chore: add github action to update remote docker images on a new tag push #1595
Conversation
ogenev
added
the
flamingo
ogenev
requested review from
carver,
KolbyML,
njgheorghita,
morph-dev and
mrferris
There was a problem hiding this comment.
I like the idea of automating this. But I have some concerns about current approach and would like to discuss it.
- I'm not sure how much I like the idea that
latestdocker images is republished astestnetwhenever there is a tag push, becauselatestdocker image might not correspond to the same commit that is tagged. For example:- we want to tag/release non-HEAD commit for some reason
- we tag HEAD commit, but circleci didn't yet finish building/publishing corresponding docker image
In case we decide to go with current logic anyway, than I have these ideas/suggestions:
- currently, we already have a workflow that triggers on tag (release). Would it make sense for this to be part of the same workflow?
- currently, docker images are created and published as part of the circleci. Should this be there instead?
- I believe circleci can be configured to trigger on tag push as well
There was a problem hiding this comment.
Why are portal-spec-tests updated?
| @@ -29,17 +29,18 @@ git pull --rebase upstream master | |||
| ``` | |||
| 2. Create a new git tag with the chosen version, for example: | |||
| ```bash | |||
| git tag v0.1.0-alpha.15 | |||
| git tag v0.1.1 | |||
There was a problem hiding this comment.
I think we should still release alpha versions. Meaning, next release should probably be: v0.1.1-alpha.1.
And once we achieve milestone or want to make proper release for whatever reason, we release non-alpha (v0.1.1).
There was a problem hiding this comment.
I think two approaches are viable here:
- we can bump the minor version on every new release 0.2.0, 0.3.0 ... 0.123.0
- or use a pre-release identifier: 0.2.0-alpha.1 until we release a stable 0.2.0 version.
I'm more in favor of the second approach.
This is a valid concern, but if we want to support the first use case (tagging non-Head commit), we should rethink our current workflow for building the docker images. Currently, we push images with two tags: "latest" and "testnet." "Latest" is always updated on a new master commit, do we want to change this? Maybe, the latest tag should mean only the latest release, not a commit? The clearest approach for me would be to build and push "latest" docker image when we release a new version and update our deploying infra to use the "latest" tag when deploying (instead of "testnet"). Does it make sense to build a new docker image on any new commit, what if this commit is only a doc change?
We can have multiple workflows that are triggered on a new tag. I think keeping those workflows in separate files is more clear and easy to navigate.
We are mixing github actions and CIrcleCI to do CI, which is not very clear. My logic is to keep all workflows on a new tag in github actions (we already have the release workflow) and leave CircleCI for running only the lints and tests. |
It does, because Hive uses it. Therefore, we want new docker image on every new commit that is added to the master branch. And I would say it's fine to keep calling it "latest". But I'm not sure "testnet" makes sense to be the name of our release. Might me good to discuss with the rest of the team, what is our plan regarding this. If we want to have some pre-release/testnet deployment (which I think we should), we can use "testnet" image for that, and create "release" image for actual release. The question still remains, how these two images (testnet and release) are created/published. So let's bring this topic during next meeting and try to figure out the way forward. |
What was wrong?
Fix #1594
How was it fixed?
To-Do