Remove 2.361.x support

[MarkEWaite]

Drop 2.361.x from plugin BOM

• Use 2.387.x in example
• Drop 2.361.x from plugin BOM

https://www.jenkins.io/security/advisory/2023-03-08/ notes a security vulnerability in Jenkins versions prior to 2.375.4. Let's drop support for 2.361.x to reduce the testing load and to encourage users to upgrade and avoid security issues.

98% of the 96000 installations of git plugin 5.0 were already running 2.375.1 or newer as of 1 May 2023. Over 40% of all git plugin installations were using 2.375.1 or newer as of 1 May 2023. Retaining plugin BOM support for 2.361.x does not help our Jenkins users or developers enough to justify the effort maintaining it.

Users that are upgrading to within 6 months of the most recent release (about 1/3 of the total installed base) are upgrading both core and plugins.

Testing done

Prep run locally and a plugin test was run locally

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests - that demonstrates feature works or fixes the issue

[jglick]

My only concern is that a lot of plugins use 2.361.x as their baseline, aligning with the switch to Java 11, so they are going to stop seeing BOM updates. Should we begin pushing them to 2.375.x?

[MarkEWaite]

My only concern is that a lot of plugins use 2.361.x as their baseline, aligning with the switch to Java 11, so they are going to stop seeing BOM updates. Should we begin pushing them to 2.375.x?

I agree that many plugins use 2.361.x as their baseline. I think that we should push them to 2.387.x unless they have a specific reason to remain at 2.375.x.

When this pull request is merged, I plan to start that change on the 18 plugins that I most actively maintain so that they will switch to 2.387.3 as their minimum Jenkins version. Let me know if you see issues with that update. I no longer actively check things with anything older than 2.387.3, so it feels best to set the minimum Jenkins version to 2.387.3.

Beginning tomorrow with the release of 2.401.1, the "Choosing a Jenkins version" page will recommend 2.387.3 or 2.375.4 as preferred versions.

[basil]

The README has:

The UC currently maintains releases for the past 400 days so it is reasonable to retire BOMs for lines older than that, or otherwise when the number of accumulated version overrides becomes large.

In practice I don't think we've ever maintained a BOM line for more than 6-9 months due to the accumulation of small annoyances (such as having to add overrides to too many Dependabot PRs). That combined with the fact that we're apparently seeing (Pipeline? infrastructure?) scalability issues testing more than 4 lines might lead us to simply admit that the 400 day ideal in the README is too impractical:

The UC currently maintains releases for the past 400 days, so any BOM lines older than that should certainly be retired. Practical concerns usually lead to the retiring of a given line after 6-9 months.

[jglick]

Such an edit would be fine with me.

[jglick]

BTW I think you can remove full-test now?

[MarkEWaite]

BTW I think you can remove full-test now?

The first run of the pull request only evaluated the portion that is evaluated for dependabot pull requests. I assumed that I needed full-test to have it run the same steps that will be run on the master branch when it is re-run by a maintainer. Have I misunderstood the use of full-test?

[jglick]

I needed full-test to have it run the same steps that will be run on the master branch when it is re-run by a maintainer.

Right, I just mean once you have successfully tested the substantive changes using full-test, you can turn it off while doing stuff like editing README.md.

[jglick]

Looks like https://ci.jenkins.io/job/Tools/job/bom/job/master/1751/ failed at the infrastructure level. Unfortunately https://plugins.jenkins.io/github-checks/ (unlike https://docs.cloudbees.com/docs/cloudbees-ci/latest/scm-integration/enabling-scm-reporting#_cloudbees_scm_reporting_feature_benefits) includes the head rather than the tail of a failed shell step’s log, which is usually useless, and does not link to the execution/node/*/log/ for the build-terminating error.

[MarkEWaite]

I see a failure from bootstrap5-api testing in the log file of https://ci.jenkins.io/job/Tools/job/bom/job/master/1751/ that reports:

org.jenkins.tools.test.exception.PomExecutionException: mvn -B -V -e -ntp -Dmaven.javadoc.skip=true clean process-test-classes in /home/jenkins/agent/workspace/Tools_bom_master/target/pct-work/bootstrap5-api-plugin failed with exit status 1

I believe that I see the same failure locally when I run:

PLUGINS=bootstrap5-api bash local-test.sh

However, I'm not sure that test would ever pass on my machine, because it seems to need some configuration that I don't have.

When I checkout the most recently released bom tag 2102.v854b_fec19c92 (where it was working enough to release), the test still fails for me locally. I've installed nodeJS 14.16.1 as is used on ci.jenkins.io, but it fails with npm build error messages like:

[INFO] > bootstrap5-api@5.2.2 build /home/mwaite/hub/core/bom/target/pct-work/bootstrap5-api-plugin
[INFO] > node-sass --output-style expanded --source-map true --source-map-contents true --precision 6 etc -o target/bootstrap5-api/css
[INFO]
[INFO] {
[INFO]   "status": 1,
[INFO]   "file": "/home/mwaite/hub/core/bom/target/pct-work/bootstrap5-api-plugin/node_modules/bootstrap/scss/_maps.scss",
[INFO]   "line": 55,
[INFO]   "column": 16,
[INFO]   "message": "Undefined variable: \"$primary-text-emphasis-dark\".",
[INFO]   "formatted": "Error: Undefined variable: \"$primary-text-emphasis-dark\".\n        on line 55 of node_modules/bootstrap/scss/_maps.scss\n        from line 22 of etc/bootstrap-custom-build.scss\n>>     \"primary\": $primary-text-emphasis-dark,\n\n   ---------------^\n"
[INFO] }
[INFO] npm ERR! code ELIFECYCLE
[INFO] npm ERR! errno 1
[INFO] npm ERR! bootstrap5-api@5.2.2 build: `node-sass --output-style expanded --source-map true --source-map-contents true --precision 6 etc -o target/bootstrap5-api/css`
[INFO] npm ERR! Exit status 1
[INFO] npm ERR!
[INFO] npm ERR! Failed at the bootstrap5-api@5.2.2 build script.
[INFO] npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
[INFO]
[INFO] npm ERR! A complete log of this run can be found in:
[INFO] npm ERR!     /home/mwaite/.npm/_logs/2023-05-31T13_22_59_842Z-debug.log
[INFO] ERROR: "build" exited with 1.
[INFO] npm ERR! code ELIFECYCLE
[INFO] npm ERR! errno 1
[INFO] npm ERR! bootstrap5-api@5.2.2 full-build: `npm-run-all build css-rtl css-prefix`
[INFO] npm ERR! Exit status 1
[INFO] npm ERR!
[INFO] npm ERR! Failed at the bootstrap5-api@5.2.2 full-build script.
[INFO] npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
[INFO]
[INFO] npm ERR! A complete log of this run can be found in:
[INFO] npm ERR!     /home/mwaite/.npm/_logs/2023-05-31T13_22_59_851Z-debug.log

Are others able to successfully run

PLUGINS=bootstrap5-api bash local-test.sh

[timja]

I get the same error @MarkEWaite

[jglick]

I do too, but also on the last release, 854bfec. Checking #571 when this was introduced…works then (or rather fails with what looks like an unrelated error); bisecting…

[jglick]

@MarkEWaite it appears that #1896 introduced the regression. I am not sure why, and I am not sure why CI builds succeeded prior to now. I suspect that there is something nondeterministic about its build (using some resource from the Internet which changed recently).

[MarkEWaite]

Thanks! Would you propose the revert of #1896?

[jglick]

I have no idea. Perhaps jenkinsci/bootstrap5-api-plugin@df0d4e4 is the ultimate cause? @uhafner any comment?

[MarkEWaite]

I have no idea. Perhaps jenkinsci/bootstrap5-api-plugin@df0d4e4 is the ultimate cause? @uhafner any comment?

Fascinating that a commit from 26 March 2023 ( #1896) shows a failure.

I see the same failure in on my development machine. With the commit prior to #1896 , the PLUGINS=bootstrap5-api bash local-test.sh command works on my machine. With that commit, it fails. I'm running nodeJS version v14.16.1 but don't understand how we missed those failures in the intervening bill of material releases.

[uhafner]

Is this a problem with a specific commit of the bootstrap plugin or with the latest one? bootstrap5-api@5.2.2 is some weeks old.

[MarkEWaite]

Is the problem with a specific commit of the bootstrap plugin or with the latest one? bootstrap5-api@5.2.2 is some weeks old.

The original failure (and most interesting) is that the plugin bill of materials fails to complete its release process because the current bootstrap5-api plugin version in the plugin BOM master branch is failing when it runs tests. The same tests can be run from a clone of this repository with the command:

PLUGINS=bootstrap5-api bash local-test.sh

I don't understand why those tests are failing. If you can run the same command from a fork of this repository, you may recognize something in the failure that is not apparent to me.

[MarkEWaite]

Is the problem with a specific commit of the bootstrap plugin or with the latest one? bootstrap5-api@5.2.2 is some weeks old.

The more surprising problem (but lower priority) is that the command

PLUGINS=bootstrap5-api bash local-test.sh

fails on the commits since #1896 (late March 2023) , yet we've released multiple times since #1896 without detecting that failure. I like the suggestion from @jglick that there must be something in the downloaded components that has changed in order to cause tests to fail that were previously passing.

[uhafner]

The bootstrap plugin uses npm as a side process do download the actual bootstrap files from the npm registry.

I also noticed some compile errors while I switched to the lastet npm version. These went away after cleaning the npm _modules folder on disk. Maybe it helps to always clean those folders before building with maven?

PLUGINS=bootstrap5-api bash local-test.sh

I'll try to run that locally as well.

[kerogers-cloudbees]

Based on some quick searching, it may be necessary to import variables-dark before importing maps at https://github.com/jenkinsci/bootstrap5-api-plugin/blob/75d2a8cd7f5baf8eed98da5f37341cc084691417/etc/bootstrap-custom-build.scss#L22

[uhafner]

Based on some quick searching, it may be necessary to import variables-dark before importing maps at https://github.com/jenkinsci/bootstrap5-api-plugin/blob/75d2a8cd7f5baf8eed98da5f37341cc084691417/etc/bootstrap-custom-build.scss#L22

That file does not yet exist in Boostrap 5.2.3, or am I missing something?

It seems that my local folder still contained a wrong version. I cleaned now everything and get the same error now. I hopefully fixed that now in v5.2.3-1.

[jtnord]

What I noticed in the repo was that there is no .lock file (either package/yarn) so versions would IIUC float to "compatible" versions by default - hence causing the non-determinism?