-
Notifications
You must be signed in to change notification settings - Fork 47
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
conventional-changelog-conventionalcommits v8.0.0 breaks semantic release #633
Comments
I had the error even with |
I'm not sure what that means. I simply have a |
@ryancausey Oh, I'm not sure, I'm configuring all the plugins explicitly, and the plugins accept the |
Seems like there is a bug with semantic-release plugins conflicting with latest major conventional commits. Reverting as issue suggests: semantic-release/release-notes-generator#633 commit-id:b1f4a00c
Seems like there is a bug with semantic-release plugins conflicting with latest major conventional commits. Reverting as issue suggests: semantic-release/release-notes-generator#633 commit-id:b1f4a00c
the conventional-changelog packages released new major versions. that means they include breaking changes. since they were just released, no work has been done to make adjustments to account for the changes in semantic-release. if someone would be willing to investigate what changes would be needed, that could help us adjust for these changes sooner |
@travi yeah that makes sense. If we need to customize the preset though, we have to install it, and then it's easy to install the wrong version... so should we make this package check the version of the preset at runtime, and at least print a warning? I would almost suggest we put the compatible version in |
I understand the desire, but npm doesn't provide a great way to define these sorts of relationships. I'm open to proposals as a separate issue if there are options that I'm not aware of, but this is a difficult one to solve. I think the closest might be peerDependencies with meta defining the optional part, but I think there are complexities that make that not ideal too |
For folks landing here for various breakages related to updating conventional-commits packages before semantic-release is updated to handle the breaking changes, I'm trying to consolidate the conversation in this thread. Until I get more organized about that, please see my suggestions in semantic-release/semantic-release#3292 (comment) |
@travi not sure you saw my suggestion to check and warn at runtime if the preset package being used is not a known compatible version, would you be okay with a PR to do that? |
sorry. i did, but forgot to comment about that approach. it doesnt seem to me like there is a clean approach there either that is maintainable and still accomplishes the goal for new breaking changes. our approach to true peer dependencies and node versions is to keep them open ended, so we would have to release a new version with updated ranges once we are aware that a new major version is incompatible, which also requires responding fairly quickly to be most helpful. each of the conventional-commits packages has its own individual major version (an approach that i agree with), so we would have to handle each one individually. this also means more investigation when trying to release a version for such incompatibility communication. in the end, i think this almost entirely comes down to folks installing latest versions in pipelines without pinning a major version. would be open to suggestions to make this suggestion more clear and discoverable in docs or elsewhere in a general way that doesnt require maintainer action each time that breaking changes are released in conventional-commits packages. |
In my case it wasn't that - I was installing I can understand where you're coming from though. I can also understand the way all these different packages are structured. But - figuring out how to even customize everything and follow the control flow of release notes generation has left me thinking the work of fetching and parsing git commits and generating a changelog from them is spread out across too many packages for its own good. Maybe I would feel differently if these were all TS projects or the configuration was done via a strongly typed TS API rather than an unvalidated JSON DSL. It's pretty hairy to dig into how the configuration is getting passed around and used. And at least half of the code is for implementing that DSL that isn't really capable of doing what I want anyway, I wish I could just provide a function for filtering and categorizing commits by type and scope, etc, which would be way more flexible and require way less library code. |
We have the same issue..
|
I agree that is what people should do. However, the problem I found is that is currently hard to test if a major version bump will cause something to fail as we have semantic-release only running on our main branch. Implementing semantic-release/semantic-release#3278 would allow us to at least run with dry-run in a branch where we upgrade versions and see if anything breaks |
Hi @travi! I've just tried half of the possible configuration arguments and severely polluted the |
We can't yet rely on the SemVer tool semantic-release/release-notes-generator#633 (comment)
@ashvardanian the new beta of semantic-release is intended to work with the latest majors of conventional-changelog presets. As mentioned in the release notes, that means older version will no longer work. For the eslint preset, it looks like v6.0.0 is the latest version, but you're project is still configured to use v3. |
So what is the plan? |
I just asked myself that. currently my Semantic release is no longer running. my gitlab ci pipelines are standing still. |
There are two options available
|
Hi @travi! Thanks for suggestions! I've bumped all the versions in my {
"name": "simsimd-ci",
"version": "1.0.0",
"devDependencies": {
"@semantic-release/exec": "^6.0.3",
"@semantic-release/git": "^10.0.1",
"@semantic-release/commit-analyzer": "^12.0.0",
"@semantic-release/release-notes-generator": "^13.0.0",
"@semantic-release/github": "^10.0.5",
"conventional-changelog-eslint": "^6.0.0",
"semantic-release": "^24.0.0-beta.2"
},
"release": {
"debug": true,
"ci": false,
"dryRun": false,
"private": true,
"branches": [
"main"
],
"plugins": [ Then, when I run the following command locally: npx --prefix .github/workflows semantic-release --no-ci --no-npm --debug I'm still getting errors like:
Same happens if I remove any GitHub-related dependencies or steps. How can I "dry-run" the semantic release pipeline locally to avoid polluting the release history and the |
You do not need to/should not install the commit-analyzer or release-notes-generator plugins as direct dependencies, since they are already dependencies of semantic-release itself. If you test with |
@travi, I've just tried that locally and still face same issues.
What else would you recommend trying? |
I've tested with this and it resolved my issue. |
Would be nice if this was something that wasn't always discovered aftter an update was being made in a repo. |
Fixes the breakage from the latest commit analyzer release. Refs: semantic-release/release-notes-generator#633
A command like |
Fixes the breakage from the latest commit analyzer release. Refs: semantic-release/release-notes-generator#633
A. Create and securely store a GitHub Personal Access Token that has |
FYI, tried on self-hosted gitlab with python project and it works as expected. 🎉 script:
- npm install @semantic-release/gitlab @semantic-release/exec @semantic-release/changelog conventional-changelog-conventionalcommits @semantic-release/git -D
- npx semantic-release@24.0.0-beta.2 configuration of plugins:
- "@semantic-release/commit-analyzer"
- "@semantic-release/release-notes-generator"
- - "@semantic-release/changelog"
- changelogFile: CHANGELOG.md
- - "@semantic-release/git"
- assets:
- CHANGELOG.md
- - "@semantic-release/exec"
- prepareCmd: "poetry version ${nextRelease.version} && poetry build"
- - "@semantic-release/gitlab"
- assets:
- path: "dist/*.whl"
type: "package"
- path: "dist/*.gz"
type: "package"
- path: "CHANGELOG.md"
type: "runbook"
preset: "conventionalcommits" |
🎉 This issue has been resolved in version 14.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Thank you @sherbakovdev for contributing to getting this out the door and to @ryancausey and @imliuruiqi for testing out the fix and confirming that it solved the problem in your projects 🎉 |
It looks like v8.0.0 of conventional-changelog-conventionalcommits was released about an hour ago. This causes the semantic-release "generateNotes" step of plugin "@semantic-release/release-notes-generator" to fail:
Reverting conventional-changelog-conventionalcommits back to the v7.x.x series makes this release run fine again.
The text was updated successfully, but these errors were encountered: