Closed greetclock closed 3 years ago
As I understand your configuration you're performing a regular backmerge from master
to develop
.
Can't see how the change you mentioned would affect that, as the behaviour should be the same as before.
Maybe someone pushed to develop branch while semantic-release was running?
That would explain the error message that the branch is behind develop
.
Please let me know if that's the case. :)
@saitho thank you for your response!
Yes, as you correctly notice, this is a regular backmerge from master
to develop
. However the error appears in develop
branch. When I rollback to 1.1.3 then I get this message and the CI job completes successfully:
[10:01:25 AM] [semantic-release] [@saithodev/semantic-release-backmerge] › ✖ Branch for back-merge is the same as the branch which includes the release. Aborting back-merge workflow.
Maybe someone pushed to develop branch while semantic-release was running?
Regarding your suggestion about concurrent push from someone else, I get the error consistently in 1.2.0 and it works as expected in 1.1.3; I've tried it multiple times in different repositories. At the same time, the push does happen indeed, it is initiated by semantic-release
itself. What I think, I'm getting something like this:
fix:
prefix is pushed to develop
.semantic-release
detects it and prepares the new version in the next
channel (the channel that I use for releases in develop
).semantic-release
makes a commit that updates version in package.json
and also adds changes to changelog.md
semantic-release
pushes the new commitThe reason why I think that the commit I mentioned affects the pipeline is that in 1.1.3 there was this warning/error message and the plugin exited immediately. After the commit, the plugin reaches the push step in any case. Of course, without your expertise in building the plugin I can only guess why the changed behaviour (1.1.3 vs 1.2.0) might appear. What do you think about it?
For now, as a temporary solution, I'm rolling back to 1.1.3 in my repos.
Thanks for your detailed reply.
I myself don't use develop
branches anymore, so I don't use this plugin.
I'll try create a test setup and take a look at it.
Hi @cherurg,
I finally was able to take some time to investigate that. I've created a test repository here: https://github.com/saitho/backmerge-test
v1.0.0 was released from master and backmerged into develop:
[3:58:49 PM] [semantic-release] › ✔ Created tag 1.0.0
[3:58:49 PM] [semantic-release] › ℹ Start step "publish" of plugin "@semantic-release/npm"
[3:58:49 PM] [semantic-release] [@semantic-release/npm] › ℹ Skip publishing to npm registry as npmPublish is false
[3:58:49 PM] [semantic-release] › ✔ Completed step "publish" of plugin "@semantic-release/npm"
[3:58:49 PM] [semantic-release] › ℹ Start step "success" of plugin "@saithodev/semantic-release-backmerge"
[3:58:49 PM] [semantic-release] [@saithodev/semantic-release-backmerge] › ℹ Release succeeded. Performing back-merge into branch "develop".
[3:58:50 PM] [semantic-release] [@saithodev/semantic-release-backmerge] › ℹ Loading plugins
[3:58:50 PM] [semantic-release] [@saithodev/semantic-release-backmerge] › ℹ Executing "done" step of plugins
[3:58:50 PM] [semantic-release] [@saithodev/semantic-release-backmerge] › ℹ Found 0 staged files for back-merge commit
[3:58:54 PM] [semantic-release] › ✔ Completed step "success" of plugin "@saithodev/semantic-release-backmerge"
[3:58:54 PM] [semantic-release] › ✔ Published release 1.0.0 on latest channel
v1.1.0-next.1 was released from develop and also succeeded:
[4:01:48 PM] [semantic-release] › ✔ Created tag 1.1.0-next.1
[4:01:48 PM] [semantic-release] › ℹ Start step "publish" of plugin "@semantic-release/npm"
[4:01:48 PM] [semantic-release] [@semantic-release/npm] › ℹ Skip publishing to npm registry as npmPublish is false
[4:01:48 PM] [semantic-release] › ✔ Completed step "publish" of plugin "@semantic-release/npm"
[4:01:48 PM] [semantic-release] › ℹ Start step "success" of plugin "@saithodev/semantic-release-backmerge"
[4:01:48 PM] [semantic-release] [@saithodev/semantic-release-backmerge] › ℹ Release succeeded. Performing back-merge into branch "develop".
[4:01:49 PM] [semantic-release] [@saithodev/semantic-release-backmerge] › ℹ Loading plugins
[4:01:49 PM] [semantic-release] [@saithodev/semantic-release-backmerge] › ℹ Executing "done" step of plugins
[4:01:49 PM] [semantic-release] [@saithodev/semantic-release-backmerge] › ℹ Found 0 staged files for back-merge commit
[4:01:49 PM] [semantic-release] › ✔ Completed step "success" of plugin "@saithodev/semantic-release-backmerge"
[4:01:49 PM] [semantic-release] › ✔ Published release 1.1.0-next.1 on next channel
So both cases worked for me. I've tried that with Github Actions and DroneCI as Continuous Deployment tool.
I'll restore the old behaviour (aborting when source == target) and add a option to disable that behaviour. That should do the trick.
@cherurg Can you try v1.2.1? ;)
Thanks for your detailed reply.
I myself don't use
develop
branches anymore, so I don't use this plugin. I'll try create a test setup and take a look at it.
I'm considering using this plugin. What are you using instead of a develop
branch? Back merging seems to be the only way to keep the pre-release version up to date with semantic-release.
@ccrowley96 I don't have prereleases on my projects. I'm developing features in separate branches and merge them to master when they're ready, immedialy creating a release.
@saitho it works for me now, thanks! I've sent you a tip via Brave, as you seem to be a registered creator there
@saitho it works for me now, thanks! I've sent you a tip via Brave, as you seem to be a registered creator there
Great it works! Oh, yes I am on Brave. Thanks a lot! :)
Hi! First of all, thank you for the great plugin!
I've been using it for some time. Recently I noticed that it causes a CI pipeline to fail. After some debugging I found that downgrading from 1.2.0 to 1.1.3 fixes the pipelines. Please, may I ask you to help me when it's the most convenient for you? I saw this commit and I think that it was the reason of the changed behaviour. However I can't really suggest off the top of my head why would it cause the error
Here is the error log and the config I use: