From 64879f591386ed8e1103f9cba9ccf5aea1a262b8 Mon Sep 17 00:00:00 2001 From: Siara <108543037+SiaraMist@users.noreply.github.com> Date: Mon, 22 Jan 2024 15:57:27 -0800 Subject: [PATCH] Actions bug fix hour for week of January 15, 2024 (#48801) --- ...ncurrency-expressions-and-a-test-matrix.md | 42 +++++++++---------- .../security-hardening-for-github-actions.md | 2 + .../using-secrets-in-github-actions.md | 4 -- .../actions/about-oidc-short-overview.md | 2 - ...eating-a-runner-group-for-an-enterprise.md | 2 +- .../oidc-custom-claims-aws-restriction.md | 2 +- 6 files changed, 25 insertions(+), 29 deletions(-) diff --git a/content/actions/examples/using-concurrency-expressions-and-a-test-matrix.md b/content/actions/examples/using-concurrency-expressions-and-a-test-matrix.md index 99375cd460..a1da13cbac 100644 --- a/content/actions/examples/using-concurrency-expressions-and-a-test-matrix.md +++ b/content/actions/examples/using-concurrency-expressions-and-a-test-matrix.md @@ -55,13 +55,13 @@ name: Node.js Tests # The `on` keyword lets you define the events that trigger when the workflow is run. You can define multiple events here. For more information, see "[AUTOTITLE](/actions/using-workflows/triggering-a-workflow#using-events-to-trigger-workflows)." on: -# Add the `workflow_dispatch` event if you want to be able to manually run this workflow. For more information, see [`workflow_dispatch`](/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch). + # Add the `workflow_dispatch` event if you want to be able to manually run this workflow. For more information, see [`workflow_dispatch`](/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch). workflow_dispatch: -# Add the `pull_request` event, so that the workflow runs automatically every time a pull request is created or updated. For more information, see [`pull_request`](/actions/using-workflows/events-that-trigger-workflows#pull_request). + # Add the `pull_request` event, so that the workflow runs automatically every time a pull request is created or updated. For more information, see [`pull_request`](/actions/using-workflows/events-that-trigger-workflows#pull_request). pull_request: -# Add the `push` event with the `branch` filter, so that the workflow runs automatically every time a commit is pushed to a branch called "main". For more information, see [`push`](/actions/using-workflows/events-that-trigger-workflows#push). + # Add the `push` event with the `branch` filter, so that the workflow runs automatically every time a commit is pushed to a branch called "main". For more information, see [`push`](/actions/using-workflows/events-that-trigger-workflows#push). push: branches: - main @@ -81,24 +81,24 @@ concurrency: # This groups together all the jobs that run in the workflow file. jobs: -# This defines a job with the ID `test` that is stored within the `jobs` key. + # This defines a job with the ID `test` that is stored within the `jobs` key. test: -# This configures the job to run on a {% data variables.product.prodname_dotcom %}-hosted runner or a self-hosted runner, depending on the repository running the workflow. -# -# In this example, the job will run on a self-hosted runner if the repository is named `docs-internal` and is within the `github` organization. If the repository doesn't match this path, then it will run on an `ubuntu-latest` runner hosted by {% data variables.product.prodname_dotcom %}. For more information on these options, see "[AUTOTITLE](/actions/using-jobs/choosing-the-runner-for-a-job)." + # This configures the job to run on a {% data variables.product.prodname_dotcom %}-hosted runner or a self-hosted runner, depending on the repository running the workflow. + # + # In this example, the job will run on a self-hosted runner if the repository is named `docs-internal` and is within the `github` organization. If the repository doesn't match this path, then it will run on an `ubuntu-latest` runner hosted by {% data variables.product.prodname_dotcom %}. For more information on these options, see "[AUTOTITLE](/actions/using-jobs/choosing-the-runner-for-a-job)." runs-on: {% raw %}${{ fromJSON('["ubuntu-latest", "self-hosted"]')[github.repository == 'github/docs-internal'] }}{% endraw %} -# This sets the maximum number of minutes to let the job run before it is automatically canceled. For more information, see [`timeout-minutes`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes). + # This sets the maximum number of minutes to let the job run before it is automatically canceled. For more information, see [`timeout-minutes`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes). timeout-minutes: 60 -# This section defines the build matrix for your jobs. + # This section defines the build matrix for your jobs. strategy: -# Setting `fail-fast` to `false` prevents {% data variables.product.prodname_dotcom %} from cancelling all in-progress jobs if any matrix job fails. + # Setting `fail-fast` to `false` prevents {% data variables.product.prodname_dotcom %} from cancelling all in-progress jobs if any matrix job fails. fail-fast: false -# This creates a matrix named `test-group`, with an array of test groups. These values match the names of test groups that will be run by `npm test`. + # This creates a matrix named `test-group`, with an array of test groups. These values match the names of test groups that will be run by `npm test`. matrix: test-group: [ @@ -112,56 +112,56 @@ jobs: translations, ] -# This groups together all the steps that will run as part of the `test` job. Each job in a workflow has its own `steps` section. + # This groups together all the steps that will run as part of the `test` job. Each job in a workflow has its own `steps` section. steps: -# The `uses` keyword tells the job to retrieve the action named `actions/checkout`. This is an action that checks out your repository and downloads it to the runner, allowing you to run actions against your code (such as testing tools). You must use the checkout action any time your workflow will use your repository's code. Some extra options are provided to the action using the `with` key. + # The `uses` keyword tells the job to retrieve the action named `actions/checkout`. This is an action that checks out your repository and downloads it to the runner, allowing you to run actions against your code (such as testing tools). You must use the checkout action any time your workflow will use your repository's code. Some extra options are provided to the action using the `with` key. - name: Check out repo uses: {% data reusables.actions.action-checkout %} with: lfs: {% raw %}${{ matrix.test-group == 'content' }}{% endraw %} persist-credentials: 'false' -# This step runs a command to check out large file storage (LFS) objects from the repository. + # This step runs a command to check out large file storage (LFS) objects from the repository. - name: Checkout LFS objects run: git lfs checkout -# This step uses the `trilom/file-changes-action` action to gather the files changed in the pull request, so they can be analyzed in the next step. This example is pinned to a specific version of the action, using the `a6ca26c14274c33b15e6499323aac178af06ad4b` SHA. + # This step uses the `trilom/file-changes-action` action to gather the files changed in the pull request, so they can be analyzed in the next step. This example is pinned to a specific version of the action, using the `a6ca26c14274c33b15e6499323aac178af06ad4b` SHA. - name: Gather files changed uses: trilom/file-changes-action@a6ca26c14274c33b15e6499323aac178af06ad4b id: get_diff_files with: output: ' ' -# This step runs a shell command that uses an output from the previous step to create a file containing the list of files changed in the pull request. + # This step runs a shell command that uses an output from the previous step to create a file containing the list of files changed in the pull request. - name: Insight into changed files run: | echo {% raw %}"${{ steps.get_diff_files.outputs.files }}" > get_diff_files.txt{% endraw %} -# This step uses the `actions/setup-node` action to install the specified version of the `node` software package on the runner, which gives you access to the `npm` command. + # This step uses the `actions/setup-node` action to install the specified version of the `node` software package on the runner, which gives you access to the `npm` command. - name: Setup node uses: {% data reusables.actions.action-setup-node %} with: node-version: 16.14.x cache: npm -# This step runs the `npm ci` shell command to install the npm software packages for the project. + # This step runs the `npm ci` shell command to install the npm software packages for the project. - name: Install dependencies run: npm ci -# {% ifversion actions-caching %}This step uses the `actions/cache` action to cache the Next.js build, so that the workflow will attempt to retrieve a cache of the build, and not rebuild it from scratch every time. For more information, see "[AUTOTITLE](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)."{% endif %} + # {% ifversion actions-caching %}This step uses the `actions/cache` action to cache the Next.js build, so that the workflow will attempt to retrieve a cache of the build, and not rebuild it from scratch every time. For more information, see "[AUTOTITLE](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)."{% endif %} - name: Cache nextjs build uses: {% data reusables.actions.action-cache %} with: path: .next/cache key: {% raw %}${{ runner.os }}-nextjs-${{ hashFiles('package*.json') }}{% endraw %} -# This step runs the build script. + # This step runs the build script. - name: Run build script run: npm run build -# This step runs the tests using `npm test`, and the test matrix provides a different value for {% raw %}`${{ matrix.test-group }}`{% endraw %} for each job in the matrix. It uses the `DIFF_FILE` environment variable to know which files have changed, and uses the `CHANGELOG_CACHE_FILE_PATH` environment variable for the changelog cache file. + # This step runs the tests using `npm test`, and the test matrix provides a different value for {% raw %}`${{ matrix.test-group }}`{% endraw %} for each job in the matrix. It uses the `DIFF_FILE` environment variable to know which files have changed, and uses the `CHANGELOG_CACHE_FILE_PATH` environment variable for the changelog cache file. - name: Run tests env: DIFF_FILE: get_diff_files.txt diff --git a/content/actions/security-guides/security-hardening-for-github-actions.md b/content/actions/security-guides/security-hardening-for-github-actions.md index f6d0dbbc7f..a6cf50188e 100644 --- a/content/actions/security-guides/security-hardening-for-github-actions.md +++ b/content/actions/security-guides/security-hardening-for-github-actions.md @@ -181,6 +181,8 @@ To help mitigate the risk of an exposed token, consider restricting the assigned {% data reusables.actions.about-oidc-short-overview %} +{% data reusables.actions.oidc-custom-claims-aws-restriction %} + {% endif %} ## Using third-party actions diff --git a/content/actions/security-guides/using-secrets-in-github-actions.md b/content/actions/security-guides/using-secrets-in-github-actions.md index c19eddd3ee..b55c33ac70 100644 --- a/content/actions/security-guides/using-secrets-in-github-actions.md +++ b/content/actions/security-guides/using-secrets-in-github-actions.md @@ -26,16 +26,12 @@ Secrets are variables that you create in an organization, repository, or reposit For secrets stored at the environment level, you can enable required reviewers to control access to the secrets. A workflow job cannot access environment secrets until approval is granted by required approvers. -{% ifversion fpt or ghec or ghes %} - {% note %} **Note**: {% data reusables.actions.about-oidc-short-overview %} {% endnote %} -{% endif %} - ### Naming your secrets The following rules apply to secret names: diff --git a/data/reusables/actions/about-oidc-short-overview.md b/data/reusables/actions/about-oidc-short-overview.md index 6d975ab96f..9e62e3e0d1 100644 --- a/data/reusables/actions/about-oidc-short-overview.md +++ b/data/reusables/actions/about-oidc-short-overview.md @@ -1,4 +1,2 @@ If your {% data variables.product.prodname_actions %} workflows need to access resources from a cloud provider that supports OpenID Connect (OIDC), you can configure your workflows to authenticate directly to the cloud provider. This will let you stop storing these credentials as long-lived secrets and provide other security benefits. For more information, see "[AUTOTITLE](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect)" - -{% data reusables.actions.oidc-custom-claims-aws-restriction %} diff --git a/data/reusables/actions/creating-a-runner-group-for-an-enterprise.md b/data/reusables/actions/creating-a-runner-group-for-an-enterprise.md index 27ef4d27ad..66f89442da 100644 --- a/data/reusables/actions/creating-a-runner-group-for-an-enterprise.md +++ b/data/reusables/actions/creating-a-runner-group-for-an-enterprise.md @@ -9,7 +9,7 @@ Always include a security admonition above this procedure. This is either one of Enterprises can add their runners to groups for access management. Enterprises can create groups of runners that are accessible to specific organizations in the enterprise account{% ifversion restrict-groups-to-workflows %} or to specific workflows{% endif %}. Organization owners can then assign additional granular repository{% ifversion restrict-groups-to-workflows %} or workflow{% endif %} access policies to the enterprise runner groups. For information about how to create a runner group with the REST API, see the enterprise endpoints in the [{% data variables.product.prodname_actions %} REST API](/rest/actions#self-hosted-runner-groups). -If no group is specified during the registration process, runners are automatically added to a default group. You can later move the runner from the default group to a custom group. For more information, see "Moving a runner to a group." +If no group is specified during the registration process, runners are automatically added to a default group. You can later move the runner from the default group to a custom group. For more information, see "[Moving a runner to a group](#moving-a-runner-to-a-group)." When creating a group, you must choose a policy that defines which organizations have access to the runner group. diff --git a/data/reusables/actions/oidc-custom-claims-aws-restriction.md b/data/reusables/actions/oidc-custom-claims-aws-restriction.md index 77c4bf8d96..509622dbeb 100644 --- a/data/reusables/actions/oidc-custom-claims-aws-restriction.md +++ b/data/reusables/actions/oidc-custom-claims-aws-restriction.md @@ -1,5 +1,5 @@ {% note %} -**Note:** support for custom claims for OIDC is unavailable in AWS. +**Note:** Support for custom claims for OIDC is unavailable in AWS. {% endnote %}