Closed isZumpo closed 1 month ago
The recent updates to the GitHub workflows refine Docker operations, focusing on version management and automation. The docker-build.yml
now tags images as dev
for better development environment control. The release-build.yml
introduces new permissions and a job for Docker image tagging, enhancing release process automation and security.
File Path | Change Summary |
---|---|
.github/workflows/docker-build.yml |
Changed Docker image tag from latest to dev |
.github/workflows/release-build.yml |
Added write permissions, new Docker image tagging job |
🐇🌟 A dance of code in the moon's soft glow,
latest
todev
, a new tag to show, Permissions unlocked, a job to flow, Our repository sings, with changes in tow! 🚀🐰
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
As mentioned before, docker images were not getting the release tags since workflows were missing for it. This PR adds a docker release tagging job to the release-build workflow. The job downloads the image with corresponding git hash and tags it with the release number. It makes use of the docker/metadata-action to strip the v from the release version since that appears to be the common approach. Meaning that v1.2.3 would become just 1.2.3. In addition it always tags with the latest tag.
In addition, the normal docker building workflow which is triggered for every commit, is modified to no longer tag with :latest, but rather with :dev. Meaning that those who want something relatively stable can use the :latest tag while those who want to live risky can use :dev
--- Demo --- Creating a new release (v0.4.13) in my fork will correctly retag the most recent commit on the main branch:
with :0.4.13 and :latest