Increment the version separately from releasing

[koterpillar]

I have a package that builds executables for several platforms and publishing those as part of a GitHub release. This is achieved by GitHub actions with this structure (on the main branch):

• Lint and test
• Build
  • Separate run for each platform
• Publish

The build steps publish the executables, the publish step downloads them and uses @semantic-release/github with assets to create a release.

---

I need to embed the version number into the executables.

I can modify the build process to do so if I know the version number, but how do I find it before publishing?

• --dry-run outputs the new version number, but is not machine readable.
• semantic-release-replace-plugin would work to replace the version before build, but has to be a part of the full Semantic Release process, which I can't complete without all executables.
• @semantic-release/exec would work to start the build, but I need to do this multiple times on separate machines (CI runners).

So far I can think of two features that could help:

• Machine readable dry run that I would execute in the platform-specific runners to extract the version.
• Separate configuration for Semantic Release that would only do the replace step and not publish anything. Requires a --configuration parameter to pass to npx semantic-release.

---

What's the best way to get the versions into my executables?

---

Update: I have tried making a separate Semantic Release configuration for the build step. The step changed the version in the file but unconditionally pushed the new tag to the repository, where the other build step running in parallel picked it up and realised there were no changes to be made.

Reiterating: the build step happens on three separate machines (CI runners), then the release step on another CI runner, so I have to run Semantic Release four times (number of builds + 1).

[babblebey]

Hi @koterpillar,

This is possible, in order to get started, you gotta understand the release lifecycle and what property is available in each step.... The release lifecycle is a split of steps where different operation is performed towards fulfilling a release. Across the each step lives a certain object called context that's forever present within this lifecycle. It gets a property and value set/appended to it after each steps in the lifecycle concludes. See https://semantic-release.gitbook.io/semantic-release/developer-guide/plugin#context-object-keys-by-lifecycle to better get a sense of the properties available per lifecycle.

You will be particularly interested in the the verifyRelease lifecycle, it is in this step that you get a the nextRelease object added to the context object. This nextRelease object has the property version.... See https://semantic-release.gitbook.io/semantic-release/developer-guide/plugin#verifyrelease

So ideally, you have 2 options...

1. You can leverage the @semantic-release/exec plugin to create a script that in runs in any step after the verifyRelease step in the release lifecycle, and you can pass on the nextRelease.version property onto the script to perform your preferred operation. In order to fulfill the choice of doing your action before publishing, then you must run the script in any step before the publish step... i.e. you could run in the generateNote or prepare step... Refer to the example here https://github.com/semantic-release/exec?tab=readme-ov-file#usage to see how to use the nextRelease.version property in your release step... the example actually uses the publish step though.
2. You can create a plugin that plugs-in to your preferred lifecycle step... and you can directly access the context.nextRelease.version property provided you are plugged-in to a step after the verifyRelease step

Hope this helps 😉

[koterpillar]

I'm sorry, but that doesn't help. The main issue I have is the "increment version in my file" has to happen on three separate machines (CI runners) before the actual release is run.

[koterpillar]

Workaround: I've written a plugin to just... stop the release process. It works like this:

• The build runners use the replace plugin, then the stop plugin. The tag is computed, version gets replaced, but nothing gets published because the release stops.
• The release runner doesn't use the stop plugin, computes the same tag, downloads the artifact from the previous builds and releases everything correctly.

Here is the semantic release configuration, build and publish steps.