Closed kgress closed 5 years ago
I've isolated the problem to scm:tag.
[INFO] --- maven-scm-plugin:1.11.1:tag (default-cli) @ scaffold ---
[INFO] Final Tag Name: 'scaffold-2.0.1'
[INFO] Executing: /bin/sh -c cd '/Users/phyzycs/Repos/scaffold' && 'git' 'tag' '-F' '/var/folders/pj/0rz8zvbj611436t2q1w55fy00000gn/T/maven-scm-1286409757.commit' 'scaffold-2.0.1'
[INFO] Working directory: /Users/phyzycs/Repos/scaffold
[INFO] Executing: /bin/sh -c cd '/Users/phyzycs/Repos/scaffold' && 'git' 'push' 'git@github.com:kgress/scaffold.git' 'refs/tags/scaffold-2.0.1'
[INFO] Working directory: /Users/phyzycs/Repos/scaffold
[INFO] Executing: /bin/sh -c cd '/Users/phyzycs/Repos/scaffold' && 'git' 'ls-files'
[INFO] Working directory: /Users/phyzycs/Repos/scaffold
It seems the tag parameter is not being respected and scm:tag is generating a "default" tag.
Bug
When running the command
npx git-semver-tags | head -n 1
, the result populated is an older release, 1.0.2.This is due to how git-semver-tags works. It will scan the commit log and parse commits that have a tag containing a version number; however, our tags contain the word
scaffold
in them. Because of this, git-semver-tags can't parse the recent releases.Expected
There isn't a real reason to have our tags contain the name of the project. I believe it's default behavior of git tags. We should find a way to reformat the tag to only be the version number and not the format that is now.
The current process is as follows:
I think the problem area here is the mvn deploy command when setting the scm:tag. I've scanned through the build logs and it's correctly setting the NEXT_VERSION to a numeric value. I manually performed the 2.0.0 release, and even entering in specifically the version 2.0.0 as the tag parameter, the most recent merge commit was amended with the tag "scaffold-2.0.0".
Maybe we could instead leave it as is and, when checking for old version, omit scaffold from the search?