Merge branch 'master' into search-overhaul

.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/workflows/publish-release-artifact.yml

@@ -35,8 +35,8 @@ 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)
@@ -51,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' ]
@@ -87,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' ]
@@ -125,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' ]
@@ -163,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' ]
@@ -201,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' ]