Build and push docker image to hub automatically #3946
Conversation
|
The earlier code mistakenly allowed all branches and only those tags - we're now building on only those tags and no branches. |
| tags: | ||
| only: /^v[0-9].[0-9]+.[0-9]+(.[0-9]+)?/ | ||
| branches: | ||
| ignore: /.*/ |
There was a problem hiding this comment.
Can we please get a :latest for master?
Latest is horrible and makes debugging what has happened anywhere a nightmare. We push a latest because of demand for it, but we'll also push a SHA1 commit id so those wanting to know what they're running (and be able to roll back if required) can use those instead. Note that latest here is defined as "most recent master commit" not "most recent released version", as the actual semantics of making latest correct while still being able to build bugfixed releases of previous versions is just ARGH. So we define it as "master" not "latest release".
michaelkaye
force-pushed
the
michaelkaye/automate_docker_hub_upload
branch
from
d546bb9
to
74bbdd0
Compare
|
(rebased against develop to pull in hawkowls' changes) |
|
This will need two environment variables adding to CircleCI : https://circleci.com/gh/matrix-org/synapse/edit#env-vars DOCKER_HUB_USERNAME - doesn't need to be matrixdotorg, can be another user who is a contributor to just the synapse project (to minimize access) We should be aware that someone who can change the .circleci/config.yml and cause a PR or branch to be build which contains, for example: "run: echo $DOCKER_HUB_PASSWORD" will be able to obtain our credentials. This is our responsibility as reviewers to never permit those PRs to be merged to or created within this repository. We do not pass these secrets to PRs from forks of this repository - so only those with commit or merge access to this repository are able to obtain these secrets - specifically we must never set https://circleci.com/gh/matrix-org/synapse/edit#advanced-settings the "pass secrets to builds of forks of this repository" |
|
Let's just leave it on develop and watch it as we make the release candidate. |
|
we might need to make a tweak to the rc branch if it doesn't build cleanly, but shrug |
Automate pushing docker images.
Questions - do we want to build any other tags? Is that regex good enough for tags we want to build or do we have a more precise naming scheme. I was hesitant to just look for all tags starting "v" in case we tag something "very_broken_build".