Add support for automatic tagging (:1, :1.2, :1.2.3, etc) for semantic versions #22
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Enabling the feature
This feature is off by default. To enable it, either:
PLUGIN_AUTO_TAG
for drone plugins--auto_tag
for command-line useThis changes the way tags (both
--tags
andPLUGIN_TAGS
) are interpreted. Now, instead of saying1,1.2,1.2.3,latest
you can sayv1.2.3,latest
This mostly follows semver.org, except that it also swaps underscores (which are not permitted) for hyphens, as otherwise it will likely be confusing when you try
v1.2.3+linux_arm
and your semver tagging breaks.Semantics
This parses all tags as semantic versions (after performing a swap of
_
for-
as required by semver.org). If they parse correctly, the following logic happens:v1.2.3-alpha1
tags1.2.3-alpha1
)v1.2.3+linux
tags1+linux
,1.2+linux
, etc)Alternatives
Instead of interpreting PLUGIN_TAGS differently, we could make PLUGIN_AUTO_TAGS a list that would be required to parse correctly as semantic versions, which might avoid some classes of error. That would make invocation look like
This probably works fine for most drone workflows, though it will break workflows where e.g. someone tags a build
for_testing
or something along those lines, so I did not go with this approach initially.