Merge branch 'main' into patch-1

.github/workflows/orphaned-assets-check.yml → .github/workflows/orphaned-files-check.yml

@@ -1,6 +1,6 @@
-name: 'Orphaned assets check'
+name: 'Orphaned files check'
 
-# **What it does**: Checks that there are no files in ./assets/ that aren't mentioned in any source file.
+# **What it does**: Checks that there are no files in ./assets/ and ./data/reusables that aren't mentioned in any source file.
 # **Why we have it**: To avoid orphans into the repo.
 # **Who does it impact**: Docs content.
 
@@ -14,6 +14,7 @@ on:
       # In case any of the dependencies affect the script
       - 'package*.json'
       - src/assets/scripts/find-orphaned-assets.js
+      - src/content-render/scripts/reusables-cli/find/unused.ts
       - src/workflows/walk-files.js
       - src/languages/lib/languages.js
       - .github/actions/clone-translations/action.yml
@@ -44,7 +45,7 @@ jobs:
 
       - uses: ./.github/actions/node-npm-setup
 
-      - name: Check for orphaned assets
+      - name: Check for orphaned assets and reusables
         env:
           # Needed for gh
           GITHUB_TOKEN: ${{ secrets.DOCS_BOT_PAT_READPUBLICKEY }}
@@ -54,10 +55,16 @@ jobs:
 
           # The `-s` is to make npm run silent and not print verbose
           # information about the npm script alias.
-          filesToRemove=`npm run -s find-orphaned-assets`
-          [ -z "$filesToRemove" ] && exit 0
+          assetFilesToRemove=$(npm run -s find-orphaned-assets)
+          reusableFilesToRemove=$(npm run -s reusables -- find unused | grep '^data/reusables')
+          [ -z "$assetFilesToRemove" ] && [ -z "$reusableFilesToRemove" ] && exit 0
 
-          echo $filesToRemove | xargs git rm
+          if [ -n "$assetFilesToRemove" ]; then
+            echo $assetFilesToRemove | xargs git rm
+          fi
+          if [ -n "$reusableFilesToRemove" ]; then
+            echo $reusableFilesToRemove | xargs git rm
+          fi
 
           git status
 
@@ -76,25 +83,26 @@ jobs:
           git config --global user.email "77750099+docs-bot@users.noreply.github.com"
 
           date=$(date '+%Y-%m-%d-%H-%M')
-          branchname=orphaned-assets-$date-$GITHUB_RUN_ID
+          branchname=orphaned-files-$date-$GITHUB_RUN_ID
 
           git checkout -b $branchname
-          git commit -m "Delete orphaned assets $date"
+          git commit -m "Delete orphaned files $date"
           git push origin $branchname
 
           body=$(cat <<-EOM
             Found with the npm run find-orphaned-assets script.
-            The orphaned assets workflow file .github/workflows/orphaned-assets-check.yml
+            The orphaned files workflow file .github/workflows/orphaned-files-check.yml
             runs every Monday at 16:20 UTC / 8:20 PST.
             The first responder should just spot-check some of the unused assets
             to make sure they aren't referenced anywhere
             and then approve and merge the pull request.
-            For more information, see [Doc: Orphaned Assets](https://github.com/github/docs-engineering/blob/main/docs/orphaned-assets.md).
+            For more information, see [Doc: Orphaned Assets](https://github.com/github/docs-engineering/blob/main/docs/orphaned-assets.md) 
+            and [Doc: Reusables CLI](https://github.com/github/docs-internal/tree/main/src/content-render/scripts/reusables-cli).
           EOM
           )
 
           gh pr create \
-            --title "Delete orphaned assets ($date)" \
+            --title "Delete orphaned files ($date)" \
             --body "$body" \
             --repo github/docs-internal \
             --label docs-content-fr

content/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile.md

@@ -212,7 +212,7 @@ To stop private contributions from counting toward your Achievements, or to turn
 
 {% note %}
 
-**Note:** This feature is currently in beta and subject to change.
+**Note:** This feature is currently in {% data variables.release-phases.public_preview %} and subject to change.
 
 {% endnote %}
 

content/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-user-account-settings/about-your-personal-dashboard.md

@@ -51,7 +51,7 @@ You can also find a list of your recently visited repositories, teams, and proje
 
 {% note %}
 
-**Note:** The new feed is currently in public beta and subject to change.
+**Note:** The new feed is currently in {% data variables.release-phases.public_preview %} and subject to change.
 
 {% endnote %}
 
@@ -91,7 +91,7 @@ For more information about following people and starring repositories, see "[AUT
 
 {% note %}
 
-**Note:** This new tab is currently in public beta and subject to change.
+**Note:** This new tab is currently in {% data variables.release-phases.public_preview %} and subject to change.
 
 {% endnote %}
 

content/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners.md

@@ -117,7 +117,7 @@ The following operating systems are supported for the self-hosted runner applica
 The following processor architectures are supported for the self-hosted runner application.
 
 * `x64` - Linux, macOS, Windows.
-* `ARM64` - Linux, macOS{% ifversion actions-windows-arm %}, Windows (currently in beta){% endif %}.
+* `ARM64` - Linux, macOS{% ifversion actions-windows-arm %}, Windows (currently in {% data variables.release-phases.public_preview %}){% endif %}.
 * `ARM32` - Linux.
 
 {% ifversion ghes %}
@@ -216,14 +216,10 @@ Untrusted workflows running on your self-hosted runner pose significant security
 
 For more information about security hardening for self-hosted runners, see "[AUTOTITLE](/actions/security-guides/security-hardening-for-github-actions#hardening-for-self-hosted-runners)."
 
-{% ifversion actions-disable-repo-runners %}
-
 ### Restricting the use of self-hosted runners
 
 {% data reusables.actions.disable-selfhosted-runners-crossrefs %}
 
-{% endif %}
-
 {% ifversion ghec or ghes %}
 
 ## Further reading

content/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners.md

@@ -49,16 +49,12 @@ You can add self-hosted runners to a single repository. To add a self-hosted run
 
 For information about how to add a self-hosted runner with the REST API, see "[AUTOTITLE](/rest/actions/self-hosted-runners)."
 
-{% ifversion actions-disable-repo-runners %}
-
 {% note %}
 
 **Note**: {% data reusables.actions.disable-selfhosted-runners-crossrefs %}
 
 {% endnote %}
 
-{% endif %}
-
 {% data reusables.repositories.navigate-to-repo %}
 {% data reusables.repositories.sidebar-settings %}
 {% data reusables.repositories.settings-sidebar-actions-runners %}

content/actions/hosting-your-own-runners/managing-self-hosted-runners/customizing-the-containers-used-by-jobs.md

@@ -11,7 +11,7 @@ shortTitle: Customize containers used by jobs
 
 {% note %}
 
-**Note**: This feature is currently in beta and is subject to change.
+**Note**: This feature is currently in {% data variables.release-phases.public_preview %} and is subject to change.
 
 {% endnote %}
 

content/actions/hosting-your-own-runners/managing-self-hosted-runners/monitoring-and-troubleshooting-self-hosted-runners.md

@@ -17,16 +17,12 @@ shortTitle: Monitor & troubleshoot
 
 {% data reusables.actions.enterprise-github-hosted-runners %}
 
-{% ifversion actions-disable-repo-runners %}
-
 ## Using repository-level self-hosted runners
 
 You may not be able to create a self-hosted runner for an organization-owned repository.
 
 {% data reusables.actions.disable-selfhosted-runners-crossrefs %}
 
-{% endif %}
-
 ## Checking the status of a self-hosted runner
 
 {% data reusables.actions.self-hosted-runner-management-permissions-required %}
@@ -51,7 +47,7 @@ You can use the self-hosted runner application's `config` script with the `--che
 In addition to `--check`, you must provide two arguments to the script:
 
 * `--url` with the URL to your {% data variables.product.company_short %} repository, organization, or enterprise. For example, `--url https://github.com/octo-org/octo-repo`.
-* `--pat` with the value of a {% data variables.product.pat_v1 %}, which must have the `workflow` scope{% ifversion pat-v2%}, or a {% data variables.product.pat_v2 %} with workflows read and write access {% endif %}. For example, `--pat ghp_abcd1234`. For more information, see "[AUTOTITLE](/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token)."
+* `--pat` with the value of a {% data variables.product.pat_v1 %}, which must have the `workflow` scope, or a {% data variables.product.pat_v2 %} with workflows read and write access. For example, `--pat ghp_abcd1234`. For more information, see "[AUTOTITLE](/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token)."
 
 For example:
 

content/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/approving-workflow-runs-from-private-forks.md

@@ -3,7 +3,9 @@ title: Approving workflow runs from private forks
 intro: 'When someone without write access submits a pull request to a private repository, a maintainer may need to approve any workflow runs.'
 permissions: Maintainers with write access to a repository can approve workflow runs.
 versions:
-  feature: actions-private-fork-workflow-approvals
+  fpt: '*'
+  ghec: '*'
+  ghes: '*'
 shortTitle: Approve private fork runs
 redirect_from:
   - /actions/managing-workflow-runs/approving-workflow-runs-from-private-forks

content/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/re-running-workflows-and-jobs.md

@@ -16,7 +16,7 @@ versions:
 
 ## About re-running workflows and jobs
 
-Re-running a workflow{% ifversion re-run-jobs %} or jobs in a workflow{% endif %} uses the same `GITHUB_SHA` (commit SHA) and `GITHUB_REF` (Git ref) of the original event that triggered the workflow run. {% ifversion actions-stable-actor-ids %}The workflow will use the privileges of the actor who initially triggered the workflow, not the privileges of the actor who initiated the re-run. {% endif %}You can re-run a workflow{% ifversion re-run-jobs %} or jobs in a workflow{% endif %} for up to 30 days after the initial run.{% ifversion re-run-jobs %} You cannot re-run jobs in a workflow once its logs have passed their retention limits. For more information, see "[AUTOTITLE](/actions/learn-github-actions/usage-limits-billing-and-administration#artifact-and-log-retention-policy)."{% endif %}{% ifversion debug-reruns %} When you re-run a workflow or jobs in a workflow, you can enable debug logging for the re-run. This will enable runner diagnostic logging and step debug logging for the re-run. For more information about debug logging, see "[AUTOTITLE](/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging)."{% endif %}
+Re-running a workflow{% ifversion re-run-jobs %} or jobs in a workflow{% endif %} uses the same `GITHUB_SHA` (commit SHA) and `GITHUB_REF` (Git ref) of the original event that triggered the workflow run. The workflow will use the privileges of the actor who initially triggered the workflow, not the privileges of the actor who initiated the re-run. You can re-run a workflow{% ifversion re-run-jobs %} or jobs in a workflow{% endif %} for up to 30 days after the initial run.{% ifversion re-run-jobs %} You cannot re-run jobs in a workflow once its logs have passed their retention limits. For more information, see "[AUTOTITLE](/actions/learn-github-actions/usage-limits-billing-and-administration#artifact-and-log-retention-policy)."{% endif %}{% ifversion debug-reruns %} When you re-run a workflow or jobs in a workflow, you can enable debug logging for the re-run. This will enable runner diagnostic logging and step debug logging for the re-run. For more information about debug logging, see "[AUTOTITLE](/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging)."{% endif %}
 
 ## Re-running all the jobs in a workflow
 

content/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-circleci-to-github-actions.md

@@ -72,8 +72,6 @@ For more information, see "[AUTOTITLE](/actions/learn-github-actions/variables#d
 
 CircleCI and {% data variables.product.prodname_actions %} provide a method to manually cache files in the configuration file.
 
-{% ifversion actions-caching %}
-
 Below is an example of the syntax for each system.
 
 ### CircleCI syntax for caching
@@ -100,12 +98,6 @@ Below is an example of the syntax for each system.
     restore-keys: v1-npm-deps-
 ```
 
-{% else %}
-
-{% data reusables.actions.caching-availability %}
-
-{% endif %}
-
 {% data variables.product.prodname_actions %} does not have an equivalent of CircleCI’s Docker Layer Caching (or DLC).
 
 ## Persisting data between jobs

content/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-gitlab-cicd-to-github-actions.md

@@ -270,8 +270,6 @@ For more information, see "[AUTOTITLE](/actions/learn-github-actions/variables)"
 
 GitLab CI/CD and {% data variables.product.prodname_actions %} provide a method in the configuration file to manually cache workflow files.
 
-{% ifversion actions-caching %}
-
 Below is an example of the syntax for each system.
 
 ### GitLab CI/CD syntax for caching
@@ -311,12 +309,6 @@ jobs:
         restore-keys: v1-npm-deps-
 ```
 
-{% else %}
-
-{% data reusables.actions.caching-availability %}
-
-{% endif %}
-
 ## Artifacts
 
 Both GitLab CI/CD and {% data variables.product.prodname_actions %} can upload files and directories created by a job as artifacts. In {% data variables.product.prodname_actions %}, artifacts can be used to persist data across multiple jobs.

content/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-travis-ci-to-github-actions.md

@@ -270,8 +270,6 @@ jobs:
 
 Travis CI and {% data variables.product.prodname_actions %} let you manually cache dependencies for later reuse.
 
-{% ifversion actions-caching %}
-
 These examples demonstrate the cache syntax for each system.
 
 ### Travis CI syntax for caching
@@ -296,12 +294,6 @@ cache: npm
     restore-keys: v1-npm-deps-
 ```
 
-{% else %}
-
-{% data reusables.actions.caching-availability %}
-
-{% endif %}
-
 ## Examples of common tasks
 
 This section compares how {% data variables.product.prodname_actions %} and Travis CI perform common tasks.

content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/automating-migration-with-github-actions-importer.md

@@ -36,7 +36,7 @@ You can use {% data variables.product.prodname_actions_importer %} to migrate fr
 * Bamboo
 * Bitbucket Pipelines
 * CircleCI
-* GitLab
+* GitLab (both cloud and self-hosted)
 * Jenkins
 * Travis CI
 

content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-circleci-with-github-actions-importer.md

@@ -32,7 +32,7 @@ The instructions below will guide you through configuring your environment to us
 There are some limitations when migrating from CircleCI to {% data variables.product.prodname_actions %} with {% data variables.product.prodname_actions_importer %}:
 
 * Automatic caching in between jobs of different workflows is not supported.
-* The `audit` command is only supported when using an organization account. However, the `dry-run` and `migrate` commands can be used with an organization or user account.
+* The `audit` command is only supported when you use a CircleCI organization account. The `dry-run` and `migrate` commands can be used with a CircleCI organization or user account.
 
 #### Manual tasks
 

content/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions.md

@@ -297,7 +297,7 @@ This list describes the recommended approaches for accessing repository data wit
     * {% data variables.product.prodname_github_apps %} can be installed on select repositories, and even have granular permissions on the resources within them. You could create a {% data variables.product.prodname_github_app %} internal to your organization, install it on the repositories you need access to within your workflow, and authenticate as the installation within your workflow to access those repositories. For more information, see "[AUTOTITLE](/apps/creating-github-apps/guides/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow)."
 1. **{% data variables.product.pat_generic %}s**
     * You should never use a {% data variables.product.pat_v1 %}. These tokens grant access to all repositories within the organizations that you have access to, as well as all personal repositories in your personal account. This indirectly grants broad access to all write-access users of the repository the workflow is in.
-    * If you do use a {% data variables.product.pat_generic %}, you should never use a {% data variables.product.pat_generic %} from your own account. If you later leave an organization, workflows using this token will immediately break, and debugging this issue can be challenging. Instead, you should use a {% ifversion pat-v2%}{% data variables.product.pat_v2 %}s{% else %}{% data variables.product.pat_generic %}s{% endif %} for a new account that belongs to your organization and that is only granted access to the specific repositories that are needed for the workflow. Note that this approach is not scalable and should be avoided in favor of alternatives, such as deploy keys.
+    * If you do use a {% data variables.product.pat_generic %}, you should never use a {% data variables.product.pat_generic %} from your own account. If you later leave an organization, workflows using this token will immediately break, and debugging this issue can be challenging. Instead, you should use a {% data variables.product.pat_v2 %}for a new account that belongs to your organization and that is only granted access to the specific repositories that are needed for the workflow. Note that this approach is not scalable and should be avoided in favor of alternatives, such as deploy keys.
 1. **SSH keys on a personal account**
     * Workflows should never use the SSH keys on a personal account. Similar to {% data variables.product.pat_v1_plural %}, they grant read/write permissions to all of your personal repositories as well as all the repositories you have access to through organization membership.  This indirectly grants broad access to all write-access users of the repository the workflow is in. If you're intending to use an SSH key because you only need to perform repository clones or pushes, and do not need to interact with public APIs, then you should use individual deploy keys instead.
 
@@ -337,12 +337,8 @@ For third-party images, such as the images for ARM-powered runners, you can find
 
 {% ifversion fpt or ghec %}As a result, self-hosted runners should almost [never be used for public repositories](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#self-hosted-runner-security) on {% data variables.product.product_name %}, because any user can open pull requests against the repository and compromise the environment. Similarly, be{% elsif ghes %}Be{% endif %} cautious when using self-hosted runners on private or internal repositories, as anyone who can fork the repository and open a pull request (generally those with read access to the repository) are able to compromise the self-hosted runner environment, including gaining access to secrets and the `GITHUB_TOKEN` which, depending on its settings, can grant write access to the repository. Although workflows can control access to environment secrets by using environments and required reviews, these workflows are not run in an isolated environment and are still susceptible to the same risks when run on a self-hosted runner.
 
-{% ifversion actions-disable-repo-runners %}
-
 {% data reusables.actions.disable-selfhosted-runners-crossrefs %}
 
-{% endif %}
-
 When a self-hosted runner is defined at the organization or enterprise level, {% data variables.product.product_name %} can schedule workflows from multiple repositories onto the same runner. Consequently, a security compromise of these environments can result in a wide impact. To help reduce the scope of a compromise, you can create boundaries by organizing your self-hosted runners into separate groups. You can restrict what {% ifversion restrict-groups-to-workflows %}workflows, {% endif %}organizations and repositories can access runner groups. For more information, see "[AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/managing-access-to-self-hosted-runners-using-groups)."
 
 You should also consider the environment of the self-hosted runner machines: