Please add a tag on Github matching each releases on DockerHub to diff code change between releases
tlvu opened this issue · 7 comments
Feature description
For traceability and for us to anticipate code/config changes when pulling in new releases, please add a tag on Github matching each releases on DockerHub so we can diff code change between releases.
Currently on DockerHub we see release 2.25.2--v2024.06.25 but there are no tags for 2.25.2--v2024.06.25 on Github.
Additional context
Screenshot of DockerHub releases:
Screenshot of Github tags:
@tlvu There are a couple of actions that can do this, maybe you could take a stab at this and see how far you get because currently the releases are done using github action and a quick check shows https://github.com/marketplace/actions/tag-release-on-push-action or https://github.com/marketplace/actions/create-tag-release.
@NyakudyaA
Can you provide details (or confirm) how the deployment and docker image tags are created?
What is the "source of truth" of the tag/release number to be replicated everywhere for the release?
Is it only an alignment of the version numbers everywhere using https://github.com/kartoza/docker-geoserver/blob/develop/upgrade_geoserver_version.sh?
Typically (in most repos I've worked on at least), a tag/release is pushed to GitHub, and GitHub Actions with their corresponding conditions are triggered to do Docker builds, upload to source-forge, or any relevant repositories where binaries should be shipped.
At the moment, updates seem manual (running https://github.com/kartoza/docker-geoserver/blob/develop/upgrade_geoserver_version.sh and pushing the changes to develop). However, there are still many inconsistencies due to missing references (eg. docker-geoserver/.github/workflows/deploy-image.yaml is not in the update script). Because of this, for example, mismatching versions are potentially produced :
Lines 6 to 8 in e0ea86e
Should the release/tags be published only by relying on the updated values in docker-geoserver/.github/workflows/deploy-image.yaml when Git pushed?
@NyakudyaA FYI @fmigneault is a collegue of mine. He is more well versed in Github automation than I am.
@fmigneault The https://github.com/kartoza/docker-geoserver/blob/develop/upgrade_geoserver_version.sh is just used to upgrade the image versions i.e 2.25.0 to 2.25.1, So a user also needs to update the github actions tags to match the specific version being uploaded in the bash script. So the issue that needs to be fixed by the github action is that whenever a commit is merged it pushes a new image based on the github actions and we are currently differentiating this by just publishing new images with the date for the version. So the feature request here is that we rely on github action as source of truth for publishing new images and also tags with source code etc for each image
@fmigneault The upgrade_geoserver_version is a helper script to aid in the migration of a version so it should also be updated to handle updating https://github.com/kartoza/docker-geoserver/tree/develop/.github/workflows. Also, #669 has been introduced to cater for also updating https://github.com/kartoza/docker-geoserver/blob/develop/build_data/community_plugins.txt and https://github.com/kartoza/docker-geoserver/blob/develop/build_data/stable_plugins.txt which also change during version upgrades
@fmigneault @tlvu I am sure we can use something like https://stackoverflow.com/questions/75679683/how-can-i-auto-generate-a-release-note-and-create-a-release-using-github-actions to resolve this
gh release create
gh release upload
Any comments about using the above?
If everything can be triggered automatically by a tag, from version update, docker build, listing of updated plugins, up to published release, that would be ideal.
After that, it is more a matter of "how" we employ tags.
Typically, it is bad practice to rewrite tags at new commits. A new version patch should be used.
It doesn't matter if the patch number end up very high until a new minor feature is integrated.
However, if there is still an intention to update and override existing tags, then each release should use either the build date-time or the build-commit as well to allow referencing of a specific artifact without worry it could be replaced later on.