Merge branch 'master' into add-dropdown-button

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,26 +1,37 @@
 <!-- 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.
+Replace XXXXX with the numeric part of the issue ID you created in Jira.
+Note that if you want your changes backported into LTS, you need to create a Jira issue. See https://www.jenkins.io/download/lts/#backporting-process for more information.
 -->
 
 See [JENKINS-XXXXX](https://issues.jenkins.io/browse/JENKINS-XXXXX).
 
 <!-- Comment:
-If the issue is not fully described in the ticket, add more information here (justification, pull request links, etc.).
+If the issue is not fully described in Jira, add more information here (justification, pull request links, etc.).
 
- * We do not require JIRA issues for minor improvements.
- * Bugfixes should have a JIRA issue (backporting process).
- * Major new features should have a JIRA issue reference.
+ * We do not require Jira issues for minor improvements.
+ * Bug fixes should have a Jira issue to facilitate the backporting process.
+ * Major new features should have a Jira issue.
+-->
+
+### Testing done
+
+<!-- Comment:
+Provide a clear description of how this change was tested.
+At minimum this should include proof that a computer has executed the changed lines.
+Ideally this should include an automated test or an explanation as to why this change has no tests.
+Note that automated test coverage is less than complete, so a successful PR build does not necessarily imply that a computer has executed the changed lines.
+If automated test coverage does not exist for the lines you are changing, you must describe the scenario(s) in which you manually tested the change.
+For frontend changes, include screenshots of the relevant page(s) before and after the change.
+For refactoring and code cleanup changes, exercise the code before and after the change and verify the behavior remains the same.
 -->
 
 ### Proposed changelog entries
 
-- Entry 1: Issue, Human-readable Text
-- ...
+- Entry 1: Issue, human-readable text
+- […]
 
 <!-- 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/
 -->
@@ -31,32 +42,31 @@ 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) 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
-- [ ] 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 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
-
-<!-- For new API and extension points: Link to the reference implementation in open-source (or example in Javadoc) -->
+- [ ] The Jira issue, if it exists, is well-described.
+- [ ] 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](https://github.com/jenkins-infra/jenkins.io/blob/master/content/_data/changelogs/weekly.yml)).
+  - Fill in the **Proposed upgrade guidelines** section only if there are breaking changes or changes that may require extra steps from users during upgrade.
+- [ ] There is automated testing or an explanation as to why this change has no tests.
+- [ ] New public classes, fields, and methods are annotated with `@Restricted` or have `@since TODO` Javadocs, 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 (CSP) directives (see [documentation](https://www.jenkins.io/doc/developer/security/csp/)).
+- [ ] For dependency updates, there are links to external changelogs and, if possible, full differentials.
+- [ ] For new APIs and extension points, there is a link to at least one consumer.
 
 ### Desired reviewers
 
 @mention
 
 <!-- Comment:
-If you need an accelerated review process by the community (e.g., for critical bugs), mention @jenkinsci/code-reviewers
+If you need an accelerated review process by the community (e.g., for critical bugs), mention @jenkinsci/core-pr-reviewers.
 -->
 
 ### 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 accurate, human-readable, and in the imperative mood
-- [ ] 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](https://github.com/jenkinsci/jenkins/pull/4387))
+- [ ] There are at least two (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 is not blocking the change.
+- [ ] Changelog entries in the pull request title and/or **Proposed changelog entries** are accurate, human-readable, and in the imperative mood.
+- [ ] Proper changelog labels are set so that the changelog can be generated automatically.
+- [ ] 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](https://github.com/jenkinsci/jenkins/pull/4387)).
 - [ ] 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](https://issues.jenkins.io/issues/?filter=12146)).

.github/dependabot.yml

@@ -55,6 +55,10 @@ updates:
       # Contains incompatible API changes and needs compatibility work. See:
       # https://github.com/jenkinsci/jenkins/pull/4224
       - dependency-name: "org.jfree:jfreechart"
+
+      # Starting with 6.x, Spring requires Java 17 at a minimum.
+      - dependency-name: "org.springframework:spring-framework-bom"
+        versions: [">=6.0.0"]
   - package-ecosystem: "maven"
     directory: "/"
     target-branch: "stable-2.361"
@@ -65,3 +69,7 @@ updates:
       interval: "daily"
     # Include only security updates and exclude version updates.
     open-pull-requests-limit: 0
+  - package-ecosystem: "docker"
+    directory: "./gitpod"
+    schedule:
+      interval: "daily"

.github/workflows/changelog.yml

@@ -9,8 +9,15 @@ on:
     branches:
       - master
 
+permissions:
+  contents: read
+
 jobs:
   update_draft_release:
+    permissions:
+      pull-requests: write # to add label to PR (release-drafter/release-drafter)
+      contents: write # to create a github release (release-drafter/release-drafter)
+
     if: github.repository_owner == 'jenkinsci'
     runs-on: ubuntu-latest
     steps:

.github/workflows/label-conflicting-pr.yml

@@ -13,7 +13,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Label conflicting PRs
-        uses: eps1lon/actions-label-merge-conflict@b8bf8341285ec9a4567d4318ba474fee998a6919 # v2.0.1
+        uses: eps1lon/actions-label-merge-conflict@v2.1.0
         with:
           dirtyLabel: "unresolved-merge-conflict"
           repoToken: "${{ secrets.GITHUB_TOKEN }}"

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

@@ -4,6 +4,9 @@ on:
   release:
     types: [published]
 
+permissions:
+  contents: read # to fetch code (actions/checkout)
+
 jobs:
   determine-version:
     runs-on: ubuntu-latest
@@ -32,9 +35,12 @@ jobs:
 
           echo "Version is $version, is_lts: $is_lts"
 
-          echo "::set-output name=is-lts::${is_lts}"
-          echo "::set-output name=project-version::$version"
+          echo "is-lts=${is_lts}" >> $GITHUB_OUTPUT
+          echo "project-version=$version" >> $GITHUB_OUTPUT
   war:
+    permissions:
+      contents: write # to upload release asset (actions/upload-release-asset)
+
     runs-on: ubuntu-latest
     needs: determine-version
     steps:
@@ -45,7 +51,7 @@ jobs:
           PROJECT_VERSION=${{ needs.determine-version.outputs.project-version }}
           IS_LTS=${{ needs.determine-version.outputs.is-lts }}
           echo $PROJECT_VERSION
-          echo "::set-output name=file-name::$FILE_NAME"
+          echo "file-name=$FILE_NAME" >> $GITHUB_OUTPUT
 
           REPO=war
           if [ ${IS_LTS} = 'true' ]
@@ -67,6 +73,9 @@ jobs:
           asset_name: ${{ steps.fetch-war.outputs.file-name }}
           asset_content_type: application/java-archive
   debian:
+    permissions:
+      contents: write # to upload release asset (actions/upload-release-asset)
+
     runs-on: ubuntu-latest
     needs: determine-version
     steps:
@@ -78,7 +87,7 @@ jobs:
           echo $PROJECT_VERSION
           FILE_NAME=jenkins_${PROJECT_VERSION}_all.deb
           IS_LTS=${{ needs.determine-version.outputs.is-lts }}
-          echo "::set-output name=file-name::$FILE_NAME"
+          echo "file-name=$FILE_NAME" >> $GITHUB_OUTPUT
 
           REPO=debian
           if [ ${IS_LTS} = 'true' ]
@@ -101,6 +110,9 @@ jobs:
           asset_name: ${{ steps.fetch-deb.outputs.file-name }}
           asset_content_type: application/vnd.debian.binary-package
   redhat:
+    permissions:
+      contents: write # to upload release asset (actions/upload-release-asset)
+
     runs-on: ubuntu-latest
     needs: determine-version
     steps:
@@ -113,7 +125,7 @@ jobs:
           FILE_NAME=jenkins-${PROJECT_VERSION}-1.1.noarch.rpm
           IS_LTS=${{ needs.determine-version.outputs.is-lts }}
 
-          echo "::set-output name=file-name::$FILE_NAME"
+          echo "file-name=$FILE_NAME" >> $GITHUB_OUTPUT
 
           REPO=redhat
           if [ ${IS_LTS} = 'true' ]
@@ -136,6 +148,9 @@ jobs:
           asset_name: ${{ steps.fetch-rpm.outputs.file-name }}
           asset_content_type: application/x-redhat-package-manager
   windows:
+    permissions:
+      contents: write # to upload release asset (actions/upload-release-asset)
+
     runs-on: ubuntu-latest
     needs: determine-version
     steps:
@@ -148,7 +163,7 @@ jobs:
           FILE_NAME=jenkins.msi
           IS_LTS=${{ needs.determine-version.outputs.is-lts }}
 
-          echo "::set-output name=file-name::$FILE_NAME"
+          echo "file-name=$FILE_NAME" >> $GITHUB_OUTPUT
 
           REPO=windows
           if [ ${IS_LTS} = 'true' ]
@@ -171,6 +186,9 @@ jobs:
           asset_name: ${{ steps.fetch-msi.outputs.file-name }}
           asset_content_type: application/octet-stream
   suse:
+    permissions:
+      contents: write # to upload release asset (actions/upload-release-asset)
+
     runs-on: ubuntu-latest
     needs: determine-version
     steps:
@@ -183,7 +201,7 @@ jobs:
           # we need opensuse to the file 
           OUTPUT_FILE_NAME=jenkins-${PROJECT_VERSION}-1.2-opensuse.noarch.rpm
           IS_LTS=${{ needs.determine-version.outputs.is-lts }}
-          echo "::set-output name=file-name::$OUTPUT_FILE_NAME"
+          echo "file-name=$OUTPUT_FILE_NAME" >> $GITHUB_OUTPUT
 
           REPO=opensuse
           if [ ${IS_LTS} = 'true' ]

.gitpod/Dockerfile

@@ -1,4 +1,6 @@
 FROM gitpod/workspace-full
 
+ARG MAVEN_VERSION=3.8.6
+
 RUN brew install gh && \
-    bash -c ". /home/gitpod/.sdkman/bin/sdkman-init.sh && sdk install maven 3.8.4 && sdk default maven 3.8.4"
+    bash -c ". /home/gitpod/.sdkman/bin/sdkman-init.sh && sdk install maven ${MAVEN_VERSION} && sdk default maven ${MAVEN_VERSION}"

CONTRIBUTING.md

@@ -74,6 +74,25 @@ You can use IntelliJ IDEA (preferred) or VS Code (alternate) in the browser.
 If you prefer using IntelliJ IDEA, you can setup Gitpod integration with JetBrains Gateway using the instructions on [gitpod.io](https://www.gitpod.io/docs/ides-and-editors/intellij),
 which will open the workspace in IntelliJ IDEA using JetBrains Gateway.
 
+### Linting
+
+For linting we use a number of tools:
+
+- [checkstyle](https://checkstyle.sourceforge.io/)
+- [eslint](https://eslint.org/)
+- [prettier](https://prettier.io/)
+- [spotless](https://github.com/diffplug/spotless)
+- [stylelint](https://stylelint.io/)
+
+These are all configured to run as part of the Maven build, although they will be skipped if you are building with the `quick-build` profile.
+
+To automatically fix most issues run:
+
+```bash
+mvn spotless:apply
+mvn -pl war frontend:yarn -Dfrontend.yarn.arguments=lint:fix
+```
+
 ## Testing changes
 
 Jenkins core includes unit and functional tests as a part of the repository.
@@ -186,6 +205,11 @@ Pending the merge and release of this patch, IntelliJ IDEA users should work aro
 
 Failure to work around the problem as described above will result in a `could not open '{jenkins.addOpens}'` failure when running tests in IntelliJ IDEA.
 
+### Code formatting for frontend files
+
+Install the [Prettier plugin](https://www.jetbrains.com/help/idea/prettier.html).
+Follow the instructions on the above JetBrains page to configure it how you wish. 'On code reformatting' is a good option.
+
 ## Copyright
 
 The Jenkins core is licensed under [MIT license](./LICENSE.txt), with a few exceptions in bundled classes.