(ETA - I’ve fixed this problem now (it was a Convox error, solved by running convox update repeatedly) and hit a new error which I’ll edit in if it seems potentially Circle-relevant)
Hey all,
I’m trying to automate our deployment process to match its behaviour in Circle 1.0. Before, we had this in our circle.yml:
dependencies:
post:
- curl -Ls https://install.convox.com/linux.zip > convox.zip
- sudo unzip convox.zip -d /usr/local/bin
test:
post:
- bundle exec bin/circle
deployment:
staging:
branch: staging
commands:
- convox login console.convox.com
- convox switch founders-pledge/founderspledge
- convox deploy --app founderspledge-staging
- convox run worker rake db:migrate --app founderspledge-staging
production:
branch: production
commands:
- convox login console.convox.com
- convox switch founders-pledge/founderspledge
- convox deploy --app founderspledge-production
- convox run worker rake db:migrate --app founderspledge-production
Our config.yml now looks like this:
# This configuration was automatically generated from a CircleCI 1.0 config.
# It should include any build commands you had along with commands that CircleCI
# inferred from your project structure. We strongly recommend you read all the
# comments in this file to understand the structure of CircleCI 2.0, as the idiom
# for configuration has changed substantially in 2.0 to allow arbitrary jobs rather
# than the prescribed lifecycle of 1.0. In general, we recommend using this generated
# configuration as a reference rather than using it in production, though in most
# cases it should duplicate the execution of your original 1.0 config.
version: 2
jobs:
build:
working_directory: ~/FoundersPledge/founders-pledge
parallelism: 1
shell: /bin/bash --login
# CircleCI 2.0 does not support environment variables that refer to each other the same way as 1.0 did.
# If any of these refer to each other, rewrite them so that they don't or see https://circleci.com/docs/2.0/env-vars/#interpolating-environment-variables-to-set-other-environment-variables .
environment:
CIRCLE_ARTIFACTS: /tmp/circleci-artifacts
CIRCLE_TEST_REPORTS: /tmp/circleci-test-results
# In CircleCI 1.0 we used a pre-configured image with a large number of languages and other packages.
# In CircleCI 2.0 you can now specify your own image, or use one of our pre-configured images.
# The following configuration line tells CircleCI to use the specified docker image as the runtime environment for you job.
# We have selected a pre-built image that mirrors the build environment we use on
# the 1.0 platform, but we recommend you choose an image more tailored to the needs
# of each job. For more information on choosing an image (or alternatively using a
# VM instead of a container) see https://circleci.com/docs/2.0/executor-types/
# To see the list of pre-built images that CircleCI provides for most common languages see
# https://circleci.com/docs/2.0/circleci-images/
docker:
# SC- See https://circleci.com/docs/2.0/circleci-images/
# - image: circleci/ruby:2.3-browsers
- image: circleci/ruby:2.5.1-stretch-node-browsers
environment:
PGHOST: 127.0.0.1
PGUSER: ubuntu
RAILS_ENV: test
POSTGRES_USER: ubuntu
- image: circleci/postgres:9.6.9-alpine-ram
environment:
POSTGRES_USER: ubuntu
POSTGRES_DB: circleci_test
POSTGRES_PASSWORD: ""
# environment:
# PGHOST: 127.0.0.1
# - image: circleci/postgres:9.6-alpine-ram
# - image: circleci/ruby:2.3
# - image: circleci/build-image:ubuntu-14.04-XXL-upstart-1189-5614f37
# command: /sbin/init
steps:
# Machine Setup
# If you break your build into multiple jobs with workflows, you will probably want to do the parts of this that are relevant in each
# The following `checkout` command checks out your code to your working directory. In 1.0 we did this implicitly. In 2.0 you can choose where in the course of a job your code should be checked out.
- checkout
# Prepare for artifact and test results collection equivalent to how it was done on 1.0.
# In many cases you can simplify this from what is generated here.
# 'See docs on artifact collection here https://circleci.com/docs/2.0/artifacts/'
- run: mkdir -p $CIRCLE_ARTIFACTS $CIRCLE_TEST_REPORTS
# Dependencies
# This would typically go in either a build or a build-and-test job when using workflows
# Restore the dependency cache
- restore_cache:
keys:
# This branch if available
- v1-dep-{{ .Branch }}-
# Default branch if not
- v1-dep-master-
# Any branch if there are none on the default branch - this should be unnecessary if you have your default branch configured correctly
- v1-dep-
# The following line was run implicitly in your 1.0 builds based on what CircleCI inferred about the structure of your project. In 2.0 you need to be explicit about which commands should be run. In some cases you can discard inferred commands if they are not relevant to your project.
- run: echo -e "export RAILS_ENV=test\nexport RACK_ENV=test" >> $BASH_ENV
- run: 'bundle check --path=vendor/bundle || bundle install --path=vendor/bundle
--jobs=4 --retry=3 '
# This is based on your 1.0 configuration file or project settings
- run: curl -Ls https://install.convox.com/linux.zip > convox.zip
- run: sudo unzip convox.zip -d /usr/local/bin
# Save dependency cache
- save_cache:
key: v1-dep-{{ .Branch }}-{{ epoch }}
paths:
# This is a broad list of cache paths to include many possible development environments
# You can probably delete some of these entries
- vendor/bundle
- ~/virtualenvs
- ~/.m2
- ~/.ivy2
- ~/.bundle
- ~/.go_workspace
- ~/.gradle
- ~/.cache/bower
# The following line was run implicitly in your 1.0 builds based on what CircleCI inferred about the structure of your project. In 2.0 you need to be explicit about which commands should be run. In some cases you can discard inferred commands if they are not relevant to your project.
- run: |-
mkdir -p config && echo 'test:
username: ubuntu
database: circle_ruby_test
adapter: postgresql
encoding: unicode
pool: 5
host: localhost
' > config/database.yml
- run:
command: bundle exec rake db:create db:schema:load --trace
environment:
RAILS_ENV: test
RACK_ENV: test
# Test
# This would typically be a build job when using workflows, possibly combined with build
# The following line was run implicitly in your 1.0 builds based on what CircleCI inferred about the structure of your project. In 2.0 you need to be explicit about which commands should be run. In some cases you can discard inferred commands if they are not relevant to your project.
- run: mkdir -p $CIRCLE_TEST_REPORTS/rspec
- run:
command: bundle exec rspec --color --require spec_helper --format RspecJunitFormatter --out $CIRCLE_TEST_REPORTS/rspec/rspec.xml --format progress spec
environment:
RAILS_ENV: test
RACK_ENV: test
- run: mkdir -p $CIRCLE_TEST_REPORTS/cucumber
- run:
command: 'bundle exec cucumber --format json --out $CIRCLE_TEST_REPORTS/cucumber/cucumber.cucumber '
environment:
RAILS_ENV: test
RACK_ENV: test
# This is based on your 1.0 configuration file or project settings
- run: bundle exec bin/circle
# Deployment
# Your existing circle.yml file contains deployment steps.
# The config translation tool does not support translating deployment steps
# since deployment in CircleCI 2.0 are better handled through workflows.
# See the documentation for more information https://circleci.com/docs/2.0/workflows/
# Teardown
# If you break your build into multiple jobs with workflows, you will probably want to do the parts of this that are relevant in each
# Save test results
- store_test_results:
path: /tmp/circleci-test-results
# Save artifacts
- store_artifacts:
path: /tmp/circleci-artifacts
- store_artifacts:
path: /tmp/circleci-test-results
staging_deploy:
docker:
- image: circleci/ruby:2.5.1-stretch-node-browsers
steps:
# - checkout
- run: curl -Ls https://install.convox.com/linux.zip > convox.zip
- run: sudo unzip convox.zip -d /usr/local/bin
- run: convox login console.convox.com
- run: convox switch founders-pledge/founderspledge
- run: convox deploy --app founderspledge-staging
- run: convox run worker rake db:migrate --app founderspledge-staging
workflows:
version: 2
test_and_deploy:
jobs:
- build
- staging_deploy:
requires:
- build
filters:
branches:
only: staging
When I upload to our Staging branch it seems to deploy ok but on the production branch I get an error, ‘ERROR: Get : unsupported protocol scheme “”’:
My best guess atm is this is a Docker-related error, but since it didn’t happen in v1.0 and doesn’t happen on our Staging site, I was hoping someone here could shed some light?
In case relevant, this is this content of our docker-compose.yml file:
web: &web
build: .
command: bundle exec puma -C config/puma.rb
environment:
- CONTENTFUL_API_KEY
- CONTENTFUL_SPACE
- DEVISE_SECRET_KEY
- HELLOSIGN_API_KEY
- RACK_ENV=production
- SECRET_KEY_BASE
- SENTRY_DSN
- ASSET_HOST
labels:
- convox.port.443.protocol=https
- convox.deployment.minimum=50
ports:
- 80:3000
- 443:3000
worker:
<<: *web
ports: []
command: bundle exec sidekiq -C config/sidekiq.yml -e production
Appreciate any tips.