Fix all lint errors

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,11 +1,12 @@
-<!-- Comment: 
+<!-- Comment:
 A great PR typically begins with the line below.
 Replace XXXXX with the numeric part of the issue's id you created on JIRA.
 Please note that if you want your changes backported into LTS, you will need to create a JIRA ticket for it. Read https://www.jenkins.io/download/lts/#backporting-process for more.
 -->
+
 See [JENKINS-XXXXX](https://issues.jenkins.io/browse/JENKINS-XXXXX).
 
-<!-- Comment: 
+<!-- Comment:
 If the issue is not fully described in the ticket, add more information here (justification, pull request links, etc.).
 
  * We do not require JIRA issues for minor improvements.
@@ -15,10 +16,10 @@ If the issue is not fully described in the ticket, add more information here (ju
 
 ### Proposed changelog entries
 
-* Entry 1: Issue, Human-readable Text
-* ...
+- Entry 1: Issue, Human-readable Text
+- ...
 
-<!-- Comment: 
+<!-- Comment:
 The changelogs will be integrated by the core maintainers after the merge.
 The changelog entry should be in the imperative mood; e.g., write "do this"/"return that" rather than "does this"/"returns that".
 For examples, see: https://www.jenkins.io/changelog/
@@ -32,9 +33,9 @@ N/A
 
 - [ ] (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) and are in the imperative mood. [Examples](https://github.com/jenkins-infra/jenkins.io/blob/master/content/_data/changelogs/weekly.yml)
-  * 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
+  - 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
-- [ ] New public classes, fields, and methods are annotated with `@Restricted` or have `@since TODO` Javadoc, as appropriate. 
+- [ ] New public classes, fields, and methods are annotated with `@Restricted` or have `@since TODO` Javadoc, as appropriate.
 - [ ] New deprecations are annotated with `@Deprecated(since = "TODO")` or `@Deprecated(forRemoval = true, since = "TODO")` if applicable.
 - [ ] New or substantially changed JavaScript is not defined inline and does not call `eval` to ease future introduction of Content-Security-Policy directives (see [documentation on jenkins.io](https://www.jenkins.io/doc/developer/security/csp/)).
 - [ ] For dependency updates: links to external changelogs and, if possible, full diffs
@@ -51,7 +52,7 @@ If you need an accelerated review process by the community (e.g., for critical b
 
 ### Maintainer checklist
 
-Before the changes are marked as `ready-for-merge`: 
+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

.github/dependabot.yml

@@ -27,7 +27,6 @@ updates:
       # Log4j 1.2.17 is the final 1.x release.
       - dependency-name: "log4j:log4j"
 
-
       # Here lies technical debt. Exclusions in this section have been triaged
       # and determined to be temporary. Exclusions should be removed from this
       # section once the remaining action items have been completed.

.github/release-drafter.yml

@@ -10,5 +10,5 @@ template: |
   See https://www.jenkins.io/changelog/ for the official changelogs._
 
   $CHANGES
-  
+
   All contributors: $CONTRIBUTORS

.github/workflows/publish-release-artifact.yml

@@ -15,7 +15,7 @@ jobs:
       - name: Set up JDK 8
         uses: actions/setup-java@v3
         with:
-          distribution: 'temurin'
+          distribution: "temurin"
           java-version: 8
       - name: Set version
         id: set-version
@@ -193,7 +193,7 @@ jobs:
 
           echo $REPO
 
-          wget -q https://get.jenkins.io/${REPO}/jenkins-${PROJECT_VERSION}-1.2.noarch.rpm -O ${OUTPUT_FILE_NAME} 
+          wget -q https://get.jenkins.io/${REPO}/jenkins-${PROJECT_VERSION}-1.2.noarch.rpm -O ${OUTPUT_FILE_NAME}
       - name: Upload Release Asset
         id: upload-suse-rpm
         if: always()

.gitpod.yml

@@ -1,7 +1,7 @@
 tasks:
   - init: |
       mvn -am -pl war,bom -P quick-build clean install
-    command: |      
+    command: |
       mvn -pl war jetty:run -Dhost=0.0.0.0
     name: Run
   - command: gp await-port 8080 && gp url 8080 && gp preview $(gp url 8080)/jenkins/

CONTRIBUTING.md

@@ -9,19 +9,19 @@ This page provides information about contributing code to the Jenkins core codeb
 1. Fork the repository on GitHub
 2. Clone the forked repository to your machine
 3. Install the necessary development tools. In order to develop Jenkins, you need the following:
-   * Java Development Kit (JDK) 11 or 17.
+   - Java Development Kit (JDK) 11 or 17.
      In the Jenkins project we usually use [Eclipse Temurin](https://adoptium.net/) or [OpenJDK](https://openjdk.java.net/), but you can use other JDKs as well.
-   * Apache Maven 3.8.1 or above. You can [download Maven here](https://maven.apache.org/download.cgi).
+   - Apache Maven 3.8.1 or above. You can [download Maven here](https://maven.apache.org/download.cgi).
      In the Jenkins project we usually use the most recent Maven release.
-   * Any IDE which supports importing Maven projects.
-   * Install [NodeJS 16.x](https://nodejs.org/en/). **Note:** only needed to work on the frontend assets found in the `war` module.
-     * Frontend tasks are run using [yarn](https://yarnpkg.com/). Run `npm install -g yarn` to install it.
+   - Any IDE which supports importing Maven projects.
+   - Install [NodeJS 16.x](https://nodejs.org/en/). **Note:** only needed to work on the frontend assets found in the `war` module.
+     - Frontend tasks are run using [yarn](https://yarnpkg.com/). Run `npm install -g yarn` to install it.
 4. Set up your development environment as described in [Preparing for Plugin Development](https://www.jenkins.io/doc/developer/tutorial/prepare/)
 
 If you want to contribute to Jenkins, or just learn about the project,
 you can start by fixing some easier issues.
 In the Jenkins issue tracker we mark such issues as `newbie-friendly`.
-You can find them by using this query (check the link) for [newbie friendly issues](https://issues.jenkins.io/issues/?jql=project%20%3D%20JENKINS%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20component%20%3D%20core%20AND%20labels%20in%20(newbie-friendly)).
+You can find them by using this query (check the link) for [newbie friendly issues](<https://issues.jenkins.io/issues/?jql=project%20%3D%20JENKINS%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20component%20%3D%20core%20AND%20labels%20in%20(newbie-friendly)>).
 
 ## Building and Debugging
 
@@ -53,11 +53,13 @@ mvn -pl war jetty:run
 To work on the `war` module frontend assets, two processes are needed at the same time:
 
 On one terminal, start a development server that will not process frontend assets:
+
 ```sh
 mvn -pl war jetty:run -Dskip.yarn
 ```
 
 On another terminal, move to the war folder and start a [webpack](https://webpack.js.org/) dev server:
+
 ```sh
 cd war; yarn start
 ```
@@ -82,9 +84,9 @@ so there is no strict need to run full test suites before proposing a pull reque
 
 There are 3 profiles for tests:
 
-* `light-test` - runs only unit tests, no functional tests
-* `smoke-test` - runs unit tests + a number of functional tests
-* `all-tests` - runs all tests, with re-run (default)
+- `light-test` - runs only unit tests, no functional tests
+- `smoke-test` - runs unit tests + a number of functional tests
+- `all-tests` - runs all tests, with re-run (default)
 
 In addition to the included tests, you can also find extra integration and UI
 tests in the [Acceptance Test Harness (ATH)](https://github.com/jenkinsci/acceptance-test-harness) repository.
@@ -93,6 +95,7 @@ If you propose complex UI changes, you should create new ATH tests for them.
 ### JavaScript unit tests
 
 In case there's only need to run the JS tests:
+
 ```sh
 cd war; yarn test
 ```
@@ -105,17 +108,17 @@ All proposed changes are submitted, and code reviewed, using a [GitHub pull requ
 To submit a pull request:
 
 1. Commit your changes and push them to your fork on GitHub.
-It is a good practice is to create branches instead of pushing to master.
+   It is a good practice is to create branches instead of pushing to master.
 2. In the GitHub Web UI, click the _New Pull Request_ button.
 3. Select `jenkinsci` as _base fork_ and `master` as `base`, then click _Create Pull Request_.
-   * We integrate all changes into the master branch towards the Weekly releases.
-   * After that, the changes may be backported to the current LTS baseline by the LTS Team.
+   - We integrate all changes into the master branch towards the Weekly releases.
+   - After that, the changes may be backported to the current LTS baseline by the LTS Team.
      Read more about the [backporting process](https://www.jenkins.io/download/lts/).
 4. Fill in the Pull Request description according to the [proposed template](.github/PULL_REQUEST_TEMPLATE.md).
 5. Click _Create Pull Request_.
 6. Wait for CI results/reviews, process the feedback.
-   * If you do not get feedback after 3 days, feel free to ping `@jenkinsci/core-pr-reviewers` in the comments.
-   * Usually we merge pull requests after 2 approvals from reviewers, no requested changes, and having waited some more time to give others an opportunity to provide their feedback.
+   - If you do not get feedback after 3 days, feel free to ping `@jenkinsci/core-pr-reviewers` in the comments.
+   - Usually we merge pull requests after 2 approvals from reviewers, no requested changes, and having waited some more time to give others an opportunity to provide their feedback.
      See [this page](/docs/MAINTAINERS.adoc) for more information about our review process.
 
 Once your Pull Request is ready to be merged,
@@ -130,26 +133,26 @@ The complete list of labels can be found at https://github.com/jenkinsci/jenkins
 These labels are defined as follows:
 
 - `needs-docs` marks a pull request as lacking documentation, either for developers (e.g., Javadoc) or users (e.g., changes to the [Jenkins handbook](https://www.jenkins.io/doc/book/)).
-For such pull requests to be approved and merged, the corresponding changes to the documentation should be proposed.
-If those changes belong to a separate repository (e.g., `jenkins-infra/jenkins.io`), a secondary pull request should be created in draft state in the other repository and reviewed in tandem with the primary pull request that proposes the code change.
+  For such pull requests to be approved and merged, the corresponding changes to the documentation should be proposed.
+  If those changes belong to a separate repository (e.g., `jenkins-infra/jenkins.io`), a secondary pull request should be created in draft state in the other repository and reviewed in tandem with the primary pull request that proposes the code change.
 - `needs-fix` marks a pull request which has pending requests for change that have not yet been addressed.
-Such pull requests will not be merged until the code has been fixed and the tests pass.
+  Such pull requests will not be merged until the code has been fixed and the tests pass.
 - `needs-justification` marks a pull request where the reasoning is unclear, incomplete or not entirely cogent.
-To properly evaluate the solution provided in a pull request, maintainers must be able to understand the high-level problem that the pull request attempts to solve.
-While the context might be obvious to the author, it is not always apparent to reviewers and maintainers.
-The use of design documents, high-level tracking epics, [minimal reproducible examples (MREs)](https://en.wikipedia.org/wiki/Minimal_reproducible_example), etc. is strongly encouraged.
+  To properly evaluate the solution provided in a pull request, maintainers must be able to understand the high-level problem that the pull request attempts to solve.
+  While the context might be obvious to the author, it is not always apparent to reviewers and maintainers.
+  The use of design documents, high-level tracking epics, [minimal reproducible examples (MREs)](https://en.wikipedia.org/wiki/Minimal_reproducible_example), etc. is strongly encouraged.
 - `needs-more-review` marks a pull request as lacking a sufficient number of reviews from subject-matter expert(s) (SME), either because the changes are complex and not sufficiently explained or because there is a lack of consensus regarding the proposed solution.
 - `on-hold` marks a pull request that depends on another event and cannot be merged until the completion of that event.
-When the dependent task has been completed, the pull request will be ready for merge.
+  When the dependent task has been completed, the pull request will be ready for merge.
 - `proposed-for-close` marks a pull request where there is either no consensus on the next steps or where the next steps have not been taken and an extended period of time has elapsed.
-Such pull requests are typically closed approximately one week after the label has been applied.
-They can always be reopened once consensus has been reached on the next steps or when action is taken regarding these next steps.
+  Such pull requests are typically closed approximately one week after the label has been applied.
+  They can always be reopened once consensus has been reached on the next steps or when action is taken regarding these next steps.
 - `ready-for-merge` marks a pull request that has met the acceptance criteria, as defined elsewhere in this document.
-If there is no negative feedback, such pull requests are typically merged within approximately 24 hours.
+  If there is no negative feedback, such pull requests are typically merged within approximately 24 hours.
 - `stalled` marks a pull request that is off to a promising start but requires additional effort to reach completion - effort that appears to have been abandoned.
-If the original author lacks the time and interest to continue the original effort, we suggest that someone else pick up where the original author left off to drive the effort to completion.
+  If the original author lacks the time and interest to continue the original effort, we suggest that someone else pick up where the original author left off to drive the effort to completion.
 - `work-in-progress` marks a pull request that remains under active development.
-Such pull requests are not ready for final review.
+  Such pull requests are not ready for final review.
 
 To ensure that pull requests are processed efficiently, the `ready-for-merge`, `stalled`, and `proposed-for-close` labels are subject to time constraints.
 
@@ -172,7 +175,7 @@ The setting can be found in Settings -> Editor -> General -> On Save -> Remove t
 This will help minimize the diff, which makes reviewing PRs easier.
 
 We also do not recommend `*` imports in the production code.
-Please disable them in Settings > Editor > Codestyle > Java by setting _Class count to use import with '*'_ and Names count to use import with '*'_ to a high value, e.g. 100. 
+Please disable them in Settings > Editor > Codestyle > Java by setting _Class count to use import with '\*'_ and Names count to use import with '\*'\_ to a high value, e.g. 100.
 
 The addition of `@{jenkins.addOpens}` to `argLine` exposes a bug in IntelliJ IDEA.
 A patch has been proposed in [JetBrains/intellij-community#1976](https://github.com/JetBrains/intellij-community/pull/1976).
@@ -209,7 +212,7 @@ just submit a pull request.
 
 # Links
 
-* [Jenkins Contribution Landing Page](https://www.jenkins.io/participate/)
-* [Jenkins Chat Channels](https://www.jenkins.io/chat/)
-* [Beginners Guide To Contributing](https://www.jenkins.io/participate/)
-* [List of newbie-friendly issues in the core](https://issues.jenkins.io/issues/?jql=project%20%3D%20JENKINS%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20component%20%3D%20core%20AND%20labels%20in%20(newbie-friendly))
+- [Jenkins Contribution Landing Page](https://www.jenkins.io/participate/)
+- [Jenkins Chat Channels](https://www.jenkins.io/chat/)
+- [Beginners Guide To Contributing](https://www.jenkins.io/participate/)
+- [List of newbie-friendly issues in the core](<https://issues.jenkins.io/issues/?jql=project%20%3D%20JENKINS%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20component%20%3D%20core%20AND%20labels%20in%20(newbie-friendly)>)

README.md

@@ -12,8 +12,8 @@
 [![Docker Pulls](https://img.shields.io/docker/pulls/jenkins/jenkins.svg)](https://hub.docker.com/r/jenkins/jenkins/)
 [![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/3538/badge)](https://bestpractices.coreinfrastructure.org/projects/3538)
 
-In a nutshell, Jenkins is the leading open-source automation server. 
-Built with Java, it provides over 1,800 [plugins](https://plugins.jenkins.io/) to support automating virtually anything, 
+In a nutshell, Jenkins is the leading open-source automation server.
+Built with Java, it provides over 1,800 [plugins](https://plugins.jenkins.io/) to support automating virtually anything,
 so that humans can spend their time doing things machines cannot.
 
 # What to Use Jenkins for and When to Use It
@@ -34,17 +34,17 @@ See the [Downloads](https://www.jenkins.io/download) page for references.
 
 For all distributions Jenkins offers two release lines:
 
-* [Weekly](https://www.jenkins.io/download/weekly/) -
+- [Weekly](https://www.jenkins.io/download/weekly/) -
   Frequent releases which include all new features, improvements, and bug fixes.
-* [Long-Term Support (LTS)](https://www.jenkins.io/download/lts/) -
+- [Long-Term Support (LTS)](https://www.jenkins.io/download/lts/) -
   Older release line which gets periodically updated via bug fix backports.
 
 Latest releases:
 [![Jenkins Regular Release](https://img.shields.io/endpoint?url=https%3A%2F%2Fwww.jenkins.io%2Fchangelog%2Fbadge.json)](https://www.jenkins.io/changelog)
 [![Jenkins LTS Release](https://img.shields.io/endpoint?url=https%3A%2F%2Fwww.jenkins.io%2Fchangelog-stable%2Fbadge.json)](https://www.jenkins.io/changelog-stable)
 
-
 # Source
+
 Our latest and greatest source of Jenkins can be found on [GitHub](https://github.com/jenkinsci/jenkins). Fork us!
 
 # Contributing to Jenkins
@@ -71,4 +71,5 @@ Jenkins is used by millions of users and thousands of companies.
 See [adopters](https://www.jenkins.io/project/adopters/) for the list of Jenkins adopters and their success stories.
 
 # License
+
 Jenkins is **licensed** under the **[MIT License](https://github.com/jenkinsci/jenkins/blob/master/LICENSE.txt)**.

changelog.html

@@ -12,4 +12,4 @@
 
 Be sure to use PRs for changes to these files, as malformed files WILL result in build failures of the jenkins.io static site generation.
 
--->
+-->