[JENKINS-66177] Ability to disable Java 11 monitor

[amuniz]

See JENKINS-66177.

Proposed changelog entries

• JENKINS-66177: ability to disable Java 11 administrative monitor with a system property

Proposed upgrade guidelines

N/A

Submitter checklist

• (If applicable) Jira issue is well described
• Changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developer, depending on the change). Examples
  • Fill-in the Proposed changelog entries section only if there are breaking changes or other changes which may require extra steps from users during the upgrade
• Appropriate autotests or explanation to why this change has no tests
• For dependency updates: links to external changelogs and, if possible, full diffs

Desired reviewers

@mention

Maintainer checklist

Before the changes are marked as ready-for-merge:

• There are at least 2 approvals for the pull request and no outstanding requests for change
• Conversations in the pull request are over OR it is explicit that a reviewer does not block the change
• Changelog entries in the PR title and/or Proposed changelog entries are correct
• Proper changelog labels are set so that the changelog can be generated automatically
• If the change needs additional upgrade steps from users, upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the PR title. (example)
• If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[batmat]

This seems reasonably well-limited scope.

[timja]

PR to jenkins.io to add to docs?

[amuniz]

Sure: jenkins-infra/jenkins.io#4469

[batmat]

Given the approvals, and the fact Tim was the submitter of the Java 11 admin monitor PR in the first place, I am moving this forward and marking this PR as ready-for-merge.

We will hence merge this in 24 hours if nobody objects in the meantime.

Thank you

[basil]

I seem to recall disabling previous administrative monitors in the UI and/or Groovy initialization scripts rather than with system properties. If that is indeed a precedent, it seems that it would be ideal to do it that way for a more consistent and polished user experience. However, I don't feel strongly about this. I don't intend to rain on the parade, and this comment is non-blocking.

[timja]

I seem to recall disabling previous administrative monitors in the UI and/or Groovy initialization scripts rather than with system properties. If that is indeed a precedent, it seems that it would be ideal to do it that way for a more consistent and polished user experience. However, I don't feel strongly about this. I don't intend to rain on the parade, and this comment is non-blocking.

That's for users to disable, I assume this is for distributors.

i.e. CloudBees

[basil]

That's for users to disable, I assume this is for distributors. i.e. CloudBees

Fair enough, but in that case they should say so explicitly. Nothing in the PR description or the Jira issue indicates that this is meant to be consumed by OEM distributors rather than end users.

[amuniz]

Yes, this is mainly for distributors. However I can also think about other usages, ie. company X uses a plugin (which might be home made) which is not Java 11 compatible yet, so they don't want Jenkins administrators to even see this monitor to avoid confusion. A sysadmin can set this property at upgrade time and move on.

[timja]

However I can also think about other usages, ie. company X uses a plugin (which might be home made) which is not Java 11 compatible yet, so they don't want Jenkins administrators to even see this monitor to avoid confusion. A sysadmin can set this property at upgrade time and move on.

they can also use the standard supported approach which is the XML file / jcasc.