feat: take the version from release tags or seed it, for repositories that carry none - #26
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Why
AutoVer reads a version out of a project file. Two situations have no file to read:
publishes no package and builds no image, and its releases are consumed by
pinned ref. A version written into a file there is a version nothing reads.
"Add one and run the tool again" rather than being started off.
VersionFromTagTakes the current version from the repository's own release tags. This is the
model GitHub Actions uses:
action.ymlhas no version field, and an action'sversion is purely the ref you check out.
{ "Projects": [ { "Name": "ci" } ], "VersionFromTag": true, "InitialVersion": "1.0.0", "TagFormat": "v{major}.{minor}.{patch}", "ChangeFilesDetermineIncrementType": true }Projects are listed by name only - the name is what
autover change --project-nameattaches to and what the changelog labels. Nothing is written, soautover versionproduces no commit: the tag lands onHEADand the release'sonly content is whatever
autover changelogcommits. Where several projects arelisted they share the one version the tag carries, and the largest increment any of
them asked for wins.
Checked when the configuration is read, rather than part-way through a release:
TagFormatmust be version-based - a date-based tag carries no version to read backPath/Paths- one tag carries one versionPrereleaseLabelneeds a{prerelease}placeholder to carry it, since the tagis the only place it could live
Seeding from
InitialVersionA project with no version field is now seeded instead of rejected. The field is
created - a
<Version>in an unconditionedPropertyGroup, a<version>in anuspec's
metadata, or aLABELappended to a Dockerfile (the end of the file, soit lands in the final build stage) - and takes
InitialVersionas-is rather thanincrementing from nothing. Every release after that reads the field back and
increments normally, so seeding happens once.
InitialVersiondefaults to0.1.0. Note AutoVer already had this concepthardcoded as
0.0.1inGetCurrentVersion; it was simply unreachable, because thepre-flight check errored before anything could use it.
Consequences:
EnsureProjectHasVersionTagcan no longer fire and is removed, and--skip-version-tag-checkis now inert - still accepted so existing pipelines keepworking, and its help text says so.
Testing
290tests pass. Beyond the feature's own cases, new coverage includes therelease-branch/merge workflow under tag-sourced versioning, the config survives
being rewritten by
ResetUserConfiguration, old-stylexmlnsproject files, CRLFDockerfiles, and version fields that exist but are empty.
Three bugs found by reviewing the first cut and fixed here:
files it still cut a release, while every release after it correctly declined
PrereleaseLabelwas silently discarded when the tag format had nowhere toput it, and was not applied to the first release even when it did
node, so
</PropertyGroup>ended up on the same line. Content assertions passed;only reading the file caught it, so there is now a test on the formatting
Six existing tests asserted the old "reject a missing version" contract and were
inverted to assert seeding.