CD Proposal: Don't update 'latest' Docker tag on Github pre-release#285
CD Proposal: Don't update 'latest' Docker tag on Github pre-release#285
Conversation
|
@armab what tag does the published bitops image end up with for a github pre-release? Have you tested that it works as expected? |
|
@mickmcgrath13 Taking table here as an example: https://bitovi.github.io/bitops/versioning/#official-images, the pre-release will publish the tags as before, but won't update the This means if we, for example, publish a new And yes, I'll need to test this PR functionality somehow. |
mickmcgrath13
left a comment
mickmcgrath13
left a comment
There was a problem hiding this comment.
@armab
approved so long as it's tested somehow. Can you outline in this PR a plan to test?
|
Yeah, working on my fork. Looks like there's a rabbit hole, considering that release workflow for prebuilt images was never actually ran. Good call on testing 👍 |
Fixes:
```
Traceback (most recent call last):
13
File "/entrypoint.py", line 39, in <module>
14
file.write(template.render(**variables) + '\n')
15
File "/usr/lib/python3.7/site-packages/jinja2/asyncsupport.py", line 76, in render
16
return original_render(self, *args, **kwargs)
17
File "/usr/lib/python3.7/site-packages/jinja2/environment.py", line 1008, in render
18
return self.environment.handle_exception(exc_info, True)
19
File "/usr/lib/python3.7/site-packages/jinja2/environment.py", line 780, in handle_exception
20
reraise(exc_type, exc_value, tb)
21
File "/usr/lib/python3.7/site-packages/jinja2/_compat.py", line 37, in reraise
22
raise value.with_traceback(tb)
23
File "<template>", line 1, in top-level template code
24
File "/usr/lib/python3.7/site-packages/jinja2/environment.py", line 430, in getattr
25
return getattr(obj, attribute)
26
jinja2.exceptions.UndefinedError: 'tags' is undefined
```
when using `tags.bitops_base` in 'variables'
| commitChange: true | ||
| updateFile: true |
There was a problem hiding this comment.
@PhillypHenning I'm afraid the multi-step logic updating the bitops tag via commit becomes out of date since we agreed on introducing the dev tag that's generated from the main branch.
The problem is that TAG file update (including for releases) happens in the main branch too where the source of truth for the tag is that file.
Instead of that we could be just taking the tag from the original release version and consider that as a source of truth for tagging the "stable" BitOps docker images via GH Workflows in one go without multi-step tag file update.
Are you fine with this approach? Do you see any corner cases going that way?
I can work on refactoring the workflow in another PR if agreed.
WDYT?
There was a problem hiding this comment.
we could be just taking the tag from the original release version
@armab Is this to say that we use a GitHub tag based workflow, and whatever the GitHub Tag is is what we use for the image versions?
@PhillypHenning remind me why we had the multi-step approach (i.e. update a file)?
There was a problem hiding this comment.
@mickmcgrath13
The idea behind it was that if anything source wise changed it would regenerate the base tag, which then would bump the tag file, which was the trigger for the loaded images.
@armab
I like the approach you're suggesting 👍
| release: | ||
| types: [ published ] |
There was a problem hiding this comment.
Looks like the omnibus image wasn't built on a release event, but instead the built was triggered when another "base" workflow updated the tag file.
With that approach there is no way to figure if it's a release or pre-release event here.
arm4b
changed the title
|
Closing this PR in favor of #293 as a proper implementation will need some rework. |
4 participants
Based on #283, we updated the
latestDocker tag on releasing the2.0.0-rcwhich might be great for preview, but not a completely stable version.An alternative is to additionally use the Github pre-release functionality in Github:
With this PR, Github pre-releases won't update the
latesttag on Docker Hub, only "stable" releases will.This way we would control more granularly the usage of
latestDocker tag users rely on.