Need Clarifications on Jenkins Automated CD Plugin Release Process

[Vahila]

Hi, 

I am exploring the new Jenkins automated CD plugin release process for our plugin releases and have a few questions based on the documentation. I would appreciate any clarifications you can provide: 

Q1. Release Triggering: My understanding is that every successful build of the default branch triggers a release, meaning each release would be associated with only one PR (assuming it has the appropriate label). However, I noticed that in the kubernetes-plugin, the latest release includes changes from multiple PRs. How is this achieved? Also, does the release happen when the PR is merged? When the release happens is a bit unclear to me. 

Q2. Automated Versioning: How is the automated version generated? For a single PR with one commit, the version format seems to be <some int>.<commit ID>, as seen with the log-cli plugin version 40.934670f4a9b8 triggered by a master push. How is the version determined when multiple PRs or commits are involved? 

Q3. PR Labels: The labels added to PRs are crucial as they determine whether a release occurs. Is there any documentation specifying which labels trigger a release and which do not? 

Thank you for taking the time to provide your insights. 

Best regards,
Vahila.

[Jesse Glick]

On Wed, Nov 13, 2024 at 2:46 PM Vahila <kayithiva...@gmail.com> wrote:

Q1. Release Triggering: My understanding is that every successful build of the default branch triggers a release

If at least one PR with an “interesting” label (so for example `bug` but not `dependencies`) has been merged since the last release.

in the kubernetes-plugin, the latest release includes changes from multiple PRs.

I think there were a few PRs merged in close succession, so the trunk build kept on getting interrupted. 

does the release happen when the PR is merged?

Not quite; it is triggered when there is a passing ci.jenkins.io build of the default branch. Normally that would happen within a few minutes of the PR being merged.

Q2. Automated Versioning: How is the automated version generated?

https://github.com/jenkinsci/jep/blob/master/jep/305/README.adoc#basic-usage

How is the version determined when multiple PRs or commits are involved?

The version is deterministic for a given commit, regardless of what chain of PRs led to it.

 

Q3. PR Labels: The labels added to PRs are crucial as they determine whether a release occurs. Is there any documentation specifying which labels trigger a release and which do not?

https://github.com/jenkinsci/.github/blob/1b5201fb8a46f811502f076272376dd72eea9e54/.github/release-drafter.yml#L9-L61 plus https://github.com/jenkins-infra/interesting-category-action/blob/78f4b74509528c18790d9c36b2cccb5b21ed3451/action.yaml#L9-L13

Feel free to update the docs page to clarify anything discussed above (in terms that make sense to you).

[Vahila]

Thank you for your inputs! I have few follow-up questions.

Q1. Our plan is leverage CD but to trigger the release explicitly, not on every push. In the version format, is it okay to have only a manually controlled semantic version(ex: 4.2.34) and not append the ${changelist}. Would we be able to leverage the CD without any issues? 

Q2. I wanted to understand the role of the Jenkins build and the CD using GitHub actions. My understanding is that on ci.jenkins.io CI build occurs and tests are run. And GitHub actions is used to upload the artifacts to Maven antifactory. Is this correct?

Thank you,

Vahila.

[Jesse Glick]

On Thursday, November 14, 2024 at 5:49:49 AM UTC-5 Vahila wrote:

Q1. Our plan is leverage CD but to trigger the release explicitly, not on every push.

That would not be “CD” would it?

 

In the version format, is it okay to have only a manually controlled semantic version(ex: 4.2.34) and not append the ${changelist}.

No, that is not supported. The design is that plugin versions are just ordered counters generated by machines and consumed by machines, not something a developer curates or a Jenkins administrator pays attention to. You should not need semantic versions because you should not make incompatible changes, and if you really are forced to, you will need to do a lot more work than just change some number and hope users notice—the expectation is that an admin will simply see a couple dozen plugin updates and accept them all.

Q2. I wanted to understand the role of the Jenkins build and the CD using GitHub actions. My understanding is that on ci.jenkins.io CI build occurs and tests are run. And GitHub actions is used to upload the artifacts to Maven antifactory. Is this correct?

Yes, the GHA workflow runs the Maven build all the way to the `deploy` phase with all tests and other validations disabled, with generic hardware/tools, which is why it is only run when the ci.jenkins.io build is passing.

[Jesse Glick]

By the way https://github.com/jenkins-infra/jenkins.io/pull/7686 should help clarify some things.

[Vahila]

Hi, 

Thank you for sharing the additional links and your inputs. I want to confirm that based on my understanding Semantic Versioning helps indicate the type of changes in a release(from user perspective - in case of option two of version format), but unique identification of release artifacts mainly relies on the machine generated  changelist.

Best regards,

Vahila.

[Daniel Beck]

On Tue, Nov 19, 2024 at 9:56 AM Vahila <kayithiva...@gmail.com> wrote:

Thank you for sharing the additional links and your inputs. I want to confirm that based on my understanding Semantic Versioning helps indicate the type of changes in a release(from user perspective - in case of option two of version format), but unique identification of release artifacts mainly relies on the machine generated  changelist.

There's support for a user-controlled prefix of the version number which you can use to approximate semver. This is generally discouraged though, it's very easy to get this wrong. IMO semver for plugins also suffers from not adequately modeling how "big" of a change something is. Major new features are more relevant to me as a user than a signature change in most cases. To mark a release as incompatible with prior versions and make that information appear in the plugin manager, Jenkins uses a different mechanism (look for hpi.compatibleSinceVersion).