semantic-release / semantic-release/git
Plugin does not generate commit message when assets set to `false`
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 339
- Forks
- 75
- Avg merge
- 5h 15m
- Merged PRs (30d)
- 6
Description
Under the options section of the readme it notes that you can set the assets option to false "to disable adding files to the release commit." However when setting the value to false, no commit is generated. It would be great to be able to generate the commit message without assets.
Use Case
Currently my team is using Semantic Release to manage the releases of our application. We deploy to three different environments (dev, qa, prod) by using pre-releases and using the format of the tag generated to determine which environment to build the release for (alpha goes to dev, beta to qa, and master to prod). There are two pre-release branches, and one branch for the primary release to production. Each branch releases it's own tag format.
"branches": [
{"name": "master"},
{
"name": "qa",
"prerelease": "beta"
},
{
"name": "develop",
"prerelease": "alpha"
}
]
The general workflow we follow is:
# work enters here
commit merged to develop branch > Semantic Release generates alpha tag > app built and deployed to dev environment > testing happens and approval to promote to qa given
# promoting dev to qa
merge develop to qa branch >Semantic Release generates beta tag > app built and deployed to qa > testing given and approval to promote to prod given
# promoting to prod
merge qa to master branch > Semantic Release generates normal tag > app built and deployed to prodcution
We were having issues with having to constantly do manual merging/conflict resolution due to release artifacts when moving between our non-production environments (develop branch -> qa branch), and so split our configuration into two files that are run depending on which branch is being processed by the pipeline. For commits to our non-production branches/envs (develop, qa) we use the folowing:
"plugins": [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
["@semantic-release/npm", {
"npmPublish": false
}],
["@semantic-release/git", {
"assets": false,
"message": "chore(release): ${nextRelease.version}\n\n${nextRelease.notes}"
}],
["@semantic-release/gitlab", {
"gitlabUrl": "<our gitlab url>",
}]
]
For production (master branch) we use:
"plugins": [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
"@semantic-release/changelog",
["@semantic-release/npm", {
"npmPublish": false
}],
["@semantic-release/git", {
"assets": ["package.json", "package-lock.json", "CHANGELOG.md"],
"message": "chore(release): ${nextRelease.version}\n\n${nextRelease.notes}"
}],
["@semantic-release/gitlab", {
"gitlabUrl": "<our gitlab url>",
}]
]
This works great for us because we can see the non-production release notes via the gitlab release view, but formal releases of the application to production are captured in the changelog file. We could also promote to the different environments at the click of a button without manually merging code on our local machines. However, shortly after moving to this setup we started to experience reference already exists errors when pushing changes to non-production branches.
Given that we are not experiencing the issue on our master branch that generates release commits, we've figured the version logged in git notes were tied to the commit message generated by the release and now they're instead tied to the tag. Since we rebase our changes based on the last commit made to the branch when working on new features, those notes are squashed with the rebase and Semantic Release can't find them when determining the version when releasing on pre-release branches, resulting in it trying to generate a tag that already exists and failing.
To fix this we would like to have Semantic Release generate the commit message, but not include assets for the pre-release branches. But, when we configure the @semantic-release/git plugin to not include any assets, it does not generate a commit despite the language in the readme that seems to imply it should.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the README options section and the @semantic-release/git configuration handling for assets and message. Reproduce the reported configuration with assets set to false, then verify that a release commit containing the configured message is generated without adding assets.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git, javascript
- Domain
- release
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100