Set Releng pipeline library version to main

[mbarbero]

I strongly discourage to reference main in the config.

Tags are referenced so that dev can continue to develop, test and fix stuff, without impacting all sites that use the library.

Tag should be updated only once changes have been tested and validated and that the new version does not cause regression.

One can can always test newer version by overriding the import of the library on 1 test site, e.g., library 'my-shared-library@main'

There is also a caching issue with:

         cachingConfiguration:
           excludedVersionsStr: "main"

caching is used to speed up build (no need to fetch code at every single build) and main is excluded as it's a moving target, while tags are supposed to be immutable.

Even if you use feat/myfeat branches for dev, you will need to exclude those branches from caching as well, or deactivate caching entirely (that I strongly discourage).

[heurtematte]

My goal is to avoid modifying JIRO every time we fix a bug or add a new feature to the Jenkins Pipeline Library. I believe it's a waste of time to deal with JIRO while testing or developing new functionalities for the library.

Current process

To summarize the current process when I need to develop, test, and provide a fix in production:

• Development is done on the master branch.
• Testing a development version involves changing the import declaration in the Jenkinsfile as follows: library 'my-shared-library@main'.
• Tag a version from the master branch.

JIRO part:

• Apply changes in the JIRO project.
• Create a pull request.
• Regenerate Jenkinsfile.
• Restart configuration as code.

Note:

• The main branch is not cached, while all other branches are cached by default.

Proposition

I propose the following process:

• Development is done on a new branch (not the master, which becomes protected by default) following the usual convention: feat/my_feat_name, fix/my_fix, etc.
• Change the Jenkins configuration by adding the temporary branch name as not cached, similar to the master branch.
• Testing a development version involves changing the import declaration in the Jenkinsfile as follows: library 'my-shared-library@feat/my_feat_name'.
• Once finished, remove the Jenkins configuration.
• Merge the merge request (MR) into the master.

Note:

• The main branch is still not cached.

Conclusion

In the second approach compared to the first:

• Everything is done in only one project.
• There is no need for Jenkins configuration redeployment.

The weak point is an manual interaction with jenkins configuration and cache management, but in my opinion, the impact is very low:

• It concerns only two 'internal' Jenkins instances.
• Only around 20 files need to be downloaded each time.
• Build time and build activities are also quite low.
• And in any case, playing jiro as code for nay upgrade, will reset the forgotten configurations

In my opinion, we benefit from following this path instead of applying a tag convention. This approach aligns with the GitHub Flow, which may not be the best, but it suits well this use case.

[mbarbero]

GitHub flow is not about "always deploy from main". It does not promote getting rid of a release/deployment process with proper versioning.

I still think that deployment should be tagged properly for repeatability and traceability. It provides an easy way to rollback to a known state. It also reduces the incentive to commit a quick fix to production that just breaks everything...

• Development is done on the master branch.

if you prefer github flow, you can do that in a branch, it's fine.

• Testing a development version involves changing the import declaration in the Jenkinsfile as follows: library 'my-shared-library@main'.

No, you don't need to change that in the Jenkinsfile, you can use the simpler "replay" feature from Jenkins. It gives you the ability to change the Jenkinsfile for the duration of a run: https://pushbuildtestdeploy.com/using-jenkinss-replay-feature-to-work-on-without-repeatedly-committing-the-jenkinsfile/.

• Tag a version from the master branch.

This step is basically doing a release. I think it's beneficial, as it's a way to convey the mean that "we've done dev, test, and QA, and we grade this commit as production-ready". Also, if something breaks, with github flow where you delete the dev/feature branch (as recommended), it's less obvious to which commit to rollback to.

JIRO part:

• Apply changes in the JIRO project.
• Create a pull request.

I'm not sure I get the "Create a pull request" part. You mean to push the changes to JIRO?

• Regenerate Jenkinsfile.

If you use the "replay" feature from Jenkins, you don't need to "Regenerate Jenkinsfile" (I guess you mean by that reverting the change to specify library my-shared-library@main

• Restart configuration as code.

This should be quite short and straightforward and should not be a paint point.

All in all, I still strongly discourage this change as I'd rather prefer the stability and predictability of the tag approach, especially given the little costs of it.

@fredg02, I'm not maintaining all of this anymore, so it's up to you!

[heurtematte]

GitHub flow is not about "always deploy from main". It does not promote getting rid of a release/deployment process with proper versioning.

The github flow philosophy is once a feature has been merged to main it should be released to production immediately. Or I missed something.

Regenerate Jenkinsfile

My mistake: Regenerate Jenkinsfile => Regenerate Jenkins files.

No, you don't need to change that in the Jenkinsfile, you can use the simpler "replay" feature from Jenkins. It gives you the ability to change the Jenkinsfile for the duration of a run

It was I meant, I should have be more specific.

. I think it's beneficial, as it's a way to convey the mean that "we've done dev, test, and QA

But since there are not real test, and Q/A...

less obvious to which commit to rollback to.

Two approaches: revert commit, or hot fix. I would propose a hot fix, and never touch the git history.

This is a pragmatic proposal for our context and for this project. If the team really discourage this approach, no problem to keep the current way.

[heurtematte]

@fredg02 can we status on this? otherwise it will break next LTS upgrade for the webdev team.

[fredg02]

Since it only affects our two internal instances, I'm with Mikael on this one.