Remove deprecated GHES versions from content and data (#15830)
* ran script/remove-unused-assets.js (manually removed unused variables printed by the script) * package-lock * turn elsif into two ifs to prepare for running Liquid deprecation script * ran script/remove-deprecated-enterprise-version-markup.js --release 2.14 (ONLY UPDATES LINE BREAKS ETC.) * ran script/remove-deprecated-enterprise-version-markup.js --release 2.15 * ran script/remove-deprecated-enterprise-version-markup.js --release 2.17 * ran script/remove-deprecated-enterprise-version-markup.js --release 2.18 * update hardcoded test * Update content/github/collaborating-with-issues-and-pull-requests/filtering-files-in-a-pull-request.md Co-authored-by: Matt Pollard <mattpollard@users.noreply.github.com> * add currentVersion is NOT free-pro-team to conditional, to make sure the deprecation script does the right thing when it is time to deprecate 2.21 Co-authored-by: Matt Pollard <mattpollard@users.noreply.github.com>
This commit is contained in:
Sarah Schneider
@@ -1 +1 @@
|
||||
Any unused labels that are not assigned to a runner will be automatically deleted within 24 hours.
|
||||
Any unused labels that are not assigned to a runner will be automatically deleted within 24 hours.
|
||||
|
||||
@@ -1 +1 @@
|
||||
When you disable {% data variables.product.prodname_actions %}, no workflows run in your repository.
|
||||
When you disable {% data variables.product.prodname_actions %}, no workflows run in your repository.
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
1. Document required arguments in the action's README and omit them from the `CMD` instruction.
|
||||
1. Use defaults that allow using the action without specifying any `args`.
|
||||
1. If the action exposes a `--help` flag, or something similar, use that to make your action self-documenting.
|
||||
1. If the action exposes a `--help` flag, or something similar, use that to make your action self-documenting.
|
||||
|
||||
@@ -1 +1 @@
|
||||
When you enable {% data variables.product.prodname_actions %}, workflows are able to run actions located within your repository and any other public repository.
|
||||
When you enable {% data variables.product.prodname_actions %}, workflows are able to run actions located within your repository and any other public repository.
|
||||
|
||||
@@ -1 +1 @@
|
||||
When you enable local actions only, workflows can only run actions located in your repository or organization.
|
||||
When you enable local actions only, workflows can only run actions located in your repository or organization.
|
||||
|
||||
@@ -1 +1 @@
|
||||
When you use expressions in an `if` conditional, you may omit the expression syntax ({% raw %}`${{ }}`{% endraw %}) because {% data variables.product.prodname_dotcom %} automatically evaluates the `if` conditional as an expression.
|
||||
When you use expressions in an `if` conditional, you may omit the expression syntax ({% raw %}`${{ }}`{% endraw %}) because {% data variables.product.prodname_dotcom %} automatically evaluates the `if` conditional as an expression.
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
This workflow performs the following steps:
|
||||
|
||||
1. Checks out a copy of project's repository.
|
||||
1. Sets up the Java JDK.
|
||||
1. Sets up the Java JDK.
|
||||
|
||||
@@ -1 +1 @@
|
||||
To create secrets at the organization level, you must have `admin` access.
|
||||
To create secrets at the organization level, you must have `admin` access.
|
||||
|
||||
@@ -1 +1 @@
|
||||
To create secrets for a user account repository, you must be the repository owner. To create secrets for an organization repository, you must have `admin` access.
|
||||
To create secrets for a user account repository, you must be the repository owner. To create secrets for an organization repository, you must have `admin` access.
|
||||
|
||||
@@ -2,4 +2,4 @@ If you rely on using forks of your private repositories, you can configure polic
|
||||
|
||||
- **Run workflows from fork pull requests** - Allows users to run workflows from fork pull requests, using a `GITHUB_TOKEN` with read-only permission, and with no access to secrets.
|
||||
- **Send write tokens to workflows from pull requests** - Allows pull requests from forks to use a `GITHUB_TOKEN` with write permission.
|
||||
- **Send secrets to workflows from pull requests** - Makes all secrets available to the pull request.
|
||||
- **Send secrets to workflows from pull requests** - Makes all secrets available to the pull request.
|
||||
|
||||
@@ -1 +1 @@
|
||||
Runs the `mvn -B deploy` command to publish to the `ossrh` repository. The `MAVEN_USERNAME` environment variable will be set with the contents of your `OSSRH_USERNAME` secret, and the `MAVEN_PASSWORD` environment variable will be set with the contents of your `OSSRH_TOKEN` secret.
|
||||
Runs the `mvn -B deploy` command to publish to the `ossrh` repository. The `MAVEN_USERNAME` environment variable will be set with the contents of your `OSSRH_USERNAME` secret, and the `MAVEN_PASSWORD` environment variable will be set with the contents of your `OSSRH_TOKEN` secret.
|
||||
|
||||
@@ -1 +1 @@
|
||||
Runs the `mvn -B deploy` command to publish to {% data variables.product.prodname_registry %}. The `GITHUB_TOKEN` environment variable will be set with the contents of the `GITHUB_TOKEN` secret.
|
||||
Runs the `mvn -B deploy` command to publish to {% data variables.product.prodname_registry %}. The `GITHUB_TOKEN` environment variable will be set with the contents of the `GITHUB_TOKEN` secret.
|
||||
|
||||
@@ -1 +1 @@
|
||||
This guide shows you how to create a workflow that publishes Java packages to {% data variables.product.prodname_registry %} and the Maven Central Repository. With a single workflow, you can publish packages to a single repository or to multiple repositories.
|
||||
This guide shows you how to create a workflow that publishes Java packages to {% data variables.product.prodname_registry %} and the Maven Central Repository. With a single workflow, you can publish packages to a single repository or to multiple repositories.
|
||||
|
||||
@@ -1 +1 @@
|
||||
A unique number for each run within a repository. This number does not change if you re-run the workflow run.
|
||||
A unique number for each run within a repository. This number does not change if you re-run the workflow run.
|
||||
|
||||
@@ -1 +1 @@
|
||||
A unique number for each run of a particular workflow in a repository. This number begins at 1 for the workflow's first run, and increments with each new run. This number does not change if you re-run the workflow run.
|
||||
A unique number for each run of a particular workflow in a repository. This number begins at 1 for the workflow's first run, and increments with each new run. This number does not change if you re-run the workflow run.
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
1. In the **Self-hosted runners** section of the settings page, click {% octicon "kebab-horizontal" aria-label="The horizontal kebab icon" %} next to the runner group you'd like to configure, then click **Edit name and [organization|repository] access**.
|
||||
|
||||
1. Select a new policy from the dropdown list, or modify the runner group name.
|
||||
1. Select a new policy from the dropdown list, or modify the runner group name.
|
||||
|
||||
@@ -1,2 +1,2 @@
|
||||
1. If your runner is in a group, locate the runner group and click {% octicon "chevron-down" aria-label="The downward chevron" %} to view the list of runners.
|
||||
|
||||
|
||||
|
||||
@@ -1 +1 @@
|
||||
1. Locate the list of runners under "Self-hosted runners".
|
||||
1. Locate the list of runners under "Self-hosted runners".
|
||||
|
||||
@@ -1 +1 @@
|
||||
1. In your organization or repository, navigate to the main page and click {% octicon "gear" aria-label="The Settings gear" %} **Settings**.
|
||||
1. In your organization or repository, navigate to the main page and click {% octicon "gear" aria-label="The Settings gear" %} **Settings**.
|
||||
|
||||
@@ -1 +1 @@
|
||||
This procedure permanently removes the self-hosted runner. If you only want to temporarily stop a runner from being assigned jobs, you can either shut down the machine or stop the `run` application. The runner will remain assigned in an "Offline" state, and won't execute any jobs until you restart the runner using the `run` application.
|
||||
This procedure permanently removes the self-hosted runner. If you only want to temporarily stop a runner from being assigned jobs, you can either shut down the machine or stop the `run` application. The runner will remain assigned in an "Offline" state, and won't execute any jobs until you restart the runner using the `run` application.
|
||||
|
||||
@@ -1 +1 @@
|
||||
Alternatively, if you don't have access to the repository, organization, or enterprise on {% data variables.product.product_name %} to remove a runner, but you would like to re-use the runner machine, then you can delete the `.runner` file inside the self-hosted runner application directory. This allows the runner to be registered without having to re-download the self-hosted runner application.
|
||||
Alternatively, if you don't have access to the repository, organization, or enterprise on {% data variables.product.product_name %} to remove a runner, but you would like to re-use the runner machine, then you can delete the `.runner` file inside the self-hosted runner application directory. This allows the runner to be registered without having to re-download the self-hosted runner application.
|
||||
|
||||
@@ -1 +1 @@
|
||||
1. In the left sidebar, click **Secrets**.
|
||||
1. In the left sidebar, click **Secrets**.
|
||||
|
||||
@@ -1 +1 @@
|
||||
- **API requests** - You can execute up to 1000 API requests in an hour across all actions within a repository. If exceeded, additional API calls will fail, which might cause jobs to fail.
|
||||
- **API requests** - You can execute up to 1000 API requests in an hour across all actions within a repository. If exceeded, additional API calls will fail, which might cause jobs to fail.
|
||||
|
||||
@@ -1 +1 @@
|
||||
- **Job matrix** - A job matrix can generate a maximum of 256 jobs per workflow run. This limit also applies to self-hosted runners.
|
||||
- **Job matrix** - A job matrix can generate a maximum of 256 jobs per workflow run. This limit also applies to self-hosted runners.
|
||||
|
||||
@@ -1 +1 @@
|
||||
- **Workflow run time** - Each workflow run is limited to 72 hours. If a workflow run reaches this limit, the workflow run is cancelled.
|
||||
- **Workflow run time** - Each workflow run is limited to 72 hours. If a workflow run reaches this limit, the workflow run is cancelled.
|
||||
|
||||
Reference in New Issue
Block a user