[pull] master from jenkinsci:master

.babelrc

@@ -0,0 +1,3 @@
+{
+  "presets": ["@babel/preset-env"]
+}

.editorconfig

@@ -1,6 +1,6 @@
 root = true
 
-[*.{jelly, js, less, css, hbs}]
+[*.{js, scss, css, hbs, svg}]
 indent_style = space
 indent_size = 2
 trim_trailing_whitespace = true

.git-blame-ignore-revs

@@ -0,0 +1,4 @@
+# Whitespace: https://github.com/jenkinsci/jenkins/pull/6149
+e27b310065b3c036b5fc9d123f1d1d99d3058c00
+# Reformatted: https://github.com/jenkinsci/jenkins/pull/6863
+e3fdfa527e4fefb4b37f04c92a2dd87b8a374b75

.gitattributes

@@ -15,7 +15,6 @@
 *.json          text
 *.jelly         text
 *.jellytag      text
-*.less          text
 *.properties    text
 *.rb            text
 *.sh            text
@@ -37,3 +36,7 @@
 *.png           binary
 *.war           binary
 *.zip           binary
+
+# Yarn
+# https://yarnpkg.com/getting-started/qa#which-files-should-be-gitignored
+/.yarn/plugins/** binary

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,59 +1,109 @@
-<!-- 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.
+Replace <issue-number> with the issue number.
 -->
-See [JENKINS-XXXXX](https://issues.jenkins-ci.org/browse/JENKINS-XXXXX).
 
-<!-- Comment: 
-If the issue is not fully described in the ticket, add more information here (justification, pull request links, etc.).
+Fixes #<issue-number>
+
+<!-- Comment:
+If the issue is not fully described in the issue tracker, 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 an issue for minor improvements.
+ * Major new features should have an issue created.
+-->
+
+### 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
-* ...
+- human-readable text
 
-<!-- Comment: 
-The changelogs will be integrated by the core maintainers after the merge.
+<!-- Comment:
 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/
+
+Do not include the issue in the changelog entry.
+Include the issue in the description of the pull request so that the changelog generator can find it and include it in the generated changelog.
+
+You may add multiple changelog entries if applicable by adding a new entry to the list, e.g.
+- First changelog entry
+- Second changelog entry
+-->
+
+### Proposed changelog category
+
+/label <update-this-with-category>
+
+<!--
+The changelog entry needs to have a category which is selected based on the label.
+If there's no changelog then the label should be `skip-changelog`.
+
+The available categories are:
+* bug - Minor bug. Will be listed after features
+* developer - Changes which impact plugin developers
+* dependencies - Pull requests that update a dependency
+* internal - Internal only change, not user facing
+* into-lts - Changes that are backported to the LTS baseline
+* localization - Updates localization files
+* major-bug - Major bug. Will be highlighted on the top of the changelog
+* major-rfe - Major enhancement. Will be highlighted on the top
+* rfe - Minor enhancement
+* regression-fix - Fixes a regression in one of the previous Jenkins releases
+* removed - Removes a feature or a public API
+* skip-changelog - Should not be shown in the changelog
+
+Non-changelog categories:
+* web-ui - Changes in the web UI
+
+Non-changelog categories require a changelog category but should be used if applicable,
+comma separate to provide multiple categories in the label command.
 -->
 
 ### Proposed upgrade guidelines
 
 N/A
 
-### Submitter checklist
+<!-- Comment:
+Leave the proposed upgrade guidelines in the pull request with the "N/A" value if no upgrade guidelines are needed.
+The changelog generator relies on the presence of the upgrade guidelines section as part of its data extraction process.
+-->
 
-- [ ] (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. 
-- [ ] For dependency updates: links to external changelogs and, if possible, full diffs
+### Submitter checklist
 
-<!-- For new API and extension points: Link to the reference implementation in open-source (or example in Javadoc) -->
+- [ ] The 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.
+- [ ] UI changes do not introduce regressions when enforcing the current default rules of [Content Security Policy Plugin](https://plugins.jenkins.io/csp/). In particular, 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`:
 
-Before the changes are marked as `ready-for-merge`: 
+### Maintainer checklist
 
-- [ ] 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))
-- [ ] 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-ci.org/issues/?filter=12146)).
+- [ ] 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, be a _Bug_ or _Improvement_, and either the issue or pull request must be labeled as `lts-candidate` to be considered.

.github/comment-ops.yml

@@ -0,0 +1,7 @@
+commands:
+  label:
+    enabled: true
+  removeLabel:
+    enabled: true
+  reviewer:
+    enabled: true

.github/config.yml

@@ -0,0 +1,25 @@
+newPRWelcomeComment: >
+  Yay, your first pull request towards Jenkins core was created successfully!
+  Thank you so much!
+  <br>
+  <br>
+  A contributor will provide feedback soon.
+  Meanwhile, you can join the [chats](https://app.gitter.im/#/room/#jenkins-ci:matrix.org) and [community forums](https://community.jenkins.io/) to connect with other Jenkins users, developers, and maintainers.
+
+firstPRMergeComment: >
+  Congratulations on getting your very first Jenkins core pull request merged 🎉🥳
+  <br>
+  <br>
+  This is a fantastic achievement, and we're thrilled to have you as part of our community!
+  Thank you for your valuable input, and we look forward to seeing more of your contributions in the future!
+  <br>
+  <br>
+  We would like to invite you to join the [community chats](https://app.gitter.im/#/room/#jenkins-ci:matrix.org) and [forums](https://community.jenkins.io/) to meet other Jenkins contributors 😊
+  <br>
+  Don't forget to check out the [participation](https://www.jenkins.io/participate/) page to learn more about how to contribute to Jenkins.
+
+  <a href="https://www.jenkins.io/participate/" target="_blank">
+   <picture>
+     <img width="600" src="https://raw.githubusercontent.com/jenkinsci/jenkins/master/.github/images/jenkins-welcome.svg">
+   </picture>
+  </a>