Migrate to CD ?

[jonesbusy]

What feature do you want to see added?

Hi,

Should this repo migrated to CD ?

Release are confusing, the last one is 2.0 from 2020.

Perhaps we could have CD and pointing to the tag instead of a moving branch ? (with an updatecli manifest to bump the defaultVersion of the JcasC config on different controller config)

By using a tag we can also avoid checking out the library each time and setup caching on the controller

On the JCasC

cachingConfiguration:
  excludedVersionsStr: "master main feature/ release/ bugfix/ hotfix/ pull/"
  refreshTimeMinutes: 86400

Upstream changes

No response

[dduportal]

Release are confusing, the last one is 2.0 from 2020.

True that: the reason is that we used the "latest" tip since then. The infra team never had any issue with the "latest" pattern since then.

Mostly because auditing what happened during build can be done with the console output which prints the exact commit: when (e.g. not often) we needed it it was enough.

By using a tag we can also avoid checking out the library each time and setup caching on the controller

Caching is already set up: https://github.com/jenkins-infra/jenkins-infra/blob/64f94bd40c0290089b10638d452d3f64dc6abb33/dist/profile/templates/jenkinscontroller/casc/global-libraries.yaml.erb#L11-L13 that's why there are no slowness due to pipeline libraries.

=> That being said, it has been a justification for the past 4 years and I'm neither against of pro for this change (weak choice on my side as infra officed).
Keep in mind this choice means re-evaluating the ratio "effort in the PRs updating the library vs. keeping the latest pattern".

Your proposal could bring up other benefits:

• Less "bad surprises" for contributors
• Allow different testing patterns (we currently use https://www.jenkins.io/doc/book/pipeline/shared-libraries/#testing-library-pull-request-changes but it could change to testing a new version in a given PR)

@jonesbusy do you see other direct benefits?

[timja]

I'm ±0 its a bit more effort and delay for a change to make it there.

I'm slightly in favour of the easier approach of merging a pull request and its available.

but open to either

[jonesbusy]

Fine for me to keep it like that if there is no regression founds when merging on master (I guess the pipeline unit coverage is good enough).

Perhaps we could just "hide" the release if we always depends on master ?

So that contributors are not confused about outdated released

[timja]

Perhaps we could just "hide" the release if we always depends on master ?

Yeah that would be fine