chore(publish) only 'publish' when triggered by a tag to not avoid overriding existing tags

[dduportal]

This PR is a proposal to only publish the image (in the private controller trusted.ci.jenkins.io) when a tag is created in the repository, to limit the possibility of overriding an existing image.

It comes from the cases where a new platform is added for this image (new CPU architecture as in #1586 new OS version as in #1629, change in jdk defaults as in #1178 etc.).

Side tasks list:

• Release documentation process update: docs: update Docker image release step jenkins-infra/release#375
• Update the Multibranch job "Containers -> Controller" in trusted.ci.jenkins.io with the same setting as the agents ones, with only tags checking, no build of a tag older than 7 days, no branch tracking and scan every 5 minutes for new tags

What is changed

• Pipeline updated to:

  • Only trigger the "Publish" steps , on both Windows and Linux parallel branches, on tags
  • Set the environment variable JENKINS_VERSION from the 1st element of the tag (with - as separator) to make it available to the publication script AND allow suffix in tags.

• Publication script for Linux updated to:

  • Only build the Jenkins version $JENKINS_VERSION (remove the loop and factorized code)
  • Removed dead or unused code including the infamous is-published code
  • Avoid using intermediate variables when dealing with environment variables to be set
  • Simplify latest LTS and weekly retrieval

Testing done

As it might be hard to test, let's use the 2.405 weekly release as a "match".

However, the following were done locally:

• The script passes shellcheck analysis without any warn or error
• Calling with dry run and no $JENKINS_VERSION set fails as expected with an error message:

$ ./.ci/publish.sh -n
./.ci/publish.sh: line 8: JENKINS_VERSION: Variable $JENKINS_VERSION not set or empty.

• Calling with dry run and the latest weekly version builds the version in my local Docker buildx worker:

$ JENKINS_VERSION=2.404 ./.ci/publish.sh -n   
Dry run, will not publish images
Using the following settings:
* JENKINS_REPO: jenkins/jenkins
* JENKINS_VERSION: 2.404
* JENKINS_SHA: c11e0391a46708680b35ed2abb47a6b513d0a1541bba1549779abbcdb313f996
* COMMIT_SHA: d23ea1a235881b54c37d5368f17a7f7799dfe1ca
* LATEST_WEEKLY: true
* LATEST_LTS: false
[+] Building 1.4s (20/48) 
# ...

• Calling with dry run and the latest LTS version builds the version in my local Docker buildx worker:

$ JENKINS_VERSION=2.387.2 ./.ci/publish.sh -n   
Dry run, will not publish images
Using the following settings:
* JENKINS_REPO: jenkins/jenkins
* JENKINS_VERSION: 2.387.3
* JENKINS_SHA: f40374910de94c9c1aafbd0fd190156e7f6afad6dc1534e1b55d20e125156be5
* COMMIT_SHA: d23ea1a235881b54c37d5368f17a7f7799dfe1ca
* LATEST_WEEKLY: false
* LATEST_LTS: true
[+] Building 506.0s (137/298) 
# ...

Not covered by this PR but worth doing after it's merged

• Update the Windows publication process (only Linux is covered here) because Update Jenkins version for Windows Image #1490
• Split into lts and weekly branches instead of master to allow fixing the Jenkins version in the code
• Utilizes an automated process such as Dependabot/Renovabot/Updatecli to keep Jenkins version up to date
• Use declarative pipeline syntax which is easier to read and maintaing in simple cases like this one

[NotMyFault]

LGTM.

Can we add the release team to this repository then to cut tags during the LTS process, to prevent delays, please?

[NotMyFault]

LGTM.

Can we add the release team to this repository then to cut tags during the LTS process, to prevent delays, please?

[dduportal]

LGTM.

Can we add the release team to this repository then to cut tags during the LTS process, to prevent delays, please?

@NotMyFault do you mind if we wait to validate the new process first? I don't mind taking care of tagging for the weeklies.

The reason I'm asking is because the discussion about adding the release team as writer or maintainer (to allow creating tags) should be separated from this PR to validate the permission pattern.

=> Keep in mind that ideally, we should have automation of this (e.g. the tag would be created by the automated release process) to avoid further human operation.

[dduportal]

Ping @timja @MarkEWaite WDYT?

[MarkEWaite]

This looks good to me.

[dduportal]

Since I got 2 maintainers approval + a board member approval, I'm proceeding to merge this PR.
I'll report here once the trusted.ci.job will be updated (as soon as possible)

[dduportal]

Job updated in trusted.ci.jenkins.io:

• Disabled the old one (no need to remove it immediatly, better keeping it if a rollback is needed and for comparing courses).
• Only current tags (~10) were found and no build triggered as expected.

For info, I won't start working on the Windows release until we've validated the current Linux publication (one step after the other) but that would be the next step.