getLastRelease: Allow customizing git tag fallback format

[semantic-release]

getLastRelease: Allow customizing git tag fallback format

[pvdlg]

In 2.6.0 we didn't change any feature. We only moved a recovery solution specific to npm from the core to this plugin.

The recovery solution is used only in the rare cases in which the npm registry doesn't contains the gitHead attribute that we use to retrieve the commit associated with the release.
This rare case happens when the last release was published from a directory on which the git head couldn't be retrieved. The 2 cases identified are when the publish is done from outside the project root or when the local repository is packed.

The change done in 2.6.0 consist in looking for the commit associated with the last version by looking at the git tags. But this is done only when gitHead is missing.

To recap, in 2.5.0:

• If the last release in the registry contains a gitHead => return it
• If not return undefined and the core will try to find the commit with the <version> or v<version> tag

And in 2.6.0:

• If the last release in the registry contains a gitHead => return it
• If not try to find the commit with the <version> or v<version> tag

In 2.6.1 we fixed the situation in which the plugin return and invalid lastRelease object with a missing gitHead. The objective of the getLastRelease is to find the commit the commit associated with a the release, so not returning is a bug.

Retrieving the last release via the release metadata in the registry is somewhat unreliable and it's something we are thinking about replacing with the much simpler git solution.

Among the problems we have with the npm getLastRelease:

• missing gitHead when publishing on a packed repo or from outside the repo
• If a commit sha is rewritten with git cherry pick, git rebase or a GitHub Rebase and merge then there is a mismatch with the registry gitHead
• complex handling of npm options (partially in local .npmrc, global .npmrc, environment variables and package.json)
• Weird stuff when using with Yarn as it passed undocumented environment variables that conflict with npm other undocumented variables

semantic-release works with valid semantic version, and this is used, parsed and checked all over the place. The valid format are x.y.z and vx.y.z:

semver.valid('1.0.0')
// 1.0.0
semver.valid('v1.0.0')
// 1.0.0
semver.valid('my-package-v1.2.3')
// null

I guess your best chance is to implement the 10 lines of code from [there](git solution) and to adapt them for your need. You can also use the npm plugin and make sure the gitHead is present in the registry, or use the version 2.5.0 that contains the bug you seems to be relying on (returning an undefined gitHead).

But I can't guarantee you won't have issues now or later as semantic-release relies on valid semantic versions.

Finally, as mentioned before we'd like to support monorepo properly, and I think that can be done in collaboration between the maintainer team and the community. As it's a complex feature we want to follow the same process that we follow for every major change:

• Description of the feature and what's needed to design it, as started in semantic-release/semantic-release#193
• Community feedback and discussion (for example semantic-release/semantic-release#563)
• Formalization of the detailed changes (for example semantic-release/evolution#1)
• Implementation once approved

[pmowrer]

But I can't guarantee you won't have issues now or later as semantic-release relies on valid semantic versions.

semantic-release-monorepo is fully committed to the semver format wherever possible. However, in a single git repository containing multiple semver packages, it simply isn't possible (to my knowledge) to use the semver format for git tags since it would collide across packages. The proposed solution (for now, to make things work) is to namespace the git tags with the package name. The tag still contains valid semver. Packages are still published using valid semver.

Finally, as mentioned before we'd like to support monorepo properly, and I think that can be done in collaboration between the maintainer team and the community.

Great, happy to contribute in any way I can, but until we get there, semantic-release-monorepo fills a need and ships production code.

You can also use the npm plugin and make sure the gitHead is present in the registry, or use the version 2.5.0 that contains the bug you seems to be relying on (returning an undefined gitHead).

As you've already touched on, gitHead is not be present for npm packages published in a monorepo since package.jsons and the git root are never equal (full explanation with references).

I guess your best chance is to implement the 10 lines of code from [there](git solution) and to adapt them for your need.

Thanks, I'll look into that!

[pvdlg]

semantic-release-monorepo is fully committed to the semver format wherever possible. However, in a single git repository containing multiple semver packages, it simply isn't possible (to my knowledge) to use the semver format for git tags since it would collide across packages. The proposed solution (for now, to make things work) is to namespace the git tags with the package name. The tag still contains valid semver. Packages are still published using valid semver.

Yep. Ideally the solution would be to centralize the determination of the tag in the core and to add a new core option to define its format or at least a prefix. We would just enforce that the tag contains a valid semver within the pattern as we would need it to determine the next version.

I'll get to that after semantic-release/semantic-release#563 as this feature is pretty well underway already and it touches quite a lot of things regarding git branches and tags.