Open tzachov opened 11 months ago
using latest versions
yes, your installation command installs the latest versions of all of those packages. the conventional-commits project released a major version of that package today that fails the tests within our projects in a similar way. see those failing PRs below:
since these versions were just released, we have not investigated. since it was a major version, breaking changes are expected, but the failure did not come from a problem with this project. rather you need to prevent your installation command from installing a version that is not compatible.
if you would like to investigate what it would take to update our plugins to be compatible with the new version, we welcome the assistance. however, you could install with a major version defined to avoid this problem in your project for now
- npm install -g semantic-release @semantic-release/gitlab @semantic-release/release-notes-generator @semantic-release/commit-analyzer conventional-changelog-conventionalcommits conventional-changelog-angular @semantic-release/exec @semantic-release/git
+ npm install -g semantic-release @semantic-release/gitlab @semantic-release/release-notes-generator @semantic-release/commit-analyzer conventional-changelog-conventionalcommits@6 conventional-changelog-angular @semantic-release/exec @semantic-release/git
I don't know if this is related, but our pipelines began to fail silently couple days ago. There is no error, the last line is [6:23:43 AM] [semantic-release] › ℹ Start step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
We are using currently the latest versions of the following:
... rather you need to prevent your installation command from installing a version that is not compatible.
With this I have a small problem. While I do agree that it would be best practice to use specific versions, it would be great that there would be some clear information on what version is supported and where. I don't know how tightly knit you are between different projects in semantic-release group and with conventional-changelog-conventionalcommit
, but some kind of coordination would be great to prevent these from happening or at least some kind of compatibility information in packages to help us see what is compatible with what.
I don't know if this is related, but our pipelines began to fail silently couple days ago. There is no error, the last line is
[6:23:43 AM] [semantic-release] › ℹ Start step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
We are using currently the latest versions of the following:
- semantic-release @semantic-release/npm
- @semantic-release/git
- @semantic-release/changelog
- @semantic-release/exec
- conventional-changelog-conventionalcommits
Did you find a fix for that? Or is it still failing?
I don't know if this is related, but our pipelines began to fail silently couple days ago. There is no error, the last line is
[6:23:43 AM] [semantic-release] › ℹ Start step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
We are using currently the latest versions of the following:
- semantic-release @semantic-release/npm
- @semantic-release/git
- @semantic-release/changelog
- @semantic-release/exec
- conventional-changelog-conventionalcommits
Did you find a fix for that? Or is it still failing?
Unfortunately I did not have time to test or debug it further. Our transition to semantic release built into our CI images has been slow, but luckily we already had it installed to it, including the plugins, so we simply removed the installation from our job so that it wouldn't use the latest but bit older ones.
If I have time to test it more tomorrow or day after, I will post the results here.
it would be great that there would be some clear information on what version is supported and where. I don't know how tightly knit you are between different projects in semantic-release group and with
conventional-changelog-conventionalcommit
, but some kind of coordination would be great to prevent these from happening or at least some kind of compatibility information in packages to help us see what is compatible with what.
i'm not sure what to say here @XC-. you are installing that dependency directly; not through semantic-release. we provide as much of this sort of information as we can through our definitions through package.json
properties. however, semantic-release
does not depend on conventional-changelog-conventionalcommits
and conventional-changelog-conventionalcommits
does not depend on semantic-release
, so most of that type of configuration does not apply here. even if we had something in our documentation, we do not have maintainers standing by to catch that one of the packages commonly used along side semantic-release
released a breaking change in order to update such documentation.
in the end, this is the role of semver. the package released a breaking change and communicated that fact through releasing a major version. if you are installing without considering that chance, semantic-release
cannot protect you from that directly.
I do agree that it would be best practice to use specific versions
short of using a specific version, we do at least recommend installing a specific major to prevent updating past a breaking change unintentionally. you would still need to remember to update that declaration, but renovate can help with that, even with inline versions in your installation command.
I don't know if this is related, but our pipelines began to fail silently couple days ago. There is no error, the last line is
[6:23:43 AM] [semantic-release] › ℹ Start step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
We are using currently the latest versions of the following:
- semantic-release @semantic-release/npm
- @semantic-release/git
- @semantic-release/changelog
- @semantic-release/exec
- conventional-changelog-conventionalcommits
Did you find a fix for that? Or is it still failing?
Unfortunately I did not have time to test or debug it further. Our transition to semantic release built into our CI images has been slow, but luckily we already had it installed to it, including the plugins, so we simply removed the installation from our job so that it wouldn't use the latest but bit older ones.
If I have time to test it more tomorrow or day after, I will post the results here.
Started to experience the same issue as @XC- today in most of our pipelines that use semantic-release. Our setup is the following:
.releaserc.json
{
"plugins": [
[
"@semantic-release/commit-analyzer",
{
"preset": "eslint",
"releaseRules": [
{ "tag": "FIX", "release": "patch" },
{ "tag": "FEAT", "release": "minor" },
{ "tag": "UPDATE", "release": "minor" },
{ "tag": "UPGRADE", "release": "minor" },
{ "tag": "BREAKING", "release": "major" },
{ "tag": "DOCS", "release": "patch" },
{ "tag": "CHORE", "release": "minor" },
{ "tag": "BUILD", "release": "patch" },
{ "tag": "REFACTOR", "release": "minor" },
{ "tag": "TEST", "release": "patch" },
{ "tag": "CI", "release": "patch" },
{ "tag": "PERF", "release": "minor" }
]
}
],
[
"@semantic-release/release-notes-generator",
{
"preset": "eslint"
}
],
"@semantic-release/github"
]
}
Workflow file:
- name: Semantic Release
uses: cycjimmy/semantic-release-action@v3
id: semantic
with:
extra_plugins: |
conventional-changelog-eslint
branches: |
[
'main',
{
name: 'alpha',
prerelease: true
},
{
name: 'beta',
prerelease: true
}
]
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Edit:
I was able to fix the issues by setting: extra_plugins: | conventional-changelog-eslint@4.0.0
it would be great that there would be some clear information on what version is supported and where. I don't know how tightly knit you are between different projects in semantic-release group and with
conventional-changelog-conventionalcommit
, but some kind of coordination would be great to prevent these from happening or at least some kind of compatibility information in packages to help us see what is compatible with what.i'm not sure what to say here @XC-. you are installing that dependency directly; not through semantic-release. we provide as much of this sort of information as we can through our definitions through
package.json
properties. however,semantic-release
does not depend onconventional-changelog-conventionalcommits
andconventional-changelog-conventionalcommits
does not depend onsemantic-release
, so most of that type of configuration does not apply here. even if we had something in our documentation, we do not have maintainers standing by to catch that one of the packages commonly used along sidesemantic-release
released a breaking change in order to update such documentation.in the end, this is the role of semver. the package released a breaking change and communicated that fact through releasing a major version. if you are installing without considering that chance,
semantic-release
cannot protect you from that directly.I do agree that it would be best practice to use specific versions
short of using a specific version, we do at least recommend installing a specific major to prevent updating past a breaking change unintentionally. you would still need to remember to update that declaration, but renovate can help with that, even with inline versions in your installation command.
@travi What I'm trying to say here, that package.json might not be the first place people look for compatibility information. I do agree that this might not be the correct place to discuss about this, as conventional-changelog-conventionalcommits
is being used via commit-analyzer
, so that might be the better place. Having the compatibility information visible in readme would be great and would provide the best visibility. A bit like some kubernetes tools are doing, though a single version might be enough in this case. Using the "latest and greatest" is completely on us, of course.
But I do suspect that somewhere there is another issue on semantic-release's end, and that is the silent fail. In situations like this, I would expect an error, not a completely silent fail. There was no indication of error in the logs, the execution just ended suddenly.
I don't know if this is related, but our pipelines began to fail silently couple days ago. There is no error, the last line is
[6:23:43 AM] [semantic-release] › ℹ Start step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
We are using currently the latest versions of the following:
- semantic-release @semantic-release/npm
- @semantic-release/git
- @semantic-release/changelog
- @semantic-release/exec
- conventional-changelog-conventionalcommits
Did you find a fix for that? Or is it still failing?
Unfortunately I did not have time to test or debug it further. Our transition to semantic release built into our CI images has been slow, but luckily we already had it installed to it, including the plugins, so we simply removed the installation from our job so that it wouldn't use the latest but bit older ones. If I have time to test it more tomorrow or day after, I will post the results here.
Started to experience the same issue as @XC- today in most of our pipelines that use semantic-release. Our setup is the following:
.releaserc.json
{ "plugins": [ [ "@semantic-release/commit-analyzer", { "preset": "eslint", "releaseRules": [ { "tag": "FIX", "release": "patch" }, { "tag": "FEAT", "release": "minor" }, { "tag": "UPDATE", "release": "minor" }, { "tag": "UPGRADE", "release": "minor" }, { "tag": "BREAKING", "release": "major" }, { "tag": "DOCS", "release": "patch" }, { "tag": "CHORE", "release": "minor" }, { "tag": "BUILD", "release": "patch" }, { "tag": "REFACTOR", "release": "minor" }, { "tag": "TEST", "release": "patch" }, { "tag": "CI", "release": "patch" }, { "tag": "PERF", "release": "minor" } ] } ], [ "@semantic-release/release-notes-generator", { "preset": "eslint" } ], "@semantic-release/github" ] }
Workflow file:
- name: Semantic Release uses: cycjimmy/semantic-release-action@v3 id: semantic with: extra_plugins: | conventional-changelog-eslint branches: | [ 'main', { name: 'alpha', prerelease: true }, { name: 'beta', prerelease: true } ] env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Edit:
I was able to fix the issues by setting: extra_plugins: | conventional-changelog-eslint@4.0.0
Same issue here, but using conventioanl-changelog-conventionalcommits instead of eslint. I am on GitLab so I don´t know how to fix it...
since we are seeing feedback about this issue in multiple locations, i've created a tracking issue to start to centralize the conversation. see #2929
Current behavior
Using GitLab CI, I run the following:
And I get this output:
Running the same code locally works fine.
Node version is 18.17.1
Expected behavior
Should run without an error
semantic-release
version21.1.1
CI environment
GitLab
Plugins used
@semantic-release/gitlab @semantic-release/release-notes-generator @semantic-release/commit-analyzer conventional-changelog-conventionalcommits conventional-changelog-angular @semantic-release/exec @semantic-release/git
semantic-release
configurationCI logs
(stated above)