Stubby for Circle

cloud-gov · Sep 7, 2018 · 7d6168e · 7d6168e
1 parent 9ae5234
commit 7d6168e
Show file tree

Hide file tree

Showing 2 changed files with 163 additions and 0 deletions.
diff --git a/.circleci/config-translation b/.circleci/config-translation
@@ -0,0 +1,134 @@
+# 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: ~/18F/cg-dashboard
+    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
+      GODIST: go1.9.linux-amd64.tar.gz
+      WS: /home/ubuntu/.go_workspace/src/github.com/18F/cg-dashboard
+      CF_ORGANIZATION: cloud-gov
+    # 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: ~/18F/cg-dashboard
+        command: 'sudo docker info >/dev/null 2>&1 || sudo service docker start; '
+    # This is based on your 1.0 configuration file or project settings
+    - run:
+        working_directory: ~/18F/cg-dashboard
+        command: cd cg-dashboard && nvm install && nvm use && nvm alias default $(cat .nvmrc)
+    - run:
+        working_directory: ~/18F/cg-dashboard
+        command: mkdir -p download
+    - run:
+        working_directory: ~/18F/cg-dashboard
+        command: test -e download/$GODIST || curl -o download/$GODIST https://storage.googleapis.com/golang/$GODIST
+    - run:
+        working_directory: ~/18F/cg-dashboard
+        command: sudo rm -rf /usr/local/go
+    - run:
+        working_directory: ~/18F/cg-dashboard
+        command: sudo tar -C /usr/local -xzf download/$GODIST
+    # 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: sudo apt-get update; sudo apt-get install libicu52
+    - run: go version
+    - run: go get -u github.com/golang/dep/cmd/dep
+    - run: rm -rf $WS
+    - run: mkdir -p $(dirname $WS) && ln -s $(pwd) $WS
+    - run: cd $WS && dep ensure
+    - run: npm install
+    - run: npm run test-selenium-install
+    # This is based on your 1.0 configuration file or project settings
+    - run: cd $WS && go build
+    - run: npm run build
+    - run: wget https://chromedriver.storage.googleapis.com/2.33/chromedriver_linux64.zip
+    - run: unzip chromedriver_linux64.zip
+    - run: sudo cp chromedriver /usr/local/bin/chromedriver
+    # 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
+        # These cache paths were specified in the 1.0 config
+        - node_modules
+        - ./node_modules
+    # 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: if ! go get github.com/golang/tools/cmd/cover; then go get golang.org/x/tools/cmd/cover; fi
+    # This is based on your 1.0 configuration file or project settings
+    - run: export DISPLAY=:99.0
+    - run: sh -e /etc/init.d/xvfb start || echo \"Unable to start virtual display.\"
+    - run: sleep 5
+    - run: cd $WS && npm test
+    - run: NODE_ENV=prod npm run build
+    - run: sleep 5
+    - run: cd $WS && npm run test-performance || true
+    - run: cd $WS && ./codecheck.sh
+    # 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
diff --git a/.circleci/config.yml b/.circleci/config.yml
@@ -0,0 +1,29 @@
+---
+version: 2
+jobs:
+  build:
+    working_directory: ~/18F/cg-dashboard
+    parallelism: 1
+    shell: /bin/bash --login
+    environment:
+      CIRCLE_ARTIFACTS: /tmp/circleci-artifacts
+      CIRCLE_TEST_REPORTS: /tmp/circleci-test-results
+      GODIST: go1.9.linux-amd64.tar.gz
+      WS: /home/ubuntu/.go_workspace/src/github.com/18F/cg-dashboard
+      CF_ORGANIZATION: cloud-gov
+    # 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
+    - checkout