Docker build from tagged branches

[aaronjudd]

When creating a tagged release (commit to master, making a new release using GitHub) our CI workflow should automatically push the successful build to Docker Hub. I really don't think there is any need to have this logic be special to master or any other branch. Just any time we release/tag a branch we should build, push and label the image based on the tag name. This might not be great if we're pulling latest in production, but that's not something I'd suggest we/people rely on anyways.. ie using latest is akin to always living in alpha state.

[aaronjudd]

Maybe this would also imply.. that we get rid of prequel?

[aaronjudd]

CircleCI in theory should support tags now (Aug 1).

https://circleci.com/changelog/#circleci-2-0-git-tags-support

`CircleCI will not run a job for a Git tag unless a tags filter is specified.

https://circleci.com/docs/2.0/configuration-reference/#tags

[spencern]

@jshimko any update here?

[jshimko]

The short answer is we either need to make sure to add the version tag to the merge commit once it's on the master branch or we just manually build/push the image after the fact like I did last time. Either is an easy solution until I have time to refactor the CI config to use all of their new features.

The longer answer is I need to refactor the CI config to make use of Circle's new workflows feature (which supports parallel jobs, tag regex's, etc.). I have that partially finished on a local branch, but I'm trying to get unburied with other more pressing blockers before I go down that rabbit hole for half a day.

[spencern]

@aaronjudd is this a blocker for our 1.5.0 release still?

[aaronjudd]

From @jshimko

Somebody needs to update the CircleCI config to support triggering builds on standalone tag push events. They didn’t support it at the time Circle 2.0 came out. It wouldn’t see the tags unless they were already on the commit when merged into master (which is never the case).
Our current solution ultimately came out of this discussion…
https://discuss.circleci.com/t/git-tag-deploys-in-2-0/9493
But they now officially support it.
https://circleci.com/docs/2.0/configuration-reference/#tags
The main hassle (and majority of the work) is we have to reformat things to use their “workflows” syntax.
https://circleci.com/docs/2.0/workflows/
It’s way more flexible, but it requires a bit of reading to use it properly. The main advantage I see is parallel job execution (as in tests can run at the same time as Docker builds, for example). That could potentially shave a lot of time off of our builds. That also allows you to only rerun specific steps. So you could rerun the Docker build without waiting 5+ mins for all of the test steps to finish again.
It’s all great, but somebody needs to put in the time to update our configs to use it. And time is something I haven’t had a surplus of for quite a while. 🙂

[aaronjudd]

@impactmass Let's discuss, this might be a project you could take a look at...

[aldeed]

I have set up / worked on a few apps using circle workflows. I am not yet up to speed on how the current reaction build is set up, but I might be of some minimal help if you get stuck on the workflows config

[impactmass]

Started working on this with help from @aldeed. Approach is to:

• Update our current circleci config.yml to use the workflow in v2 (done)
• Update the deploy job to use filters tag, to achieve this issue's goal
• Update node image and fix issues
• Test & PR

[aldeed]

@aaronjudd @jshimko Can you think of any reason not to update the image for the "test" job to:

    docker:
      - image: circleci/node:8.9.1-browsers

The -browsers images have headless Chrome available for running client tests

[jshimko]

That seems reasonable to me.

[spencern]

@impactmass FYI #3629 may help out with this ticket.

[impactmass]

Thanks @spencern . #3629 actually solves the real problem of building from tagged branches.

So far, my work on #3618 will bring:

1. the circleci config.yml to use workflows which enables:
   • faster builds by running jobs within a workflow independently (except when jobs depend on another)
   • faster re-runs by allowing individual re-runs on each job
2. updates the test node image to a -browsers image that contains headless Chrome available for running client tests

I merged #3629 into #3618 and testing that everything works, then will open for review

[spencern]

@impactmass @ticean what's our status here? Can this be closed?

[ticean]

Yep. This can be closed now. We're pushing all builds to Docker Hub.

[aldeed]

@ticean I had worked with @impactmass on converting to Circle workflows as part of this, and that still hasn't been merged. Is that tracked elsewhere? Also, more importantly, the config still is not running npm run lint command, which it should, so lint errors keep sneaking in. Should I make an issue for that, or make a PR?

[impactmass]

@aldeed re: earlier work of updating the reaction repo to Circle workflows, it is being tracked in another issue. The plan is to have a similar Circle config across all our repos. So I'll be making some changes to the earlier work before it gets merged (PR should come in for that tomorrow).