-
Notifications
You must be signed in to change notification settings - Fork 152
Description
Description
This issue is primarily to better reference comments of mine on the topic from different issues. I've revised each of those and quoted them inline below for convenience.
The information is still a bit dense and could do with further revision, I can't say I'll have time to tackle that.
It may just be easier to add a link to the README docs to this issue for more information in the meantime (similar to the approach taken for pre-release tags (semver/pep440) caveats).
If you've landed here from seeking a deeper understanding of config decisions/caveats with the action, you may also appreciate this resource on labels/annotations defaults.
Beyond the relevance of the priority attribute (especially if you have various tag types with a subset only being used between different trigger contexts of a workflow) do keep in mind:
type=raw,value=latest,enable=falsedoes not prevent thelatesttag from being added by default. Configure theflavorinput withlatest=falseto opt-out instead.- There is a caveat that might not seem obvious initially that applies to mutable tags like the
latesttag and semver styled tags (1.2.3=>:1,:1.2,:1.2.3) when your release process would update past major or minor version series with a new point/patch release (bug fix, security patch)- If you're not careful you'll mess up these mutable tags (
:major+:major.minor) to resolve to these earlier release channels instead of the intended "latest" release channels. - I have provided some suggestions to deal with that at the expense of extra complexity. It would be better/simpler however to parameterize your workflow in a way that you have a better handle on managing the inputs for determining what the
latestmajor and minor versions are.
- If you're not careful you'll mess up these mutable tags (
The four tags that opt-in to latest tag (and the importance of the priority attribute)
Usage of any of these tags types will implicitly enable a
latesttag as the docs explain whenflavor.latest=autowould evaluate toflavor.latest=true:
type=ref,event=tag(source: alwaystrue)type=semver,pattern=...(source:falseif pre-release or invalid semver)type=pep440,pattern=...(source:falseif pre-release or invalid pep440)type=match,pattern=...(source: alwaystrue)NOTE:
- Those all rely on
github.ref_type == 'tag'(a push event trigger from a tag rather than a commit), unless they were given an explicitvalueas input instead.latestwill be determined by the firsttagsinput entry processed by the action (which is dependent upon the sort order based on their associatedpriorityattribute).
type=semver(900) /type=pep440(900) >type=match(800) >type=ref(600)- When priority is the same value, the secondary sorting factor is the declaration order from the
tagsinput.- If a different tag type from those four mentioned was given a higher priority (or already had higher by default, eg:
type=schedule(1000)), then that tags defaultflavor.latest=autologic is to setlatest=false, preventing an implicitly added alatesttag.
Conditional logic for type=semver/type=pep440 on pre-release inputs:
Lines 183 to 198 in ed95091
let latest = false; const sver = semver.parse(vraw, { loose: true }); if (semver.prerelease(vraw)) { if (Meta.isRawStatement(tag.attrs['pattern'])) { vraw = this.setValue(handlebars.compile(tag.attrs['pattern'])(sver), tag); } else { vraw = this.setValue(handlebars.compile('{{version}}')(sver), tag); } } else { vraw = this.setValue(handlebars.compile(tag.attrs['pattern'])(sver), tag); latest = true; } return Meta.setVersion(version, vraw, this.flavor.latest == 'auto' ? latest : this.flavor.latest == 'true');
- At the start of that snippet the
latestvariable is initiallyfalseand if the semver tag being processed is considered a release tag (not parsed as a semver pre-release version) it'll be set tolatest=true.- Finally at the end of that snippet it'll check
flavor.latest, which if configured asautowill use thelatestvariable (release:true, or for pre-release:false) that was set in the prior condition, otherwise it'll use what was explicitly configured on the workflow (flavor.latest=<true|false>).
Influence of flavor.latest on creating an implicit latest tag (compared to manual type=raw,value=latest,enable=<condition>)
I'm short on time, so here's a rough outline for anyone landing here, that may want to contribute a fix to the README:
type=rawcould mention a caveat withvalue=latest.- The
latesttag section references the defaultflavor.latest=autobehaviour.
- That section then suggests using a
type=rawtag withenablefor controlling a conditionallatesttag, without clarifying that theflavor.latest=autodefault will disregard/override that enable logic.- Additionally if
flavor.latest=trueand atype=raw,value=latest,enable=truetag are both present, the tags output will produce twolatesttags (even when there is no suffix/prefix difference involved).flavorsetting describes theonlatestcondition forflavor.<prefix|suffix>:
It is not clarified that
onlatestattribute is only applicable to an implicitlatesttag generated fromflavor.latest=<auto|true>(whenautoresolves totrue).onlatesthas no relation to an explicittype=raw,value=latesttag (which could easily be confused that it does).
onlatestis alsofalseby default, but that's not documented either (see this recent bug report from a confused user).
flavor.suffix(and equivalentflavor.prefix) applies to all explicit tags, but can also be used as an attribute intagsto opt-out via,suffix=(suffix unset via an empty value). This override behaviour could be documented more clearly, given the current docs that show a tag types implicit defaults which already include,prefix=,suffix=it may not be obvious that you can opt-out of the flavor prefix/suffix this way.Lines 703 to 708 in ed95091
Extended attributes and default values: ```yaml tags: | type=raw,enable=true,priority=200,prefix=,suffix=,value= ```