|
| 1 | +# This configuration was automatically generated from a CircleCI 1.0 config. |
| 2 | +# It should include any build commands you had along with commands that CircleCI |
| 3 | +# inferred from your project structure. We strongly recommend you read all the |
| 4 | +# comments in this file to understand the structure of CircleCI 2.0, as the idiom |
| 5 | +# for configuration has changed substantially in 2.0 to allow arbitrary jobs rather |
| 6 | +# than the prescribed lifecycle of 1.0. In general, we recommend using this generated |
| 7 | +# configuration as a reference rather than using it in production, though in most |
| 8 | +# cases it should duplicate the execution of your original 1.0 config. |
| 9 | +version: 2 |
| 10 | +jobs: |
| 11 | + build: |
| 12 | + working_directory: ~/material-motion/indefinite-observable-js |
| 13 | + parallelism: 1 |
| 14 | + shell: /bin/bash --login |
| 15 | + # CircleCI 2.0 does not support environment variables that refer to each other the same way as 1.0 did. |
| 16 | + # 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 . |
| 17 | + environment: |
| 18 | + CIRCLE_ARTIFACTS: /tmp/circleci-artifacts |
| 19 | + CIRCLE_TEST_REPORTS: /tmp/circleci-test-results |
| 20 | + # In CircleCI 1.0 we used a pre-configured image with a large number of languages and other packages. |
| 21 | + # In CircleCI 2.0 you can now specify your own image, or use one of our pre-configured images. |
| 22 | + # The following configuration line tells CircleCI to use the specified docker image as the runtime environment for you job. |
| 23 | + # We have selected a pre-built image that mirrors the build environment we use on |
| 24 | + # the 1.0 platform, but we recommend you choose an image more tailored to the needs |
| 25 | + # of each job. For more information on choosing an image (or alternatively using a |
| 26 | + # VM instead of a container) see https://circleci.com/docs/2.0/executor-types/ |
| 27 | + # To see the list of pre-built images that CircleCI provides for most common languages see |
| 28 | + # https://circleci.com/docs/2.0/circleci-images/ |
| 29 | + docker: |
| 30 | + - image: circleci/node:10-stretch-browsers |
| 31 | + steps: |
| 32 | + # Machine Setup |
| 33 | + # 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 |
| 34 | + # 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. |
| 35 | + - checkout |
| 36 | + # Prepare for artifact and test results collection equivalent to how it was done on 1.0. |
| 37 | + # In many cases you can simplify this from what is generated here. |
| 38 | + # 'See docs on artifact collection here https://circleci.com/docs/2.0/artifacts/' |
| 39 | + - run: mkdir -p $CIRCLE_ARTIFACTS $CIRCLE_TEST_REPORTS/tslint/ $CIRCLE_TEST_REPORTS/mocha/ |
| 40 | + # Dependencies |
| 41 | + # This would typically go in either a build or a build-and-test job when using workflows |
| 42 | + # Restore the dependency cache |
| 43 | + - restore_cache: |
| 44 | + keys: |
| 45 | + # This branch if available |
| 46 | + - node10-{{ .Branch }}- |
| 47 | + # Default branch if not |
| 48 | + - node10-develop- |
| 49 | + # Any branch if there are none on the default branch - this should be unnecessary if you have your default branch configured correctly |
| 50 | + - node10- |
| 51 | + |
| 52 | + # set default yarn installation's install path |
| 53 | + - run: yarn config set prefix "$HOME/.yarn" |
| 54 | + - run: PATH=$( yarn global bin ):$PATH |
| 55 | + |
| 56 | + - run: yarn |
| 57 | + |
| 58 | + # Save dependency cache |
| 59 | + - save_cache: |
| 60 | + key: node10-{{ .Branch }}-{{ epoch }} |
| 61 | + paths: |
| 62 | + - ~/.cache/yarn |
| 63 | + - ./node_modules |
| 64 | + |
| 65 | + # yarn will lint separately as part of pretest, but we're running it manually to get the output piped into Circle |
| 66 | + - run: |
| 67 | + name: Run linter |
| 68 | + command: yarn run lint --out $CIRCLE_TEST_REPORTS/tslint/core.xml --formatters-dir ./node_modules/tslint-junit-formatter/formatters --format junit |
| 69 | + when: always |
| 70 | + |
| 71 | + # Test |
| 72 | + # This would typically be a build job when using workflows, possibly combined with build |
| 73 | + # This is based on your 1.0 configuration file or project settings |
| 74 | + - run: |
| 75 | + name: Run unit tests |
| 76 | + command: yarn run test --reporter mocha-junit-reporter --reporter-options mochaFile=$CIRCLE_TEST_REPORTS/mocha/test-results.xml |
| 77 | + when: always |
| 78 | + |
| 79 | + # Teardown |
| 80 | + # 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 |
| 81 | + # Save test results |
| 82 | + - store_test_results: |
| 83 | + path: /tmp/circleci-test-results |
| 84 | + # Save artifacts |
| 85 | + - store_artifacts: |
| 86 | + path: /tmp/circleci-artifacts |
| 87 | + - store_artifacts: |
| 88 | + path: /tmp/circleci-test-results |
| 89 | + |
| 90 | +# From http://codereview.cc/harbormaster/step/edit/6/ |
| 91 | +# |
| 92 | +# This was from CircleCI v1, but Internet comments lead me to believe it's |
| 93 | +# unofficially still supported in Circle v2. |
| 94 | +notify: |
| 95 | + webhooks: |
| 96 | + - url: http://codereview.cc/harbormaster/hook/circleci/ |
| 97 | + |
0 commit comments