[JENKINS-73114] avoid conflicts with css classes from bootstrap

[mawinter69]

jenkins and bootstrap both have definitions for alert and alert-warning, alert-info and alert-danger. Bootstrap css definitions are included when e.g. the warning-ng plugin is installed and a job is configured to scan for warnings. The css classes from bootstrap are then chosen instead of the ones for Jenkins for things like the admin monitors. To make things unambiguous, add additional classes prefixed with jenkins- and make use of them in code. Keep the old definitions for backward compatibility with plugins.
Follow-up changes are needed in plugins (Mostly those that define admin monitors) and the design-library

After:
for a plugin message:

for a core message:

See JENKINS-73114.

Originally reported as jenkinsci/customizable-header-plugin#99

Testing done

Manual testing

1. Create new Jenkins instance, it should have some executors for built-in, this will trigger the corresponding monitor
2. Visit page /manage/ -> monitors are displayed properly
3. install warnings-ng plugin
4. create freestyle job and configure post build action to scan for e.g. stylellint.
5. run the job once
6. In the header click on the warning shield -> monitor is displayed properly (If there are monitors from plugins they might not be properly styled here)

Proposed changelog entries

• Add new CSS classes to avoid conflicts with CSS classes from bootstrap.

Proposed upgrade guidelines

N/A

Submitter checklist

Beta Give feedback

1. The Jira issue, if it exists, is well-described.
2. The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples). Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
3. There is automated testing or an explanation as to why this change has no tests.
4. New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
5. New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
6. New or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
7. For dependency updates, there are links to external changelogs and, if possible, full differentials.
8. For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@mention

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

Maintainer checklist

Beta Give feedback

1. There are at least two (2) approvals for the pull request and no outstanding requests for change.
2. Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
3. Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
4. Proper changelog labels are set so that the changelog can be generated automatically.
5. If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
6. 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).

[NotMyFault]

Thanks!

---

/label ready-for-merge

---

This PR is now ready for merge. We will merge it after ~24 hours if there is no negative feedback.
Please see the merge process documentation for more information about the merge process.
Thanks!

[timja]

Can you create a PR for the design library to adapt to this please?

[mawinter69]

Can you create a PR for the design library to adapt to this please?

done

[MarkEWaite]

@mawinter69 can you also identify the plugins that need to be updated to use the new CSS classes? I think it is better to complete the migration from the old CSS classes to the new CSS classes in the most popular plugins.

[mawinter69]

Should this maybe downported to LTS 2.452.2? Otherwise it will take quite a while until it arrives in an LTS. Plugins would otherwise need to use weekly 2.459. Specifying both the old and new classes doesn't help when bootstrap loaded so it can't really be made forward compatible

[mawinter69]

I Identified following plugins making use of the any of the alert-* classes. That doesn't necessarily mean they need to be adjusted, e.g. pipeline-stage-view seems to have a bootstrap3 included and relies on the definitions there.

active-directory
alauda-devopy-synvc
artifact-manager-s3
atlassian-bitbucket-server-integration
audit-trail
azure-ad
azure-vm-agents
blue-ocean
branch-api
cloudbees-jenkins-advisor
collabnet
configuration-as-code
copyartifact
customizable-header
dependency-track
dimensionsscm
ec2
github
gitlab-branch-source
gradle
jenkinslint
localization-support
matrix-auth
miniorange-saml-sp
miniorange-two-factor
opentelemetry
performance-signature-dynatrace
pipeline-input-step
pipeline-maven
pipeline-stage-view
pull-request-monitoring
role-strategy
spotinst
ssh-agents
sysdig-secure
sysdig-secure
xcode

[MarkEWaite]

Thanks @mawinter69 ! Is it valid CSS to refer to a CSS class that does not exist? For example, the branch-api plugin today has a line:

<div class="alert alert-warning" role="alert">

Could that be extended to:

<div class="alert jenkins-alert alert-warning" role="alert">

and still be usable on Jenkins versions that don't yet include the new CSS classes?

[mawinter69]

Thanks @mawinter69 ! Is it valid CSS to refer to a CSS class that does not exist?

That would be valid (Jenkins is using all over the place classes without a corresponding css definition to be able to select things in queries). Though only by removing alert and alert-warning there is no interference with bootstrap. And for not breaking plugins that don't have the new classes, the old definitions are still there.

<div class="alert alert-warning" role="alert">

that should become <div class="alert jenkins-alert alert-warning jenkins-alert-warning" role="alert">