Merge branch 'main' into fix-server-release-page
This commit is contained in:
@@ -19,6 +19,8 @@ Before you make your changes, check to see if an [issue exists](https://github.c
|
||||
|
||||
If you spot something new, open an issue using a [template](https://github.com/github/docs/issues/new/choose). We'll use the issue to have a conversation about the problem you want to fix.
|
||||
|
||||
**Note:** We cannot accept contributions to the [REST API reference documentation](https://docs.github.com/en/rest/reference). If you spot an inaccuracy in the REST API reference documentation, open an issue in the [github/rest-api-description](https://github.com/github/rest-api-description/issues/new?template=schema-inaccuracy.md) repository.
|
||||
|
||||
### Ready to make a change? Fork the repo
|
||||
|
||||
Fork using GitHub Desktop:
|
||||
|
||||
@@ -45,7 +45,7 @@ In addition to uploading packaging artifacts for testing in a continuous integra
|
||||
* **Publish packages to {% data variables.product.prodname_registry %}**
|
||||
{% data variables.product.prodname_registry %} can act as a package hosting service for many types of packages. You can choose to share your packages with all of {% data variables.product.prodname_dotcom %}, or private packages to share with collaborators or an organization. For more information, see "[About {% data variables.product.prodname_registry %}](/github/managing-packages-with-github-packages/about-github-packages)."
|
||||
|
||||
You may want to publish packages to {% data variables.product.prodname_registry %} on every push into the default branch. This will allow developers on your project to always be able to run and test the latest build out of master easily, by installing it from {% data variables.product.prodname_registry %}.
|
||||
You may want to publish packages to {% data variables.product.prodname_registry %} on every push into the default branch. This will allow developers on your project to always be able to run and test the latest build out of the main branch easily, by installing it from {% data variables.product.prodname_registry %}.
|
||||
|
||||
* **Publish packages to a package registry**
|
||||
For many projects, publishing to a package registry is performed whenever a new version of a project is released. For example, a project that produces a JAR file may upload new releases to the Maven Central repository. Or, a .NET project may produce a nuget package and upload it to the NuGet Gallery.
|
||||
|
||||
@@ -70,6 +70,7 @@ includeGuides:
|
||||
- /actions/guides/commenting-on-an-issue-when-a-label-is-added
|
||||
- /actions/guides/moving-assigned-issues-on-project-boards
|
||||
- /actions/guides/removing-a-label-when-a-card-is-added-to-a-project-board-column
|
||||
- /actions/guides/managing-github-actions-with-github-cli
|
||||
|
||||
---
|
||||
<!-- {% link_in_list /about-continuous-integration %} -->
|
||||
@@ -104,3 +105,4 @@ includeGuides:
|
||||
<!-- {% link_in_list /commenting-on-an-issue-when-a-label-is-added %} -->
|
||||
<!-- {% link_in_list /moving-assigned-issues-on-project-boards %} -->
|
||||
<!-- {% link_in_list /removing-a-label-when-a-card-is-added-to-a-project-board-column %} -->
|
||||
<!-- {% link_in_list /managing-github-actions-with-github-cli %} -->
|
||||
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: Managing GitHub Actions with GitHub CLI
|
||||
intro: 'You can use {% data variables.product.prodname_cli %} to interact with {% data variables.product.prodname_actions %}.'
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
github-ae: '*'
|
||||
type: 'overview'
|
||||
topics:
|
||||
- 'Workflows'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
{% data reusables.actions.ae-beta %}
|
||||
|
||||
### Setting up {% data variables.product.prodname_cli %}
|
||||
|
||||
{% data reusables.cli.download-update-cli %} {% data reusables.cli.actions-cli-version %} {% data reusables.cli.cli-manual %}
|
||||
|
||||
{% data reusables.cli.cli-auth %}
|
||||
|
||||
{% data reusables.cli.cli-repo %}
|
||||
|
||||
### Managing {% data variables.product.prodname_actions %} with {% data variables.product.prodname_cli %}
|
||||
|
||||
To view all available commands related to {% data variables.product.prodname_actions %}, run `gh actions`.
|
||||
|
||||
For more information on using commands in specific scenarios, see the following procedures:
|
||||
|
||||
- "[Re-running a workflow](/actions/managing-workflow-runs/re-running-a-workflow#re-run-a-workflow-through-github-cli)"
|
||||
- "[Manually running a workflow](/actions/managing-workflow-runs/manually-running-a-workflow#running-a-workflow-using-github-cli)"
|
||||
- "[Downloading workflow artifacts](/actions/managing-workflow-runs/downloading-workflow-artifacts#download-artifacts-through-github-cli)"
|
||||
- "[Using workflow run logs](/actions/managing-workflow-runs/using-workflow-run-logs#viewing-logs-through-github-cli)"
|
||||
- "[Viewing workflow run history](/actions/managing-workflow-runs/viewing-workflow-run-history#viewing-workflow-run-history-with-github-cli)"
|
||||
- "[Disabling and enabling a workflow](/actions/managing-workflow-runs/disabling-and-enabling-a-workflow#disabling-and-enabling-workflows-through-github-cli)"
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Disabling and enabling a workflow
|
||||
intro: 'You can disable and re-enable a workflow using {% data variables.product.prodname_dotcom %} or the REST API.'
|
||||
intro: 'You can disable and re-enable a workflow using the {% data variables.product.prodname_dotcom %} UI, the REST API, or {% data variables.product.prodname_cli %}.'
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
@@ -12,7 +12,7 @@ versions:
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
{% data reusables.actions.ae-beta %}
|
||||
|
||||
Disabling a workflow allows you to stop a workflow from being triggered without having to delete the file from the repo. You can easily re-enable the workflow again on {% data variables.product.prodname_dotcom %}. You can also disable and enable a workflow using the REST API. For more information, see the "[Actions REST API](/rest/reference/actions#workflows)."
|
||||
Disabling a workflow allows you to stop a workflow from being triggered without having to delete the file from the repo. You can easily re-enable the workflow again on {% data variables.product.prodname_dotcom %}.
|
||||
|
||||
Temporarily disabling a workflow can be useful in many scenarios. These are a few examples where disabling a workflow might be helpful:
|
||||
|
||||
@@ -27,7 +27,9 @@ Temporarily disabling a workflow can be useful in many scenarios. These are a fe
|
||||
|
||||
{% endwarning %}
|
||||
|
||||
### Disabling a workflow
|
||||
### Disabling and enabling workflows with the {% data variables.product.prodname_dotcom %} UI
|
||||
|
||||
#### Disabling a workflow
|
||||
|
||||
You can manually disable a workflow so that it won't execute any workflow runs. A disabled workflow is not deleted, and can be re-enabled.
|
||||
|
||||
@@ -42,7 +44,7 @@ You can manually disable a workflow so that it won't execute any workflow runs.
|
||||
The disabled workflow is marked {% octicon "stop" aria-label="The stop icon" %} to indicate its status.
|
||||

|
||||
|
||||
### Enabling a workflow
|
||||
#### Enabling a workflow
|
||||
|
||||
You can re-enable a workflow that was previously disabled.
|
||||
|
||||
@@ -52,3 +54,23 @@ You can re-enable a workflow that was previously disabled.
|
||||

|
||||
1. Click **Enable workflow**.
|
||||

|
||||
|
||||
### Disabling and enabling workflows with {% data variables.product.prodname_cli %}
|
||||
|
||||
{% data reusables.actions.actions-cli %}
|
||||
|
||||
To disable a workflow, use the `workflow disable` subcommand. Replace `workflow` with either the name, ID, or file name of the workflow you want to disable. For example, `"Link Checker"`, `1234567`, or `"link-check-test.yml"`. If you don't specify a workflow, {% data variables.product.prodname_cli %} returns an interactive menu for you to choose a workflow.
|
||||
|
||||
```shell
|
||||
gh workflow disable <em>workflow</em>
|
||||
```
|
||||
|
||||
To enable a workflow, use the `workflow enable` subcommand. Replace `workflow` with either the name, ID, or file name of the workflow you want to enable. For example, `"Link Checker"`, `1234567`, or `"link-check-test.yml"`. If you don't specify a workflow, {% data variables.product.prodname_cli %} returns an interactive menu for you to choose a workflow.
|
||||
|
||||
```shell
|
||||
gh workflow enable <em>workflow</em>
|
||||
```
|
||||
|
||||
### Disabling and enabling workflows through the REST API
|
||||
|
||||
You can also disable and enable a workflow using the REST API. For more information, see the "[Actions REST API](/rest/reference/actions#workflows)."
|
||||
|
||||
@@ -15,6 +15,8 @@ versions:
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" or currentVersion == "github-ae@latest" %} By default, {% data variables.product.product_name %} stores build logs and artifacts for 90 days, and you can customize this retention period, depending on the type of repository. For more information, see "[Configuring the retention period for GitHub Actions artifacts and logs in your repository](/github/administering-a-repository/configuring-the-retention-period-for-github-actions-artifacts-and-logs-in-your-repository)."{% endif %}
|
||||
{% if currentVersion == "enterprise-server@2.22" %} {% data variables.product.product_name %} stores full build logs and artifacts for 90 days.{% endif %}
|
||||
|
||||
### Download artifacts with the {% data variables.product.prodname_dotcom %} UI
|
||||
|
||||
{% data reusables.repositories.permissions-statement-read %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
@@ -27,3 +29,33 @@ versions:
|
||||
{% else %}
|
||||

|
||||
{% endif %}
|
||||
|
||||
### Download artifacts with {% data variables.product.prodname_cli %}
|
||||
|
||||
{% data reusables.actions.actions-cli %}
|
||||
|
||||
{% data variables.product.prodname_cli %} will download each artifact into separate directories based on the artifact name. If only a single artifact is specified, it will be extracted into the current directory.
|
||||
|
||||
To download all artifacts generated by a workflow run, use the `run download` subcommand. Replace `run-id` with the ID of the run that you want to download artifacts from. If you don't specify a `run-id`, {% data variables.product.prodname_cli %} returns an interactive menu for you to choose a recent run.
|
||||
|
||||
```shell
|
||||
gh run download <em>run-id</em>
|
||||
```
|
||||
|
||||
To download a specific artifact from a run, use the `run download` subcommand. Replace `run-id` with the ID of the run that you want to download artifacts from. Replace `artifact-name` with the name of the artifact that you want to download.
|
||||
|
||||
```shell
|
||||
gh run download <em>run-id</em> -n <em>artifact-name</em>
|
||||
```
|
||||
|
||||
You can specify more than one artifact.
|
||||
|
||||
```shell
|
||||
gh run download <em>run-id</em> -n <em>artifact-name-1</em> -n <em>artifact-name-2</em>
|
||||
```
|
||||
|
||||
To download specific artifacts across all runs in a repository, use the `run download` subcommand.
|
||||
|
||||
```shell
|
||||
gh run download -n <em>artifact-name-1</em> -n <em>artifact-name-2</em>
|
||||
```
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Manually running a workflow
|
||||
intro: 'When a workflow is configured to run on the `workflow_dispatch` event, you can run the workflow using the REST API or from the Actions tab on {% data variables.product.prodname_dotcom %}.'
|
||||
intro: 'When a workflow is configured to run on the `workflow_dispatch` event, you can run the workflow using the Actions tab on {% data variables.product.prodname_dotcom %}, {% data variables.product.prodname_cli %}, or the REST API.'
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
@@ -31,6 +31,40 @@ To trigger the `workflow_dispatch` event on {% data variables.product.prodname_d
|
||||
1. Select the branch where the workflow will run and type the input parameters used by the workflow. Click **Run workflow**.
|
||||

|
||||
|
||||
### Running a workflow using {% data variables.product.prodname_cli %}
|
||||
|
||||
{% data reusables.actions.actions-cli %}
|
||||
|
||||
To run a workflow, use the `workflow run` subcommand. Replace the `workflow` parameter with either the name, ID, or file name of the workflow you want to run. For example, `"Link Checker"`, `1234567`, or `"link-check-test.yml"`. If you don't specify a workflow, {% data variables.product.prodname_cli %} returns an interactive menu for you to choose a workflow.
|
||||
|
||||
```shell
|
||||
gh workflow run <em>workflow</em>
|
||||
```
|
||||
|
||||
If your workflow accepts inputs, {% data variables.product.prodname_cli %} will prompt you to enter them. Alternatively, you can use `-f` or `-F` to add an input in `key=value` format. Use `-F` to read from a file.
|
||||
|
||||
```shell
|
||||
gh workflow run greet.yml -f name=mona -f greeting=hello -F data=@myfile.txt
|
||||
```
|
||||
|
||||
You can also pass inputs as JSON by using standard input.
|
||||
|
||||
```shell
|
||||
echo '{"name":"mona", "greeting":"hello"}' | gh workflow run greet.yml --json
|
||||
```
|
||||
|
||||
To run a workflow on a branch other than the repository's default branch, use the `--ref` flag.
|
||||
|
||||
```shell
|
||||
gh workflow run <em>workflow</em> --ref <em>branch-name</em>
|
||||
```
|
||||
|
||||
To view the progress of the workflow run, use the `run watch` subcommand and select the run from the interactive list.
|
||||
|
||||
```shell
|
||||
gh run watch
|
||||
```
|
||||
|
||||
### Running a workflow using the REST API
|
||||
|
||||
When using the REST API, you configure the `inputs` and `ref` as request body parameters. If the inputs are omitted, the default values defined in the workflow file are used.
|
||||
|
||||
@@ -12,6 +12,8 @@ versions:
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
{% data reusables.actions.ae-beta %}
|
||||
|
||||
### Re-run a workflow using the {% data variables.product.prodname_dotcom %} UI
|
||||
|
||||
{% data reusables.repositories.permissions-statement-write %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
@@ -19,3 +21,19 @@ versions:
|
||||
{% data reusables.repositories.navigate-to-workflow %}
|
||||
{% data reusables.repositories.view-run %}
|
||||
1. In the upper-right corner of the workflow, use the **Re-run jobs** drop-down menu, and select **Re-run all jobs**.{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" or currentVersion == "github-ae@latest" %}{% else %}{% endif %}
|
||||
|
||||
### Re-run a workflow using {% data variables.product.prodname_cli %}
|
||||
|
||||
{% data reusables.actions.actions-cli %}
|
||||
|
||||
To re-run a failed workflow run, use the `run rerun` subcommand. Replace `run-id` with the ID of the failed run that you want to re-run. If you don't specify a `run-id`, {% data variables.product.prodname_cli %} returns an interactive menu for you to choose a recent failed run.
|
||||
|
||||
```shell
|
||||
gh run rerun <em>run-id</em>
|
||||
```
|
||||
|
||||
To view the progress of the workflow run, use the `run watch` subcommand and select the run from the interactive list.
|
||||
|
||||
```shell
|
||||
gh run watch
|
||||
```
|
||||
|
||||
@@ -109,3 +109,31 @@ After deleting logs, the **Delete all logs** button is removed to indicate that
|
||||

|
||||
After the logs have been deleted, the **Delete all logs** button is removed to indicate that no log files remain in the workflow run.
|
||||
{% endif %}
|
||||
|
||||
### Viewing logs with {% data variables.product.prodname_cli %}
|
||||
|
||||
{% data reusables.actions.actions-cli %}
|
||||
|
||||
To view the log for a specific job, use the `run view` subcommand. Replace `run-id` with the ID of run that you want to view logs for. {% data variables.product.prodname_cli %} returns an interactive menu for you to choose a job from the run. If you don't specify `run-id`, {% data variables.product.prodname_cli %} returns an interactive menu for you to choose a recent run, and then returns another interactive menu for you to choose a job from the run.
|
||||
|
||||
```shell
|
||||
gh run view <em>run-id</em> --log
|
||||
```
|
||||
|
||||
You can also use the `--job` flag to specify a job ID. Replace `job-id` with the ID of the job that you want to view logs for.
|
||||
|
||||
```shell
|
||||
gh run view --job <em>job-id</em> --log
|
||||
```
|
||||
|
||||
You can use `grep` to search the log. For example, this command will return all log entries that contain the word `error`.
|
||||
|
||||
```shell
|
||||
gh run view --job <em>job-id</em> --log | grep error
|
||||
```
|
||||
|
||||
To filter the logs for any failed steps, use `--log-failed` instead of `--log`.
|
||||
|
||||
```shell
|
||||
gh run view --job <em>job-id</em> --log-failed
|
||||
```
|
||||
|
||||
@@ -12,9 +12,67 @@ versions:
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
{% data reusables.actions.ae-beta %}
|
||||
|
||||
### Viewing workflow run history on {% data variables.product.prodname_dotcom %}
|
||||
|
||||
{% data reusables.repositories.permissions-statement-read %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
{% data reusables.repositories.navigate-to-workflow %}
|
||||
{% data reusables.repositories.view-run %}
|
||||
|
||||
### Viewing workflow run history with {% data variables.product.prodname_cli %}
|
||||
|
||||
{% data reusables.actions.actions-cli %}
|
||||
|
||||
#### Viewing recent workflow runs
|
||||
|
||||
To list the recent workflow runs, use the `run list` subcommand.
|
||||
|
||||
```shell
|
||||
gh run list
|
||||
```
|
||||
|
||||
To specify the maximum number of runs to return, you can use the `-L` or `--limit` flag . The default is `10`.
|
||||
|
||||
```shell
|
||||
gh run list --limit 5
|
||||
```
|
||||
|
||||
To only return runs for the specified workflow, you can use the `-w` or `--workflow` flag. Replace `workflow` with either the workflow name, workflow ID, or workflow file name. For example, `"Link Checker"`, `1234567`, or `"link-check-test.yml"`.
|
||||
|
||||
```shell
|
||||
gh run list --workflow <em>workflow</em>
|
||||
```
|
||||
|
||||
#### Viewing details for a specific workflow run
|
||||
|
||||
To display details for a specific workflow run, use the `run view` subcommand. Replace `run-id` with the ID of the run that you want to view. If you don't specify a `run-id`, {% data variables.product.prodname_cli %} returns an interactive menu for you to choose a recent run.
|
||||
|
||||
```shell
|
||||
gh run view <em>run-id</em>
|
||||
```
|
||||
|
||||
To include job steps in the output, use the `-v` or `--verbose` flag.
|
||||
|
||||
```shell
|
||||
gh run view <em>run-id</em> --verbose
|
||||
```
|
||||
|
||||
To view details for a specific job in the run, use the `-j` or `--job` flag. Replace `job-id` with the ID of the job that you want to view.
|
||||
|
||||
```shell
|
||||
gh run view --job <em>job-id</em>
|
||||
```
|
||||
|
||||
To view the full log for a job, use the `--log` flag.
|
||||
|
||||
```shell
|
||||
gh run view --job <em>job-id</em> --log
|
||||
```
|
||||
|
||||
Use the `--exit-status` flag to exit with a non-zero status if the run failed. For example:
|
||||
|
||||
```shell
|
||||
gh run view 0451 --exit-status && echo "run pending or passed"
|
||||
```
|
||||
|
||||
@@ -899,7 +899,7 @@ The order that you define a `matrix` matters. The first option you define will b
|
||||
|
||||
#### Example running with more than one version of Node.js
|
||||
|
||||
You can specify a matrix by supplying an array for the configuration options. For example, if the runner supports Node.js versions 6, 8, and 10, you could specify an array of those versions in the `matrix`.
|
||||
You can specify a matrix by supplying an array for the configuration options. For example, if the runner supports Node.js versions 10, 12, and 14, you could specify an array of those versions in the `matrix`.
|
||||
|
||||
This example creates a matrix of three jobs by setting the `node` key to an array of three Node.js versions. To use the matrix, the example sets the `matrix.node` context property as the value of the `setup-node` action's input parameter `node-version`. As a result, three jobs will run, each using a different Node.js version.
|
||||
|
||||
@@ -907,10 +907,10 @@ This example creates a matrix of three jobs by setting the `node` key to an arra
|
||||
```yaml
|
||||
strategy:
|
||||
matrix:
|
||||
node: [6, 8, 10]
|
||||
node: [10, 12, 14]
|
||||
steps:
|
||||
# Configures the node version used on GitHub-hosted runners
|
||||
- uses: actions/setup-node@v1
|
||||
- uses: actions/setup-node@v2
|
||||
with:
|
||||
# The Node.js version to configure
|
||||
node-version: ${{ matrix.node }}
|
||||
@@ -934,9 +934,9 @@ runs-on: ${{ matrix.os }}
|
||||
strategy:
|
||||
matrix:
|
||||
os: [ubuntu-16.04, ubuntu-18.04]
|
||||
node: [6, 8, 10]
|
||||
node: [10, 12, 14]
|
||||
steps:
|
||||
- uses: actions/setup-node@v1
|
||||
- uses: actions/setup-node@v2
|
||||
with:
|
||||
node-version: ${{ matrix.node }}
|
||||
```
|
||||
@@ -948,7 +948,7 @@ steps:
|
||||
|
||||
#### Example including additional values into combinations
|
||||
|
||||
You can add additional configuration options to a build matrix job that already exists. For example, if you want to use a specific version of `npm` when the job that uses `windows-latest` and version 4 of `node` runs, you can use `include` to specify that additional option.
|
||||
You can add additional configuration options to a build matrix job that already exists. For example, if you want to use a specific version of `npm` when the job that uses `windows-latest` and version 8 of `node` runs, you can use `include` to specify that additional option.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
@@ -956,29 +956,29 @@ runs-on: ${{ matrix.os }}
|
||||
strategy:
|
||||
matrix:
|
||||
os: [macos-latest, windows-latest, ubuntu-18.04]
|
||||
node: [4, 6, 8, 10]
|
||||
node: [8, 10, 12, 14]
|
||||
include:
|
||||
# includes a new variable of npm with a value of 2
|
||||
# includes a new variable of npm with a value of 6
|
||||
# for the matrix leg matching the os and version
|
||||
- os: windows-latest
|
||||
node: 4
|
||||
npm: 2
|
||||
node: 8
|
||||
npm: 6
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### Example including new combinations
|
||||
|
||||
You can use `include` to add new jobs to a build matrix. Any unmatched include configurations are added to the matrix. For example, if you want to use `node` version 12 to build on multiple operating systems, but wanted one extra experimental job using node version 13 on Ubuntu, you can use `include` to specify that additional job.
|
||||
You can use `include` to add new jobs to a build matrix. Any unmatched include configurations are added to the matrix. For example, if you want to use `node` version 14 to build on multiple operating systems, but wanted one extra experimental job using node version 15 on Ubuntu, you can use `include` to specify that additional job.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
runs-on: ${{ matrix.os }}
|
||||
strategy:
|
||||
matrix:
|
||||
node: [12]
|
||||
node: [14]
|
||||
os: [macos-latest, windows-latest, ubuntu-18.04]
|
||||
include:
|
||||
- node: 13
|
||||
- node: 15
|
||||
os: ubuntu-18.04
|
||||
experimental: true
|
||||
```
|
||||
@@ -994,11 +994,11 @@ runs-on: ${{ matrix.os }}
|
||||
strategy:
|
||||
matrix:
|
||||
os: [macos-latest, windows-latest, ubuntu-18.04]
|
||||
node: [4, 6, 8, 10]
|
||||
node: [8, 10, 12, 14]
|
||||
exclude:
|
||||
# excludes node 4 on macOS
|
||||
# excludes node 8 on macOS
|
||||
- os: macos-latest
|
||||
node: 4
|
||||
node: 8
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
@@ -1033,7 +1033,7 @@ Prevents a workflow run from failing when a job fails. Set to `true` to allow a
|
||||
|
||||
#### Example preventing a specific failing matrix job from failing a workflow run
|
||||
|
||||
You can allow specific jobs in a job matrix to fail without failing the workflow run. For example, if you wanted to only allow an experimental job with `node` set to `13` to fail without failing the workflow run.
|
||||
You can allow specific jobs in a job matrix to fail without failing the workflow run. For example, if you wanted to only allow an experimental job with `node` set to `15` to fail without failing the workflow run.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
@@ -1042,11 +1042,11 @@ continue-on-error: ${{ matrix.experimental }}
|
||||
strategy:
|
||||
fail-fast: false
|
||||
matrix:
|
||||
node: [11, 12]
|
||||
node: [13, 14]
|
||||
os: [macos-latest, ubuntu-18.04]
|
||||
experimental: [false]
|
||||
include:
|
||||
- node: 13
|
||||
- node: 15
|
||||
os: ubuntu-18.04
|
||||
experimental: true
|
||||
```
|
||||
@@ -1064,7 +1064,7 @@ If you do not set a `container`, all steps will run directly on the host specifi
|
||||
jobs:
|
||||
my_job:
|
||||
container:
|
||||
image: node:10.16-jessie
|
||||
image: node:14.16
|
||||
env:
|
||||
NODE_ENV: development
|
||||
ports:
|
||||
@@ -1079,7 +1079,7 @@ When you only specify a container image, you can omit the `image` keyword.
|
||||
```yaml
|
||||
jobs:
|
||||
my_job:
|
||||
container: node:10.16-jessie
|
||||
container: node:14.16
|
||||
```
|
||||
|
||||
### `jobs.<job_id>.container.image`
|
||||
|
||||
@@ -767,6 +767,19 @@ registries:
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
The `docker-registry` type can also be used to pull from Amazon ECR using static AWS credentials.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
registries:
|
||||
ecr-docker:
|
||||
type: docker-registry
|
||||
url: https://1234567890.dkr.ecr.us-east-1.amazonaws.com
|
||||
username: ${{secrets.ECR_AWS_ACCESS_KEY_ID}}
|
||||
password: ${{secrets.ECR_AWS_SECRET_ACCESS_KEY}}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
#### `git`
|
||||
|
||||
The `git` type supports username and password.
|
||||
@@ -907,4 +920,4 @@ registries:
|
||||
url: https://rubygems.pkg.github.com/octocat/github_api
|
||||
token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
|
||||
```
|
||||
{% endraw %}
|
||||
{% endraw %}
|
||||
|
||||
@@ -186,6 +186,7 @@ An overview of some of the most common actions that are recorded as events in th
|
||||
|
||||
| Action | Description
|
||||
|------------------|-------------------
|
||||
| `custom_amount_settings_change` | Triggered when you enable or disable custom amounts, or when you change the suggested custom amount (see "[Managing your sponsorship tiers](/github/supporting-the-open-source-community-with-github-sponsors/managing-your-sponsorship-tiers)")
|
||||
| `repo_funding_links_file_action` | Triggered when you change the FUNDING file in your repository (see "[Displaying a sponsor button in your repository](/articles/displaying-a-sponsor-button-in-your-repository)")
|
||||
| `sponsor_sponsorship_cancel` | Triggered when you cancel a sponsorship (see "[Downgrading a sponsorship](/articles/downgrading-a-sponsorship)")
|
||||
| `sponsor_sponsorship_create` | Triggered when you sponsor an account (see "[Sponsoring an open source contributor](/github/supporting-the-open-source-community-with-github-sponsors/sponsoring-an-open-source-contributor)")
|
||||
@@ -265,4 +266,3 @@ An overview of some of the most common actions that are recorded as events in th
|
||||
|--------------------|---------------------
|
||||
| `update` | Triggered when you set or change the status on your profile. For more information, see "[Setting a status](/articles/personalizing-your-profile/#setting-a-status)."
|
||||
| `destroy` | Triggered when you clear the status on your profile.
|
||||
|
||||
|
||||
@@ -593,6 +593,7 @@ For more information, see "[Managing the publication of {% data variables.produc
|
||||
|
||||
| Action | Description
|
||||
|------------------|-------------------
|
||||
| `custom_amount_settings_change` | Triggered when you enable or disable custom amounts, or when you change the suggested custom amount (see "[Managing your sponsorship tiers](/github/supporting-the-open-source-community-with-github-sponsors/managing-your-sponsorship-tiers)")
|
||||
| `repo_funding_links_file_action` | Triggered when you change the FUNDING file in your repository (see "[Displaying a sponsor button in your repository](/articles/displaying-a-sponsor-button-in-your-repository)")
|
||||
| `sponsor_sponsorship_cancel` | Triggered when you cancel a sponsorship (see "[Downgrading a sponsorship](/articles/downgrading-a-sponsorship)")
|
||||
| `sponsor_sponsorship_create` | Triggered when you sponsor an account (see "[Sponsoring an open source contributor](/github/supporting-the-open-source-community-with-github-sponsors/sponsoring-an-open-source-contributor)")
|
||||
|
||||
17
data/release-notes/2-21/19.yml
Normal file
17
data/release-notes/2-21/19.yml
Normal file
@@ -0,0 +1,17 @@
|
||||
date: '2021-04-14'
|
||||
sections:
|
||||
security_fixes:
|
||||
- Packages have been updated to the latest security versions.
|
||||
bugs:
|
||||
- 'A warning message `jq: error (at <stdin>:0): Cannot index number with string "settings"` could occur during replica promotion.'
|
||||
- Visiting the `/settings/emails page` would store state that could cause improper redirects when logging out and logging back in.
|
||||
- Dependency graph alerts weren''t shown for some components whose advisories have upper case package names in `vulnerable_version_ranges`.
|
||||
- User saw 500 error when executing git operations on an instance configured with LDAP authentication.
|
||||
- When ghe-migrator encountered import errors, it would sometimes abort the entire process, and the logs did not include enough context.
|
||||
known_issues:
|
||||
- On a freshly set up GitHub Enterprise Server without any users, an attacker could create the first admin user.
|
||||
- Custom firewall rules are not maintained during an upgrade.
|
||||
- Git LFS tracked files [uploaded through the web interface](https://github.com/blog/2105-upload-files-to-your-repositories) are incorrectly added directly to the repository.
|
||||
- Issues cannot be closed if they contain a permalink to a blob in the same repository where the file path is longer than 255 characters.
|
||||
- When "Users can search GitHub.com" is enabled with GitHub Connect, issues in private and internal repositories are not included in GitHub.com search results.
|
||||
- Security alerts are not reported when pushing to a repository on the command line.
|
||||
18
data/release-notes/2-22/11.yml
Normal file
18
data/release-notes/2-22/11.yml
Normal file
@@ -0,0 +1,18 @@
|
||||
date: '2021-04-14'
|
||||
sections:
|
||||
security_fixes:
|
||||
- Packages have been updated to the latest security versions.
|
||||
bugs:
|
||||
- 'A warning message `jq: error (at <stdin>:0): Cannot index number with string "settings"` could occur during replica promotion.'
|
||||
- Continuously restoring backups to a cluster could fail due to MySQL replicas failing to connect to the primary.
|
||||
- Syntax highlighting could fail due to the Treelights container running out of memory.
|
||||
- Visiting the `/settings/emails page` would store state that could cause improper redirects when logging out and logging back in.
|
||||
- Dependency graph alerts weren''t shown for some components whose advisories have upper case package names in `vulnerable_version_ranges`.
|
||||
- GitHub integration apps were not able to notify teams when mentioned directly via an at-mention in an issue comment.
|
||||
- When ghe-migrator encountered import errors, it would sometimes abort the entire process, and the logs did not include enough context.
|
||||
known_issues:
|
||||
- On a freshly set up GitHub Enterprise Server without any users, an attacker could create the first admin user.
|
||||
- Custom firewall rules are not maintained during an upgrade.
|
||||
- Git LFS tracked files [uploaded through the web interface](https://github.com/blog/2105-upload-files-to-your-repositories) are incorrectly added directly to the repository.
|
||||
- Issues cannot be closed if they contain a permalink to a blob in the same repository where the file path is longer than 255 characters.
|
||||
- When "Users can search GitHub.com" is enabled with GitHub Connect, issues in private and internal repositories are not included in GitHub.com search results.
|
||||
24
data/release-notes/3-0/5.yml
Normal file
24
data/release-notes/3-0/5.yml
Normal file
@@ -0,0 +1,24 @@
|
||||
date: '2021-04-14'
|
||||
sections:
|
||||
security_fixes:
|
||||
- Packages have been updated to the latest security versions.
|
||||
bugs:
|
||||
- Some logs were not included in the log forwarding configuration.
|
||||
- 'A warning message `jq: error (at <stdin>:0): Cannot index number with string "settings"` could occur during replica promotion.'
|
||||
- Continuously restoring backups to a cluster could fail due to MySQL replicas failing to connect to the primary.
|
||||
- Pages were not getting published when using custom CA certificate.
|
||||
- Packages related subdomains were not showing up in the "Test domain settings" prompt for subdomain isolation.
|
||||
- The `X-GitHub-Enterprise-Host` header sent with webhooks included a random string, rather than the hostname of the GitHub Enterprise Server instance that sent the HTTP POST payload.
|
||||
- Upgrading from 2.22.x to 3.0.x would fail if GitHub Actions had previously been enabled, but disabled before the upgrade.
|
||||
- Visiting the `/settings/emails page` would store state that could cause improper redirects when logging out and logging back in.
|
||||
- GitHub integration apps were not able to notify teams when mentioned directly via an at-mention in an issue comment.
|
||||
- reStructuredText (RST) rendering in the web UI would fail and instead displayed raw RST markup text.
|
||||
- Email notifications for Secret Scanning alerts were not sent to authorized users when the Dependency Graph was not fully enabled.
|
||||
- When ghe-migrator encountered import errors, it would sometimes abort the entire process, and the logs did not include enough context.
|
||||
- Jupyter notebooks with non-ASCII characters could fail to render.
|
||||
known_issues:
|
||||
- On a freshly set up GitHub Enterprise Server without any users, an attacker could create the first admin user.
|
||||
- Custom firewall rules are not maintained during an upgrade.
|
||||
- Git LFS tracked files [uploaded through the web interface](https://github.com/blog/2105-upload-files-to-your-repositories) are incorrectly added directly to the repository.
|
||||
- Issues cannot be closed if they contain a permalink to a blob in the same repository where the file path is longer than 255 characters.
|
||||
- When "Users can search GitHub.com" is enabled with GitHub Connect, issues in private and internal repositories are not included in GitHub.com search results.
|
||||
1
data/reusables/actions/actions-cli.md
Normal file
1
data/reusables/actions/actions-cli.md
Normal file
@@ -0,0 +1 @@
|
||||
For information on setting up {% data variables.product.prodname_cli %}, see "[Managing GitHub Actions with GitHub CLI](/actions/guides/managing-github-actions-with-github-cli#setting-up-github-cli)."
|
||||
1
data/reusables/cli/actions-cli-version.md
Normal file
1
data/reusables/cli/actions-cli-version.md
Normal file
@@ -0,0 +1 @@
|
||||
To access all of the {% data variables.product.prodname_actions %}-related commands, you must use version 1.9.0 or greater.
|
||||
1
data/reusables/cli/cli-auth.md
Normal file
1
data/reusables/cli/cli-auth.md
Normal file
@@ -0,0 +1 @@
|
||||
{% data variables.product.prodname_cli %} can authenticate using your {% data variables.product.prodname_dotcom %} account. Before running {% data variables.product.prodname_cli %} commands, you will need to authenticate by running `gh auth login`. For more information on command line authentication, see "[`gh auth login`](https://cli.github.com/manual/gh_auth_login)."
|
||||
1
data/reusables/cli/cli-manual.md
Normal file
1
data/reusables/cli/cli-manual.md
Normal file
@@ -0,0 +1 @@
|
||||
For more information about {% data variables.product.prodname_cli %}, see [the {% data variables.product.prodname_cli %} manual](https://cli.github.com/manual/).
|
||||
1
data/reusables/cli/cli-repo.md
Normal file
1
data/reusables/cli/cli-repo.md
Normal file
@@ -0,0 +1 @@
|
||||
{% data variables.product.prodname_cli %} commands must be run within the repository that you want to interact with, so you must first navigate to the directory containing the local copy of your repository. Alternatively, you can specify a repository by passing {% if enterpriseServerVersions contains currentVersion or currentVersion == "github-ae@latest" %}`-R HOSTNAME/OWNER/REPOSITORY` or `--repo HOSTNAME/OWNER/REPOSITORY`{% else %}`-R OWNER/REPOSITORY` or `--repo OWNER/REPOSITORY`{% endif %}. {% if enterpriseServerVersions contains currentVersion or currentVersion == "github-ae@latest" %}Replace `HOSTNAME` with the name of {% data variables.product.product_location %}. {% endif %}Replace `OWNER` with owner of the repository. Replace `REPOSITORY` with the name of the repository.
|
||||
1
data/reusables/cli/download-update-cli.md
Normal file
1
data/reusables/cli/download-update-cli.md
Normal file
@@ -0,0 +1 @@
|
||||
To download or upgrade {% data variables.product.prodname_cli %}, follow the instructions in the [{% data variables.product.prodname_cli %} README](https://github.com/cli/cli#installation).
|
||||
30
script/lint-translation-files.js
Executable file
30
script/lint-translation-files.js
Executable file
@@ -0,0 +1,30 @@
|
||||
#!/usr/bin/env node
|
||||
|
||||
const { execSync } = require('child_process')
|
||||
|
||||
// [start-readme]
|
||||
//
|
||||
// Use this script as part of the Crowdin merge process to output a list of parsing and rendering
|
||||
// errors in translated files and run script/reset-translated-file.js on them.
|
||||
//
|
||||
// [end-readme]
|
||||
|
||||
const parsingErrorsLog = '~/docs-translation-parsing-error.txt'
|
||||
const renderErrorsLog = '~/docs-translation-rendering-error.txt'
|
||||
|
||||
// 1. Check for parsing errors and output to file. Note this one must be run FIRST.
|
||||
execSync(`TEST_TRANSLATION=true npx jest content/lint-files > ${parsingErrorsLog}`)
|
||||
|
||||
// 2. Check for rendering errors and output to file. Note this one must be run SECOND.
|
||||
execSync(`script/test-render-translation.js > ${renderErrorsLog}`)
|
||||
|
||||
// Reset the broken files.
|
||||
execSync(`cat ${parsingErrorsLog} ${renderErrorsLog} | egrep "^translations/.*/(.+.md|.+.yml)$" | uniq | xargs -L1 script/reset-translated-file.js --prefer-main`)
|
||||
|
||||
// Print a message with next steps.
|
||||
console.log(`Success!
|
||||
|
||||
Verify changes with git status and then run:
|
||||
|
||||
git commit --no-verify -m "Reverted translated files with parsing and rendering errors"
|
||||
`)
|
||||
55
script/reset-known-broken-translation-files.js
Executable file
55
script/reset-known-broken-translation-files.js
Executable file
@@ -0,0 +1,55 @@
|
||||
#!/usr/bin/env node
|
||||
|
||||
require('dotenv').config()
|
||||
const github = require('./helpers/github')()
|
||||
const { promisify } = require('util')
|
||||
const exec = promisify(require('child_process').exec)
|
||||
|
||||
// Check for required PAT
|
||||
if (!process.env.GITHUB_TOKEN) {
|
||||
console.error('Error! You must have a GITHUB_TOKEN set in an .env file to run this script.')
|
||||
process.exit(1)
|
||||
}
|
||||
|
||||
// [start-readme]
|
||||
//
|
||||
// Use this script as part of the Crowdin merge process to get the list of known broken
|
||||
// files and run script/reset-translated-file.js on them.
|
||||
//
|
||||
// [end-readme]
|
||||
|
||||
main()
|
||||
|
||||
async function main () {
|
||||
// Get body text of OP from https://github.com/github/localization-support/issues/489.
|
||||
const { data: { body } } = await github.issues.get({
|
||||
owner: 'github',
|
||||
repo: 'localization-support',
|
||||
issue_number: '489'
|
||||
})
|
||||
|
||||
// Get the list of broken files from the body text.
|
||||
const brokenFiles = body
|
||||
.replace(/^[\s\S]*?## List of Broken Translations/m, '')
|
||||
.trim()
|
||||
|
||||
// Turn it into a simple array of files.
|
||||
const brokenFilesArray = brokenFiles
|
||||
.split('\n')
|
||||
.map(line => line.replace('- [ ] ', '').trim())
|
||||
|
||||
// Run the script to revert them.
|
||||
await Promise.all(brokenFilesArray.map(async (file) => {
|
||||
console.log(`resetting ${file}`)
|
||||
await exec(`script/reset-translated-file.js --prefer-main ${file}`)
|
||||
}))
|
||||
|
||||
// Print a message with next steps.
|
||||
console.log(`
|
||||
Success!
|
||||
|
||||
Verify changes with git status and then run:
|
||||
|
||||
git commit --no-verify -m "Reset broken translated files to English"
|
||||
`)
|
||||
}
|
||||
108
script/update-crowdin-issue.js
Executable file
108
script/update-crowdin-issue.js
Executable file
@@ -0,0 +1,108 @@
|
||||
#!/usr/bin/env node
|
||||
|
||||
require('dotenv').config()
|
||||
const github = require('./helpers/github')()
|
||||
const { execSync } = require('child_process')
|
||||
|
||||
// Check for required PAT
|
||||
if (!process.env.GITHUB_TOKEN) {
|
||||
console.error('Error! You must have a GITHUB_TOKEN set in an .env file to run this script.')
|
||||
process.exit(1)
|
||||
}
|
||||
|
||||
// [start-readme]
|
||||
//
|
||||
// Use this script as the last step of the Crowdin merge process to:
|
||||
// 1. Add newly found broken translated files to the localization-support issue OP.
|
||||
// 2. Add a comment on the issue with more details.
|
||||
//
|
||||
// [end-readme]
|
||||
|
||||
const fixableErrorsLog = '~/docs-translation-errors-fixable.txt'
|
||||
const parsingErrorsLog = '~/docs-translation-parsing-error.txt'
|
||||
const renderingErrorsLog = '~/docs-translation-rendering-error.txt'
|
||||
|
||||
// Get just the fixable files:
|
||||
const fixable = execSync(`cat ${fixableErrorsLog} | egrep "^translations/.*/(.+.md|.+.yml)$" | sed -e 's/^/- [ ] /' | uniq`).toString()
|
||||
|
||||
// Get a list of files to be added to the body of the issue
|
||||
const filesToAdd = execSync(`cat ${parsingErrorsLog} ${renderingErrorsLog} | egrep "^translations/.*/(.+.md|.+.yml)$" | sed -e 's/^/- [ ] /' | uniq`).toString()
|
||||
|
||||
// Cat the three error logs together
|
||||
const allErrors = execSync('cat ~/docs-*').toString()
|
||||
|
||||
const comment = `
|
||||
Did a fresh merge today!
|
||||
|
||||
<details>
|
||||
<summary>In addition to the files in the PR body, these files also have errors, but can be fixed programmatically:</summary>
|
||||
|
||||
${fixable}
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>Here are the <b>new</b> errors:</summary>
|
||||
|
||||
\`\`\`
|
||||
|
||||
${allErrors}
|
||||
|
||||
\`\`\`
|
||||
|
||||
</details>
|
||||
`
|
||||
|
||||
const owner = 'github'
|
||||
const repo = 'localization-support'
|
||||
const issueNumber = '489'
|
||||
|
||||
main()
|
||||
|
||||
async function main () {
|
||||
await updateIssueBody()
|
||||
await addNewComment()
|
||||
|
||||
console.log('Success! You can safely delete the temporary logfiles under ~/docs-*.')
|
||||
}
|
||||
|
||||
async function updateIssueBody () {
|
||||
// Get current body text of OP from https://github.com/github/localization-support/issues/489.
|
||||
const { data: { body } } = await github.issues.get({
|
||||
owner,
|
||||
repo,
|
||||
issue_number: issueNumber
|
||||
})
|
||||
|
||||
// Update the body with the list of newly broken files
|
||||
const newBody = body + '\n' + filesToAdd
|
||||
|
||||
// Update the issue
|
||||
try {
|
||||
await github.issues.update({
|
||||
owner,
|
||||
repo,
|
||||
issue_number: issueNumber,
|
||||
body: newBody
|
||||
})
|
||||
|
||||
console.log('Added newly found broken files to OP of https://github.com/github/localization-support/issues/489!\n')
|
||||
} catch (err) {
|
||||
console.error(err)
|
||||
}
|
||||
}
|
||||
|
||||
async function addNewComment () {
|
||||
try {
|
||||
await github.issues.createComment({
|
||||
owner,
|
||||
repo,
|
||||
issue_number: issueNumber,
|
||||
body: comment
|
||||
})
|
||||
|
||||
console.log('Added comment to the end of https://github.com/github/localization-support/issues/489!\n')
|
||||
} catch (err) {
|
||||
console.error(err)
|
||||
}
|
||||
}
|
||||
@@ -199,10 +199,12 @@ if (!process.env.TEST_TRANSLATION) {
|
||||
const ghesReleaseNotesYamlRelPaths = ghesReleaseNotesYamlAbsPaths.map(p => path.relative(rootDir, p))
|
||||
releaseNotesToLint = zip(ghesReleaseNotesYamlRelPaths, ghesReleaseNotesYamlAbsPaths)
|
||||
} else {
|
||||
console.log('testing translations.')
|
||||
|
||||
// get all translated markdown or yaml files by comparing files changed to main branch
|
||||
const changedFilesRelPaths = execSync('git diff --name-only origin/main | egrep "^translations/.*/.+.(yml|md)$"', { maxBuffer: 1024 * 1024 * 100 }).toString().split('\n')
|
||||
if (changedFilesRelPaths === '') process.exit(0)
|
||||
|
||||
console.log('testing translations.')
|
||||
|
||||
console.log(`Found ${changedFilesRelPaths.length} translated files.`)
|
||||
|
||||
const { mdRelPaths = [], ymlRelPaths = [], releaseNotesRelPaths = [] } = groupBy(changedFilesRelPaths, (path) => {
|
||||
|
||||
@@ -32,7 +32,8 @@ const ALLOW_LIST = new Set([
|
||||
'smimesign',
|
||||
'tweetsodium',
|
||||
'choosealicense.com',
|
||||
'renaming'
|
||||
'renaming',
|
||||
'localization-support'
|
||||
])
|
||||
|
||||
describe('check for repository references', () => {
|
||||
|
||||
Reference in New Issue
Block a user