Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compute release candidate #185

Closed
manuelstein opened this issue Nov 14, 2024 · 3 comments
Closed

Compute release candidate #185

manuelstein opened this issue Nov 14, 2024 · 3 comments

Comments

@manuelstein
Copy link

Hi,

I'd like to create release candidates on feature branches, i.e. compute the next version and append an -rc.1 etc.
The current beta-release-support requires a maintained version, but I would like to have that next version automatically computed from the found version and the commit analyzer.

Example:

  • latest (found) version on default 1.1.0
  • create a new branch from default with a conventional commit, e.g. 'feat: great new feature'
  • upon pull/merge request (or upon push), run the CI -> create release 1.2.0-rc.1

Ideally, the label rc would also be variable, so that I can concurrently work on different feature branches.

What would be a good approach to do this?

  1. --maintained-version -rc
  2. --maintained-version *-rc
  3. --channel rc

Cheers, Manuel

@manuelstein
Copy link
Author

I think I gave the answer already in #183.
I'm now using this gitlab script to compute next release candidates:

  script:
    - semantic-release --allow-no-changes --allow-initial-development-versions --ci-condition-opt defaultBranch="*" -f .version --dry
    - LABEL=$(echo $CI_COMMIT_BRANCH|sed 's/[^0-9a-zA-Z_-]//g'|tr '[:upper:]' '[:lower:]')
    - semantic-release --allow-no-changes --allow-initial-development-versions --maintained-version $(cat .version-unreleased)-$LABEL

@manuelstein
Copy link
Author

Problem with above is that it repeatedly creates the first release candidate, e.g. (1.2.0-rc.1):

  • The first call doesn't find the existing 1.2.0-rc.1 tag and always computes the new version 1.2.0
  • The second call then always ends up creating 1.2.0-rc.1 despite it already being an existing tag

I really don't see how calculating the next release candidate (1.2.0-rc.2) could be achieved (with gitlab).

@manuelstein
Copy link
Author

Ok, one really needs to go with the major version number only in the maintained-version (e.g. 2-alpha).

Got it working for my merge request pipelines:

  script:
    - export CI_COMMIT_BRANCH=${CI_MERGE_REQUEST_SOURCE_BRANCH_NAME}
    - LABEL=mr$CI_MERGE_REQUEST_IID
    - semantic-release --allow-no-changes --allow-initial-development-versions --force-bump-patch-version --ci-condition-opt defaultBranch="*" -f .version --dry
    - MAJOR=$(cat .version-unreleased|sed 's/\..*//')
    - semantic-release --allow-no-changes --allow-initial-development-versions --force-bump-patch-version --ci-condition-opt defaultBranch="*" --maintained-version $MAJOR-$LABEL

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant