You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our current release process does not automatically adjust the latest tag to the most recent official version based on semantic versioning. This limitation arises from our unique git workflow, where:
Official versions are not strictly confined to the main branch.
Version releases do not always follow a sequential temporal order.
Given these constraints, we seek a feature that, upon releasing an image triggered by a tag, checks if the tag adheres to the Semantic Versioning (SemVer) standard and represents the highest version within the repository. If both conditions are met, the image should additionally be tagged as latest.
Proposed Solution
Detects when a release is triggered by a tag.
Verifies that the tag follows the SemVer standard.
Compares the tagged version against all existing versions in the repository to determine if it is the highest.
If the tagged version is the highest based on SemVer, automatically tags the image with latest.
[Tag Release] ---> [Check if SemVer] ---> [Compare Versions] ---> [Is highest version?] ---> [Tag as 'latest']
(We have not found existing documentation or capabilities within our current toolset that meet this specific need.Additionally, I'm unsure if my idea above constitutes a valid requirement. I would appreciate some feedback on its viability. If deemed reasonable, I'm willing to implement this feature.)
The text was updated successfully, but these errors were encountered:
Compares the tagged version against all existing versions in the repository to determine if it is the highest.
I wonder why you would need this at all? I guess you maintain n and n-1 versions of your project or more right? Such as v1.9.0 patch releases and v1.10.0. In such case you could just have an env in your workflow that would be the latest version digits like:
Compares the tagged version against all existing versions in the repository to determine if it is the highest.
I wonder why you would need this at all? I guess you maintain n and n-1 versions of your project or more right? Such as v1.9.0 patch releases and v1.10.0. In such case you could just have an env in your workflow that would be the latest version digits like:
Or I guess this would be fine to create a new global expression to handle this and remove extra overhead in your workflow.
Thank you for your suggestion on setting an environment variable for the latest version and using semver comparison with GitHub-script in the workflow. However, I am looking for a solution that does not require manual updates to the workflow file each time a new version is released. To achieve this, I plan to use the following approach:
LATEST_TAG=$(git fetch --tags && git tag --sort=-v:refname | grep -E '^[0-9]+\.[0-9]+\.[0-9]+$' | head -n 1)
This command will automatically fetch all tags, sort them in descending order according to semantic versioning, filter them to match the semantic versioning pattern, and then select the top one as the latest official version tag. ...
Feature Request
Problem Statement
Our current release process does not automatically adjust the latest tag to the most recent official version based on semantic versioning. This limitation arises from our unique git workflow, where:
Given these constraints, we seek a feature that, upon releasing an image triggered by a tag, checks if the tag adheres to the Semantic Versioning (SemVer) standard and represents the highest version within the repository. If both conditions are met, the image should additionally be tagged as latest.
Proposed Solution
(We have not found existing documentation or capabilities within our current toolset that meet this specific need.Additionally, I'm unsure if my idea above constitutes a valid requirement. I would appreciate some feedback on its viability. If deemed reasonable, I'm willing to implement this feature.)
The text was updated successfully, but these errors were encountered: