Skip to content

Instantly share code, notes, and snippets.

@tb0yd

tb0yd/config.yml Secret

Created November 2, 2018 19:19
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save tb0yd/6e3d2fe498f9eb7273a497249b97abc5 to your computer and use it in GitHub Desktop.
Save tb0yd/6e3d2fe498f9eb7273a497249b97abc5 to your computer and use it in GitHub Desktop.
circleCI
# 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: ~/mydir
parallelism: 4
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
RAILS_ENV: test
RACK_ENV: test
suite: default
RSPEC_RETRY_RETRY_COUNT: 3
LD_PRELOAD: /usr/local/lib/libjemalloc.so.2
# 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:
- 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
# This is based on your 1.0 configuration file or project settings
- run:
working_directory: ~/mydir
command: wget https://s3.amazonaws.com/motionmd-build-deps/libjemalloc.so.2
- run:
working_directory: ~/mydir
command: sudo mv libjemalloc.so.2 /usr/local/lib
# This is based on your 1.0 configuration file or project settings
- run:
working_directory: ~/mydir
command: 'sudo redis-cli ping >/dev/null 2>&1 || sudo service redis-server
start; '
# 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-
# This is based on your 1.0 configuration file or project settings
- run: bash ./config/libssh/install-libssh-0.6.5.sh
- run: echo "export rvm_ignore_gemsets_flag=1" >> ~/.rvmrc
- run: mv .sample.env .env
- run: gem install bundler
- run: gem install puma
# 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: 'bundle check --path=vendor/bundle || bundle install --path=vendor/bundle
--jobs=4 --retry=3 '
# 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
# This is based on your 1.0 configuration file or project settings
- run: mv config/database.circle.yml config/database.yml
- run: RAILS_ENV=test bundle exec rake db:create db:schema:load
# Test
# This would typically be a build job when using workflows, possibly combined with build
# This is based on your 1.0 configuration file or project settings
- run:
name: mkdir -p $CIRCLE_TEST_REPORTS/rspec
command: if [ "$CIRCLE_NODE_INDEX" == "0" ]; then mkdir -p $CIRCLE_TEST_REPORTS/rspec; fi
- run:
name: mkdir -p $CIRCLE_TEST_REPORTS/cucumber
command: if [ "$CIRCLE_NODE_INDEX" == "0" ]; then mkdir -p $CIRCLE_TEST_REPORTS/cucumber; fi
- run:
name: mkdir -p $CIRCLE_TEST_REPORTS/reports
command: if [ "$CIRCLE_NODE_INDEX" == "0" ]; then mkdir -p $CIRCLE_TEST_REPORTS/reports; fi
# This is based on your 1.0 configuration file or project settings
- run: if [ $CIRCLE_NODE_INDEX == 0 ]; then bin/rake ci:rubocop ci:validate_mappings teaspoon; else true; fi
- run:
name: Feature RSpec
# We may not be using as efficient a splitting method as was used on the 1.0 platform.
# For the most efficient split, see https://circleci.com/docs/2.0/parallelism-faster-jobs/ for setting this manually.
command: bin/rspec --format progress --format RspecJunitFormatter --out $CIRCLE_TEST_REPORTS/rspec/features_rspec.xml spec/features/admin/mass_entry/viewing_mass_entry_batch_spec.rb:14
no_output_timeout: 1200s
- run:
name: Non-Feature RSpec
# We may not be using as efficient a splitting method as was used on the 1.0 platform.
# For the most efficient split, see https://circleci.com/docs/2.0/parallelism-faster-jobs/ for setting this manually.
command: bin/rspec --format progress --format RspecJunitFormatter --out $CIRCLE_TEST_REPORTS/rspec/rspec.xml $(circleci tests glob "spec/{api,controllers,exhibits,forms,helpers,integration,lib,mailers,models,pdfs,routing,services,views,workers}/**/*_spec.rb" | circleci tests split)
no_output_timeout: 1200s
- run:
name: Test Unit
# We may not be using as efficient a splitting method as was used on the 1.0 platform.
# For the most efficient split, see https://circleci.com/docs/2.0/parallelism-faster-jobs/ for setting this manually.
command: bin/rake $(circleci tests glob "test/**/*_test.rb" | circleci tests split)
- run: bundle exec rake cucumber_runner:start
- run: bundle exec rake cucumber_runner:rerun_failing_scenarios
# This is based on your 1.0 configuration file or project settings
- run:
name: git config user.name "CircleCI"
command: if [ "$CIRCLE_NODE_INDEX" == "0" ]; then git config user.name "CircleCI"; fi
# 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment