Migrate to Circle CI v2.0

[jezdez]

This is just a stub so we can track getredash#2609 in Waffle.

There is a lot of precedence at Mozilla to move to 2.0, e.g.:

• https://github.com/mozilla-services/Dockerflow/blob/master/.circleci/config.yml
• https://github.com/mozilla/taar-api-lite/blob/master/.circleci/config.yml

[b4handjr]

How do we want the deploy jobs to run? Since they will need to build the image do we want to run through the entire test suite before? Or is it okay to just build and push.

I think for master builds its okay if we skip the tests, but for tags, we should run everything.

Thoughts @jezdez @hackebrot @robhudson

[jezdez]

Yeah, definitely run the test suite on every git commit, including master, just like it is now. It may take longer in terms of build time, but it also provides consistency between the environments and prevents bad surprises in case of flaky tests etc. E.g. pull requests may have had passed tests a while ago and are only later merged. It matters that we test the code again after the merge into master.

Also, remember for our fork the deploy strategy is:

a) anything merged to master is pushed to Dockerhub and tagged as "master" but not deployed
b) anything merged into the release branch is pushed to Dockerhub and taggged as "rc" and auto deployed to the rc stage environment
c) any commit tagged in git starting with "m" (e.g. m14) is pushed to Dockerhub, tagged accordingly and deployed to the stage environment
d) prod deploys are manually pushed after QA verification by the ops team

For the upstream repo, it's less involved:

a) anything merged into master or a release* branch is packed as a tarball
b) any commit tagged in git starting with "v" (e.g. v4.0.1) is built, taggged and pushed to Dockerhub

[jezdez]

This was finalized in #488 but will need to be updated once the upstream PR getredash#2672 has been merged.