exec plugin with successCmd can causes *first release only* of maintenance branch to fail #3523
-
|
Hello I have a problem when using module.exports = {
branches: [
'+([0-9])?(.{+([0-9]),x}).x',
'release',
],
plugins: [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
[
"@terrestris/maven-semantic-release",
{
"settingsPath": process.env.MAVEN_SETTINGS,
"clean": false,
"updateSnapshotVersion": "true",
"processAllModules": "true"
}
],
[
"@semantic-release/git",
{
assets: ["**/pom.xml"]
},
],
"@semantic-release/gitlab",
["@semantic-release/exec", {
"publishCmd": "echo VERSION_BUILD=${nextRelease.version} > version.env",
"successCmd": "cat version.env && touch RELEASE_DONE"
}]
],
};which gives this execution log : in this execution log, you can see that there are two lines and there is no commit analyzer ran at all. Complete log is here execution.log Can some tell me what's wrong in my settings there please ? |
Beta Was this translation helpful? Give feedback.
Replies: 7 comments 21 replies
-
|
@travi I'm really sorry to pinging you so rudely, but can you have a look at my question which really blocks me please 🙏 |
Beta Was this translation helpful? Give feedback.
-
|
based on a quick look, i dont see anything obvious. order of defining the plugins is important in your config, but it looks like that is correct already. this suggests that it should be ready to be used:
if you arent already, you could try to use the debug flag when you execute. you may need to create a minimal reproduction in a public project for us to dig further from this side. |
Beta Was this translation helpful? Give feedback.
-
|
Hello @travi Thank you for taking time to help me. |
Beta Was this translation helpful? Give feedback.
-
|
forgot to give you plugins versions |
Beta Was this translation helpful? Give feedback.
-
|
You don't need to install commit analyzer or release notes generator directly since they are already dependencies of semantic-release.
You have to many variables. You need to start by narrowing down the situation and understanding which variable is causing the behavior difference. Adding more variables makes it even harder to suggest what the true issue might be.
As mentioned before, without a minimal public reproduction, there is not much I can do beyond what is not obvious from the logs. By creating a public reproduction, you can also try to reduce the problem and maybe even identify the problem yourself. I want to help you, but you have to help me do so. My time available to provide support is limited, so the more you can help me optimize that to focus on the true problem, the more helpful I can be |
Beta Was this translation helpful? Give feedback.
-
|
Hello @travi BUT, if I run it a second time after the failure, then the second time it will work surprisingly. From my understanding it has to do with the fact that during second execution, the channel stuff is not exactly the same than during first one. Another test for a branch where exec plugin is not used : it works at the 1st time : https://gitlab.com/djeanprost/semantic-release-issue/-/jobs/8533673385 So if you have any idea with that, I take it. |
Beta Was this translation helpful? Give feedback.
-
|
@pvdlg ? sorry for getting you there, but maybe you can help with this bug-a-like ? |
Beta Was this translation helpful? Give feedback.
-
when you are releasing a maintenance version, does a release for the range defined for the branch already exist or are you creating the maintenance branch with the expectation that the first release for that range will be created? i havent had the time to completely confirm my suspicion, but it looks like you are approaching this workflow expecting the latter |
Beta Was this translation helpful? Give feedback.
-
what you are describing is gitflow, which is a workflow that is not officially supported by semantic-release. while semantic-release is configurable enough to simulate gitflow, we do not recommend it and do not provide support for such configuration. it is a "at your own risk" situation if you choose to follow gitflow with semantic-release
i think we are back to this request. while making a public reproduction helped me understand your intended workflow better, it skipped over the "minimal" part of the request. in order to dig deeper into this situation, we need to reproduce this in the context of the supported workflows. deviating from the supported workflows introduces variables beyond your theory that the exec plugin is the cause. that means we need a configuration where the primary release branch is the default branch and all features are merged to the default branch rather than through a develop branch first. this can help us eliminate the unsupported workflow from the equation and determine if your theory of being related to the exec plugin is correct |
Beta Was this translation helpful? Give feedback.
-
|
Hello @travi module.exports = {
branches: [
'+([0-9])?(.{+([0-9]),x}).x',
'main',
],
plugins: [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
[
"@terrestris/maven-semantic-release",
{
"clean": false,
"mavenTarget": "package jib:build",
"updateSnapshotVersion": false,
"processAllModules": true
}
],
[
"@semantic-release/git",
{
assets: ["**/pom.xml"]
},
],
"@semantic-release/gitlab",
["@semantic-release/exec", {
"publishCmd": "echo VERSION_BUILD=${nextRelease.version} > version.env",
"successCmd": "cat version.env && touch RELEASE_DONE"
}]
],
};release-job:
stage: release
rules:
# This branch definition has to be the same than the branch configured in semantic release
- if: $CI_COMMIT_REF_NAME == "main" || $CI_COMMIT_REF_NAME =~ /^[0-9]+\.[0-9]+\.x$/
image: $MAVEN_IMAGE_NAME
variables:
NODE_OPTIONS: "--disable-warning=ExperimentalWarning"
DEBUG: "semantic-release:*"
before_script:
- curl -fsSL https://deb.nodesource.com/setup_23.x -o nodesource_setup.sh
- bash nodesource_setup.sh
- apt-get install -y nodejs
- node -v
- echo "Node is installed"
script:
- npm install semantic-release@24
- npm install @semantic-release/gitlab@13
- npm install @terrestris/maven-semantic-release@3
- npm install @semantic-release/exec@6
- npm install conventional-changelog-conventionalcommits@8
- npx semantic-release --extends ./semantic-release-config.jsAnd this will give the same results I've been struggling with :
--> Back from the start I hope this will help you to drill down on what is the cause of the problem, and by the way I really thank you for helping. The lead that seems the most interesting to me even if I'm limited in my understanding of it is @kilianpaquier question : #3523 (comment) Looking forward reading from you 😄 |
Beta Was this translation helpful? Give feedback.
-
|
@travi any updates on your side maybe 😁 ? |
Beta Was this translation helpful? Give feedback.
-
|
@travi sorry for being so rude, but this issue is still with no solution 😐. From my point of view, I reproduced everything you requested. If there are still missing feedback from me, please don't hesitate to ask |
Beta Was this translation helpful? Give feedback.
-
|
i'm sorry that i don't have a better answer for you. we appreciate the effort you've already put into reproducing this problem. i've investigated far enough to believe that it will take quite a bit of effort to really get to the bottom of this. unfortunately, i have not had the time lately to dedicate that level of focus to this. if getting past this is important to you, you are likely to get to an answer by investigating more deeply yourself and sharing your findings. in the end, we will need to reproduce whatever problem is causing this as a test, so as you investigate keep that in mind in case it can help guide you to the steps we'll need to get to for this to get resolved. |
Beta Was this translation helpful? Give feedback.
-
|
Hi ! Could it come from the fact that for this bloc of semantic-release execution, only Lines 110 to 153 in 6022328 However, at first glance, I don't see why it would work the second time ... What makes me say it could come from here (may be an expected behavior) is that on @djeanprost first CI error, this line appears Found 4 commits since last release and then it goes straight to From the look of it, the only execution succession giving this is there. And it does seem that this execution flow is specific to maintenance branches ? Lines 117 to 121 in 6022328 |
Beta Was this translation helpful? Give feedback.
-
the only difference I can see in 1st execution and in 2nd one is that on 2nd one, channel 1.2.x is already present on the tag/branch. I guess it was added on first time. |
Beta Was this translation helpful? Give feedback.
-
|
in attempting to look into this issue, i've been looking through historical discussions to see if others have come across any similar behaviors. while doing so, i spotted a previous thread that you started where you mentioned behavior that wasnt working correctly with the first execution, but was working with a second run. i see that i didnt manage to respond to that one, so apologies for that. did you end up solving that situation? it is interesting that you've seen misbehavior on first run but correct behavior on a second run in both cases. this makes me further wonder if there is something about your workflow that i havent grasped yet that might be presenting this situation. you havent described anything yet that gives me any real confidence that this is the case, but this is at least an interesting pattern that stands out to me |
Beta Was this translation helpful? Give feedback.
-
|
Hello @travi Indeed there could be something in my branch workflow or release management, I agree. But what I cannot understand is that depending on the presence of exec plugin, it works well or not.
The only difference I can spot in 1st and 2nd run with exec plugin is that at first time, channel is not set on the maintenance branch, and during 2nd one, it's set (I guess by previous run), although it's not present too on single run when exec plugin is not used. Do you need write access to my personnal repo to test on your side or reproduce something ? I can give you permission if you request it. |
Beta Was this translation helpful? Give feedback.
-
|
@travi Did you have a look at what is mentionned here ? #3523 (comment) At least from what is said, the piece of code that is highlighted could explain something ? |
Beta Was this translation helpful? Give feedback.
-
|
Hey @djeanprost, After looking at this and the threads in this discussion, I think there's an imperative part of the error that you might be unintentionally leaving it out.... See below.. It point out how the BUT the WEIRD BUT is that the Why? How come the |
Beta Was this translation helpful? Give feedback.
-
|
Hello @babblebey |
Beta Was this translation helpful? Give feedback.
-
|
Hello @travi, After further investigation, it's really coming from here: https://github.com/semantic-release/semantic-release/blob/master/index.js#L151 What is happening:
Why does it fail on @djeanprost specific case ?Simple, Multiple questions come to mind with this specific discussionHistorically, from oldest to newest (yes I checked previous commits impacting this code), it seems tags were created, which was a justified reason to call Which poses with, do we still need to run 7b40524#diff-e727e4bdf3657fd1d798edcd6b099d6e092f8573cba266154583a746bba0f346R112-R123 aec96c7#diff-e727e4bdf3657fd1d798edcd6b099d6e092f8573cba266154583a746bba0f346R109-R122 b2c1b2c#diff-e727e4bdf3657fd1d798edcd6b099d6e092f8573cba266154583a746bba0f346L112-R115 Another question that comes to my mind, and I can backup it with this pull request and gitlab run (thanks @djeanprost):
It seems on top of that, that this |
Beta Was this translation helpful? Give feedback.
-
|
As a test, I removed the Thanks everybody for helping. Changed discussion title to reflect this diagnosis. |
Beta Was this translation helpful? Give feedback.
-
|
thank you for the further investigation. i will be largely afk for the next couple of weeks before i can attempt to dig deeper to catch up on my understanding. i think the recommendation i can give in the mean time is that we will need a reproduction in a test to get this resolved. if someone would be willing to add a test to our e2e suite in this project, i think that will be the best place to reproduce this issue fully. while this surfaced using the exec plugin, i think it would be best to simulate the problem without adding a dependency on the actual exec plugin to the project. it should be possible to set up the test using a faked out plugin to accomplish a similar issue. if you run into any problems with the test, feel free to create a draft pr and ask us questions. we will try to help you further as we have availability |
Beta Was this translation helpful? Give feedback.
Hello @travi,
After further investigation, it's really coming from here:
https://github.com/semantic-release/semantic-release/blob/master/index.js#L151
What is happening:
1.3.01.4.0,1.5.0, etc.1.3.0for any justified reason (security, etc.)1.3.xand push (directly or with a pull request it doesn't matter) the appropriate fix on it1.3.1