kgress / scaffold

A Java based Selenium WebDriver abstraction
MIT License
4 stars 7 forks source link

git-semver-tags not working due to improper tagging of releases #14

Closed kgress closed 5 years ago

kgress commented 5 years ago

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:

OLD_VERSION=$(npx git-semver-tags | head -n 1)
# Using conventional commits paradigm, check the merge commit message on master to set up a new version deployment
if [ -n "$OLD_VERSION" ]; then BUMP_TYPE=$(npx -p conventional-changelog-angular -p conventional-recommended-bump conventional-recommended-bump --preset angular);
    NEXT_VERSION=$(npx semver -i $BUMP_TYPE ${OLD_VERSION});
    # Add a message to console with the next version number
    echo "Versioning artifacts with version $NEXT_VERSION";
    # Sets the new version for the release and deploys using the maven release profile
    mvn versions:set --define newVersion=${NEXT_VERSION};
    echo "Performing release for version $NEXT_VERSION";
    mvn -Prelease -Dtag=${NEXT_VERSION} deploy scm:tag;
  else
    echo "Could not detect a previous version with git-semver-tags";
  fi

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?

kgress commented 5 years ago

https://axelfontaine.com/blog/final-nail.html

kgress commented 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.