semver
semver copied to clipboard
jscutlery
Add option to add `last-release` tag
The last-release tag should always be on the commit with the latest (as in time, not version-number) release.
The tag is used to calculate the changes since the last release.
Currently I'm setting the tag as an extra CI-step, but this has the disadvantage that the tag will be moved whether there is a new release or not.
The best way I came up with would be to set the last-release tag in the same step the version tag for the individual release is set.
If wanted there could be a global config where this behavior could be enabled/disabled.
Hi, I agree this could be useful. For now, we do this in the CI as an independent step in our workflow. It could be an executor used along with post-targets.
the downside of "moving" the "last-release" tag is that you always have to
git pull -t -f
before pushing, to update the tag locally.
To avoid that, im pushing a new tag, starting with release- , followed by a number, or a date and time like
git tag -f release-$(date '+%d-%m-%Y-%H-%M-%S')
to get the base for the next nx affected, im using
npx nx affected --target=prepare --base=$(git show-ref --tags | grep release- | tail -n 1 | sed 's~.* refs/tags/~~')
IMHO, this is a bit out of scope of versioning, and more an individual CI flow thing when / how to place a last-release tag.
Another possibility would be to "grep" for the newest version-tag (that depends on your configuration).
e.g. if you
{
"tagPrefix": "release-${projectName}-"
}
you could also use
git show-ref --tags | grep release- | tail -n 1 | sed 's~.* refs/tags/~~')
to get you base, and you dont have to push an extra tag at all, BUT
if a library/app fails versioning for some reason (upload fails?), you cannot retry you build.
In fact, the version tag and the release tag are two distinct things. The release tag marks the success.
💯 with @ndrsg and @edbzn,tagging last release shouldn't be part of semver. Last release could even be marked by storing the commit is in a file for instance. So there are way multiple strategies. Also, even if it's an executor in post targets. It shouldn't be executed for each project but only once so it should only be used at the workspace level.
tagging last release shouldn't be part of semver
I do not totally agree here, as you mentioned "release tag marks the success", imo we should provide something, whatever the strategy used under the hood, for marking the last successful release. It is required for semver to work properly in the CI, but I agree that we can't provide such a feature without the ability to run semver at the workspace level.
Exactly! This can only work at the workspace level. Also, what I meant is that this is beyond semver. All kind of workflows using affected need a way of marking the last success. We could even imagine multiple tags for multiple steps:
nx affected --target test --base last-test-success
nx affected --target version --base last-version-success
Actually, it should be an Nx feature. 🤔 just thinking out loud, what about a hook system that could allow us to trigger an executor after nx affected...
Or maybe, we just need an Nx wrapper for the CI. npx nx-affected-and-tag --target test