Skip to content
This repository has been archived by the owner on May 19, 2020. It is now read-only.

Enable Circle2.0 builds #1316

Merged
merged 22 commits into from
Sep 18, 2018
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
File renamed without changes.
96 changes: 96 additions & 0 deletions .circleci/config.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,96 @@
# This configuration was automatically generated from a CircleCI 1.0 config.
# And then modified to complete a build-and-test cycle.

# The build uses the docker image, circleci/build-image:ubuntu-14.04-XXL-upstart-1189-5614f37
# that has all the tools from the v1.0 CircleCI world. That image is 22.9 Gb, and
# takes about 8 minutes to set up if it's not already cached on the CircleCI machine
# that your job lands on.

# TODO:
# - enable cachine for node_modules, to save abou 2m on builds
# - enable master builds to deploy to fr-stage - DONE Managed in circle_deploy.sh
# - enable new tags to deploy to fr - DONE Managed in circle_deploy.sh
# - enable Slack notifications

version: 2
jobs:
build:
# branches: TODO filter build by branches for release to fr-stage?
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 image, at 22.9 Gb, is the old pre-configured image:
docker:
- image: circleci/build-image:ubuntu-14.04-XXL-upstart-1189-5614f37
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason we can't use a different image here? Like one specific for the tasks that it's accomplishing, go, node, etc?

Copy link
Contributor Author

@pburkholder pburkholder Sep 15, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, there is a reason. I tried to go the "correct" route by having the appropriate Docker container for the Go lang stuff, the Node stuff, the tests, etc. But it turned into a rabbit hole, first because the different images have different permissions on their paths, so I could not cache the node modules from one image and then have it restored on a subsequent Go image, because the gopath is rooted at /go/src

Second, the dependencies didn't align exactly with the way we'd been doing things before, and I was starting to get failed test results. As I started to backtrack those, I realized I was consuming a lot of my time, and that I would probably optimize for human time by just using the kitchen sink image and doing things pretty much the way they'd be done before.

You can see a lot of my abortive work trying to go the right direction in https://github.com/18F/cg-dashboard/compare/pdb-ci2.2 -- then as I got stuck trying to resolve issues with fibers binaries and node-gyp, I decided to chuck it all and just build everything off of the fat image.

command: /sbin/init
steps:
- checkout
# Compatibility step
- 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; '
# The following run steps are pulled from old circle.yml
# Machine:
- run:
working_directory: ~/18F/cg-dashboard
command: 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:
- run: sudo apt-get update; sudo apt-get install libicu52
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are these doing?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't know. It was in the old circle.yml

Maybe it's not needed, but I don't see the harm in leaving it here.

- 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
- 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
# Test:
- run: if ! go get github.com/golang/tools/cmd/cover; then go get golang.org/x/tools/cmd/cover; fi
- run: export DISPLAY=:99.0
- run: sh -e /etc/init.d/xvfb start || echo \"Unable to start virtual display.\"
- run: sleep 5 # give xvfb spin pu time
- 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 && SKIP_DOCKER=1 ./codecheck.sh # TODO: SKIP_DOCKER may not be needed anymore
# Deploy:
- run: NODE_ENV=prod npm run build-prod
- run: pip install --user ruamel.yaml
- run: export BUILD_INFO=build::$CIRCLE_BRANCH::$(date -u "+%Y-%m-%d-%H-%M-%S")::$CIRCLE_BUILD_NUM::$(deploy/npm-version.sh) && python deploy/vars-to-manifest.py
- run: cd $WS && ./deploy/circle_deploy.sh


workflows:
version: 2
build-deploy:
jobs:
- build
2 changes: 1 addition & 1 deletion deploy/circle_deploy.sh
Original file line number Diff line number Diff line change
Expand Up @@ -39,7 +39,7 @@ then
CF_APP="cg-dashboard-demo"
else
echo Unknown environment, quitting. >&2
exit 1
exit 0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we exiting cleanly here? Shouldn't it stay as exit >0 in order to fail?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The old logic only called the deploy script if it had one of the appropriate branches or a matching tag.

To replicate that same behavior with 2.0, I'd have to use a filter statement, which would either be in the workflow, as a deploy step, or in the jobs. That would double the number of jobs/steps, so each job would be held up by 22.9Gb Docker install, and we'd have to make sure we'd cached and restored all the correct paths between the jobs.

Since the deploy script has the logic to deploy to the correct place, there's no harm in having it called with each job, but just exit 0 (OK) if there's no matching tag/branch.

I know this whole PR is ugly as sin, so I hope we tamp down our aesthetic inclinations and move it forward.

fi

echo manifest: $CF_MANIFEST
Expand Down