Getting Next tag version using semantic releases
Asked Answered
K

4

14

Hi am using semantic release for versioning in my repo. In my Gitlab when i merge my branch with master my tag increases according to the commit and it works fine. Is there any way for me to get the " next tag version " that will come before the merge. I want to write the next version to a file before merging

Tried using exec but it doesn't seem to be running

i tried using exec but exec isn't running for me (Am quite new to semantic release i must be doing something wrong somewhere)

Could you push me in the right direction :)

My gitlab Ci script:

semantic_release:
stage: Tag
image: node:12.16
variables:
GITLAB_TOKEN: $TOKEN_ACCESS
before_script:
- npm install -g semantic-release/exec
- npm install -g semantic-release @semantic-release/gitlab-config
script:
- semantic-release -e @semantic-release/gitlab-config @semantic-release/exec
only:
- master

This is my package.json:

{
  "name": "@semantic-release/npm",
  "description": "semantic-release",
  "version": "0.0.0-development",
  "author": "",
  "release": {
    "analyzeCommits": "@semantic-release/commit-analyzer",
    "generateNotes": "@semantic-release/release-notes-generator",
    "publish": "@semantic-release/gitlab",
    "success": false,
    "fail": false,
    "branches": [
      "master"
    ],
    "npmPublish": false
  },
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    ["@semantic-release/exec", {
      "prepareCmd": "./my-build-script.sh ${nextRelease.version}"
    }]
  ]
}
1:30pm
[7:55:10 AM] [semantic-release] › ✔  Completed step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[7:55:10 AM] [semantic-release] › ℹ  The next release version is 0.2.0
[7:55:10 AM] [semantic-release] › ℹ  Start step "verifyRelease" of plugin "[Function: verifyRelease]"
[7:55:10 AM] [semantic-release] › ✔  Completed step "verifyRelease" of plugin "[Function: verifyRelease]"
[7:55:10 AM] [semantic-release] › ℹ  Start step "generateNotes" of plugin "@semantic-release/release-notes-generator"
[7:55:10 AM] [semantic-release] › ✔  Completed step "generateNotes" of plugin "@semantic-release/release-notes-generator"
[7:55:10 AM] [semantic-release] › ℹ  Start step "prepare" of plugin "[Function: prepare]"
[7:55:10 AM] [semantic-release] › ✔  Completed step "prepare" of plugin "[Function: prepare]"
[7:55:12 AM] [semantic-release] › ✔  Created tag v0.2.0
[7:55:12 AM] [semantic-release] › ℹ  Start step "publish" of plugin "@semantic-release/gitlab"
[7:55:12 AM] [semantic-release] [@semantic-release/gitlab] › ℹ  Verify GitLab authentication

Exec doesnt seem to be running

Klaipeda answered 6/3, 2020 at 15:9 Comment(3)
Hey @Origin, can you detail a little bit more? I'm not sure to understand what you want. If you have a branch master and you have a branch B, you want to merge the B into master right? And when merging, semantic-release updates your app version + create a release right ? And you want to know which release will be the next one ? Which language do you use ?Karol
ya @Karol when i merge my branch A ( with feat: commit ) with master which is at 1.0.0 version will increase to 1.0.1 (this is done my semantic release) . i want to get the new version before merge so that i can write it into a fileKlaipeda
@Klaipeda - From my experience using semantic-release, there is no way to determine what the next version will be directly from the tool. The reason for that is during a Merge/Pull request stage, semantic-release is looking at the current branch to derive its understanding of how things have changed. Only on merging can it deduce what the release branch's state is thereby figuring out what the release type will be. Having said that, it should be just as easy to emulate the logic used by the tool in a custom script.Oregon
P
10

The next version tag will be passed to any plugin during the release. In order to update a file with the next version you can use the @semantic-release/exec during the prepare step:

{
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    "@semantic-release/npm",
    ["@semantic-release/exec", {
      "prepareCmd": "./update-version.sh ${nextRelease.version}",
    }],
  ]
}

With this example the script ./update-version.sh will be called with the next version as its first parameter, before making the release.

Also See FAQ-How can I use a npm build script that requires the package.json’s version?

Proletarian answered 8/3, 2020 at 18:22 Comment(0)
F
7

Solution to use in shell script is with grep on a "dry-run" (to not actually release a new version)

VERSION_SPACES=$(npx semantic-release --dryRun | grep -oP 'Published release \K.*? ')
VERSION="${VERSION_SPACES// /}" # Remove spaces
echo $VERSION
Fulfil answered 12/4, 2020 at 19:54 Comment(1)
This should be the best answer.Abelmosk
K
1

The solution that worked for me was the following which also:

  1. Still pipes the output of the semantic-release plugin to stdout.
  2. Pulls the version into an env var ($LATEST_VERSION) that you can do with what you will.
npx semantic-release --ci false --dryRun | tee /dev/tty | grep -i "Published release" > .semver-output

export LATEST_VERSION=$([[ $(cat .semver-output) =~ .*([[:digit:]]+\.[[:digit:]]+\.[[:digit:]]+) ]] && echo ${BASH_REMATCH[1]})
Kathe answered 21/1, 2021 at 15:46 Comment(0)
Q
-1

When using GitLab, you can use dotenv reports to store the value of semantic-version for usage in the next job. You simply write the value via a semantic-version hook into the file, and let GitLab do the rest:

Install semantic-release/exec:

npm i -D @semantic-release/exec

Next update your .releaserc.json with a hook:

...
[
  "@semantic-release/exec",
    {
      "publishCmd": "echo \"VERSION=${nextRelease.version}\" >> version.env",
    }
],
...

And now store the value as artifact .gitlab-ci.yml:

release:
  script:
    - semantic-release
  artifacts:
    reports:
      dotenv: version.env # this will save the version.env file and apply all variables in the next stage

You can now export all the variables in the next stage:

test -f version.env && set -o allexport; source version.env; set +o allexport || true
Quirt answered 17/10, 2022 at 12:13 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.