Disable automatic release for bitbucket-branch-source-plugin

[nfalco79]

Link to GitHub repository

https://github.com/jenkinsci/bitbucket-branch-source-plugin

I need to disable automatic release becuase:

• I need to test master code in our environment and only after this period that I want to release (actually I have to create PR with an interesting tag);
• release will happens because of tag in PRs. But those tag when set by the PR author trigger a release when merge. It has already happened to me that I didn't remember to check tags at the merge time and a release came out even if I didn't want to;
• in Github commit page I'm not able to understand if a specific commit in which release has been released. I have to choose tag filter than select next or previous tag to see when the commit appear in the list. Manual release using maven plugin add specific commits. Otherwise I have to be behind a PC with a local git client, often I see and respond to the PR or issue using phone.
• actually master is waiting the git-plugin to be released, but I would release an hot fix. Using manual release I can do in a separate branch (support branch for example) using semantic versioning

There are IRC Bot commands for it.

[rsandell]

IMO master should be always releasable. So if there are commits/features that you are unsure about then put them on a staging branch and build a test version from there.

[nfalco79]

IMO master should be always releasable.

In a CI/CD yes. I want manage this plugin like I do for nodejs/xunit/dependency-check. Use semantic versioning and be able to use gitflow with support branch (if needed, rarely but something "shit happens" as Forrest Gump said)

So if there are commits/features that you are unsure about then put them on a staging branch and build a test version from there.

I should test more PR in parallel switching our production each time. For me it's time consuming.
When PR goes well from a review standpoint, I release the author from ongoing updating and conflict resolution, and then take it upon myself to test all changes a bit before deciding whether to publish.

[alecharp]

So, first, you could just remove the .github/workflow/cd.yaml definition from the workflow and that would remove the CD. This, here, will make it fail until you remove that file.

Then, if you want to use gitflow, great, but then why not create a develop branch, make it the default one, so that all pull requests are targeting it. You could then tweak the CD process to work only on the master branch. This way, you can quickly merge the pull requests, test the content of the default branch on your systems and release (merge into master) when you are ready, with very limited manual operations.

[nfalco79]

So, first, you could just remove the .github/workflow/cd.yaml definition from the workflow and that would remove the CD. This, here, will make it fail until you remove that file.

This was missing to me, thanks (done with jenkinsci/bitbucket-branch-source-plugin#942)

Then, if you want to use gitflow, great, but then why not create a develop branch, make it the default one, so that all pull requests are targeting it. You could then tweak the CD process to work only on the master branch. This way, you can quickly merge the pull requests, test the content of the default branch on your systems and release (merge into master) when you are ready, with very limited manual operations.

If I'm allowed to do these settings I could try. Anyway I want disable automatic release because it does not use the maven-release-plugin (3rd point above)

[alecharp]

If I'm allowed to do these settings I could try.

You're a maintainer of the plugin. You can maintain the plugin as you wish. Just be careful that you are not the only maintainer listed for the plugin, so you might want to make it clear to others what you want to do. Maybe you won't be the only one to cut releases (which is why the CD pipeline is good).

Anyway I want disable automatic release because it does not use the maven-release-plugin (3rd point above)

True, but there is no real "reason" to use it. The plugin is in fact just a succession of command. The CD action is almost doing the same thing (https://github.com/jenkins-infra/jenkins-maven-cd-action/blob/master/run.sh) in a different order.

[alecharp]

@nfalco79 I know this is resolved but I wish I thought of it earlier: the plugin is producing incremental builds. This means you should be able to install a build from a pull request, just as if it was released. This without merge the pull request too soon. Have you tried to look this way for your process?

[nfalco79]

I know this is resolved but I wish I thought of it earlier: the plugin is producing incremental builds. This means you should be able to install a build from a pull request, just as if it was released. This without merge the pull request too soon. Have you tried to look this way for your process?

I know about incremental builds, and they don't solve the above points. Plugin is yet producing incremental builds.
I usually use them by asking the reporter if he can install the build produced by the PR in his environment and do a roundtrip to know if the problem is solved. I use them when I can't test them myself because the conditions to replicate the problem are too complex...
I tried the automatic release for the first time with this plugin and I had to fight with it all the time like "Don Quixote of La Mancha", it's not for my lifecycle.
I also update README.MD in the root of the plugin.
Anyway thank for your notes

[jglick]

I need to test master code in our environment and only after this period that I want to release

You do not need to turn off CD-type releases to do that. You just configure the repository to avoid automatic release. This was always possible, but was refined somewhat in jenkins-infra/github-reusable-workflows#32.

in Github commit page I'm not able to understand if a specific commit in which release has been released

A commit will show all the releases it includes. For example jenkinsci/workflow-cps-plugin@82eabc0 links to https://github.com/jenkinsci/workflow-cps-plugin/releases/tag/3996.va_f5c1799f978 through https://github.com/jenkinsci/workflow-cps-plugin/releases/tag/4007.vd705fc76a_34e.

Using manual release I can do in a separate branch

You do not need to release manually in order to create backports. You just create an appropriate branch, push to it, and trigger releases from GHA. https://gist.github.com/jglick/86a30894446ed38f918050c1180483e2

While it is ultimately up to the plugin maintainer to decide how to work, CD versions are generally encouraged and I do not think any of the stated justifications are valid. Perhaps https://www.jenkins.io/doc/developer/publishing/releasing-cd/ is incomplete.

[jglick]

@nfalco79 FYI https://plugins.jenkins.io/cloudbees-bitbucket-branch-source/releases/ shows https://plugins.jenkins.io/cloudbees-bitbucket-branch-source/releases/#version_933.v7119e94e8f56 as newer than the manual releases, which may be contributing to the confusion in https://community.jenkins.io/t/bitbucket-branch-source-plugin-error/25717?u=jglick

[nfalco79]

Thanks, I will release tonorrow a 934.3.1 same as 933.3.1