Merge pull request github#34745 from github/repo-sync

Repo sync

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

@@ -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/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 %}

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/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/security-for-github-actions/security-guides/security-hardening-for-github-actions.md

@@ -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:

content/actions/use-cases-and-examples/building-and-testing/building-and-testing-go.md

@@ -146,8 +146,6 @@ You can use `go get` to install dependencies:
           go get example.com/octo-examplemodule@v1.3.4
 ```
 
-{% ifversion actions-caching %}
-
 ### Caching dependencies
 
 You can cache and restore dependencies using the [`setup-go` action](https://github.com/actions/setup-go). By default, caching is {% ifversion actions-setup-go-default-cache-enabled %}enabled when using the `setup-go` action.{% else %}disabled, but you can set the `cache` parameter to `true` to enable it.{% endif %}
@@ -191,8 +189,6 @@ Alternatively, you can use the `cache-dependency-path` parameter for cases when
 
 If you have a custom requirement or need finer controls for caching, you can use the [`cache` action](https://github.com/marketplace/actions/cache). For more information, see "[AUTOTITLE](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)."
 
-{% endif %}
-
 ## Building and testing your code
 
 You can use the same commands that you use locally to build and test your code. This example workflow demonstrates how to use `go build` and `go test` in a job:

content/actions/use-cases-and-examples/building-and-testing/building-and-testing-java-with-gradle.md

@@ -21,7 +21,7 @@ shortTitle: Build & test Java & Gradle
 
 ## Introduction
 
-This guide shows you how to create a workflow that performs continuous integration (CI) for your Java project using the Gradle build system. The workflow you create will allow you to see when commits to a pull request cause build or test failures against your default branch; this approach can help ensure that your code is always healthy. You can extend your CI workflow to {% ifversion actions-caching %}cache files and{% endif %} upload artifacts from a workflow run.
+This guide shows you how to create a workflow that performs continuous integration (CI) for your Java project using the Gradle build system. The workflow you create will allow you to see when commits to a pull request cause build or test failures against your default branch; this approach can help ensure that your code is always healthy. You can extend your CI workflow to cache files and upload artifacts from a workflow run.
 
 {% data variables.product.prodname_dotcom %}-hosted runners have a tools cache with pre-installed software, which includes Java Development Kits (JDKs) and Gradle. For a list of software and the pre-installed versions for JDK and Gradle, see "[AUTOTITLE](/actions/using-github-hosted-runners/about-github-hosted-runners#supported-software)".
 
@@ -120,16 +120,12 @@ steps:
     run: ./gradlew -b ci.gradle package
 ```
 
-{% ifversion actions-caching %}
-
 ## Caching dependencies
 
 Your build dependencies can be cached to speed up your workflow runs. After a successful run, `gradle/actions/setup-gradle` caches important parts of the Gradle user home directory. In future jobs, the cache will be restored so that build scripts won't need to be recompiled and dependencies won't need to be downloaded from remote package repositories.
 
 Caching is enabled by default when using the `gradle/actions/setup-gradle` action. For more information, see [`gradle/actions/setup-gradle`](https://github.com/gradle/actions/blob/main/setup-gradle/README.md#caching-build-state-between-jobs).
 
-{% endif %}
-
 ## Packaging workflow data as artifacts
 
 After your build has succeeded and your tests have passed, you may want to upload the resulting Java packages as a build artifact. This will store the built packages as part of the workflow run, and allow you to download them. Artifacts can help you test and debug pull requests in your local environment before they're merged. For more information, see "[AUTOTITLE](/actions/using-workflows/storing-workflow-data-as-artifacts)."

content/actions/use-cases-and-examples/building-and-testing/building-and-testing-java-with-maven.md

@@ -21,7 +21,7 @@ shortTitle: Build & test Java with Maven
 
 ## Introduction
 
-This guide shows you how to create a workflow that performs continuous integration (CI) for your Java project using the Maven software project management tool. The workflow you create will allow you to see when commits to a pull request cause build or test failures against your default branch; this approach can help ensure that your code is always healthy. You can extend your CI workflow to {% ifversion actions-caching %}cache files and{% endif %} upload artifacts from a workflow run.
+This guide shows you how to create a workflow that performs continuous integration (CI) for your Java project using the Maven software project management tool. The workflow you create will allow you to see when commits to a pull request cause build or test failures against your default branch; this approach can help ensure that your code is always healthy. You can extend your CI workflow to cache files and upload artifacts from a workflow run.
 
 {% data variables.product.prodname_dotcom %}-hosted runners have a tools cache with pre-installed software, which includes Java Development Kits (JDKs) and Maven. For a list of software and the pre-installed versions for JDK and Maven, see "[AUTOTITLE](/actions/using-github-hosted-runners/about-github-hosted-runners#supported-software)".
 
@@ -110,8 +110,6 @@ steps:
     run: mvn --batch-mode --update-snapshots verify
 ```
 
-{% ifversion actions-caching %}
-
 ## Caching dependencies
 
 You can cache your dependencies to speed up your workflow runs. After a successful run, your local Maven repository will be stored in a cache. In future workflow runs, the cache will be restored so that dependencies don't need to be downloaded from remote Maven repositories. You can cache dependencies simply using the [`setup-java` action](https://github.com/marketplace/actions/setup-java-jdk) or can use [`cache` action](https://github.com/actions/cache) for custom and more advanced configuration.
@@ -131,8 +129,6 @@ steps:
 
 This workflow will save the contents of your local Maven repository, located in the `.m2` directory of the runner's home directory. The cache key will be the hashed contents of _pom.xml_, so changes to _pom.xml_ will invalidate the cache.
 
-{% endif %}
-
 ## Packaging workflow data as artifacts
 
 After your build has succeeded and your tests have passed, you may want to upload the resulting Java packages as a build artifact. This will store the built packages as part of the workflow run, and allow you to download them. Artifacts can help you test and debug pull requests in your local environment before they're merged. For more information, see "[AUTOTITLE](/actions/using-workflows/storing-workflow-data-as-artifacts)."

content/actions/use-cases-and-examples/building-and-testing/building-and-testing-net.md

@@ -136,8 +136,6 @@ steps:
   run: dotnet add package Newtonsoft.Json --version 12.0.1
 ```
 
-{% ifversion actions-caching %}
-
 ### Caching dependencies
 
 You can cache NuGet dependencies for future workflows using the optional `cache` input. For example, the YAML below caches the NuGet `global-packages` folder, and then installs the `Newtonsoft` package. A second optional input, `cache-dependency-path`, can be used to specify the path to a dependency file: `packages.lock.json`.
@@ -162,8 +160,6 @@ steps:
 
 {% endnote %}
 
-{% endif %}
-
 ## Building and testing your code
 
 You can use the same commands that you use locally to build and test your code. This example demonstrates how to use `dotnet build` and `dotnet test` in a job:

content/actions/use-cases-and-examples/building-and-testing/building-and-testing-nodejs.md

@@ -150,7 +150,7 @@ For more information, see "[AUTOTITLE](/actions/using-github-hosted-runners/abou
 
 {% data variables.product.prodname_dotcom %}-hosted runners have npm and Yarn dependency managers installed. You can use npm and Yarn to install dependencies in your workflow before building and testing your code. The Windows and Linux {% data variables.product.prodname_dotcom %}-hosted runners also have Grunt, Gulp, and Bower installed.
 
-{% ifversion actions-caching %}You can also cache dependencies to speed up your workflow. For more information, see "[AUTOTITLE](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)."{% endif %}
+You can also cache dependencies to speed up your workflow. For more information, see "[AUTOTITLE](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)."
 
 ### Example using npm
 
@@ -242,8 +242,6 @@ The example above creates an _.npmrc_ file with the following contents:
 always-auth=true
 ```
 
-{% ifversion actions-caching %}
-
 ### Example caching dependencies
 
 You can cache and restore the dependencies using the [`setup-node` action](https://github.com/actions/setup-node).
@@ -296,8 +294,6 @@ steps:
 
 If you have a custom requirement or need finer controls for caching, you can use the [`cache` action](https://github.com/marketplace/actions/cache). For more information, see "[AUTOTITLE](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)."
 
-{% endif %}
-
 ## Building and testing your code
 
 You can use the same commands that you use locally to build and test your code. For example, if you run `npm run build` to run build steps defined in your _package.json_ file and `npm test` to run your test suite, you would add those commands in your workflow file.

content/actions/use-cases-and-examples/building-and-testing/building-and-testing-powershell.md

@@ -16,7 +16,7 @@ topics:
   - PowerShell
 shortTitle: Build & test PowerShell
 ---
- 
+
 {% data reusables.actions.enterprise-github-hosted-runners %}
 
 ## Introduction
@@ -109,7 +109,7 @@ The table below describes the locations for various PowerShell modules in each {
 
 {% endnote %}
 
-{% ifversion actions-caching %}You can also cache dependencies to speed up your workflow. For more information, see "[AUTOTITLE](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)."{% endif %}
+You can also cache dependencies to speed up your workflow. For more information, see "[AUTOTITLE](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)."
 
 For example, the following job installs the `SqlServer` and `PSScriptAnalyzer` modules:
 
@@ -133,8 +133,6 @@ jobs:
 
 {% endnote %}
 
-{% ifversion actions-caching %}
-
 ### Caching dependencies
 
 You can cache PowerShell dependencies using a unique key, which allows you to restore the dependencies for future workflows with the [`cache`](https://github.com/marketplace/actions/cache) action. For more information, see "[AUTOTITLE](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)."
@@ -158,8 +156,6 @@ steps:
       Install-Module SqlServer, PSScriptAnalyzer -ErrorAction Stop
 ```
 
-{% endif %}
-
 ## Testing your code
 
 You can use the same commands that you use locally to build and test your code.

content/actions/use-cases-and-examples/building-and-testing/building-and-testing-python.md

@@ -218,7 +218,7 @@ We recommend using `setup-python` to configure the version of Python used in you
 
 {% data variables.product.prodname_dotcom %}-hosted runners have the pip package manager installed. You can use pip to install dependencies from the PyPI package registry before building and testing your code. For example, the YAML below installs or upgrades the `pip` package installer and the `setuptools` and `wheel` packages.
 
-{% ifversion actions-caching %}You can also cache dependencies to speed up your workflow. For more information, see "[AUTOTITLE](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)."{% endif %}
+You can also cache dependencies to speed up your workflow. For more information, see "[AUTOTITLE](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)."
 
 ```yaml copy
 steps:
@@ -248,8 +248,6 @@ steps:
     pip install -r requirements.txt
 ```
 
-{% ifversion actions-caching %}
-
 ### Caching Dependencies
 
 You can cache and restore the dependencies using the [`setup-python` action](https://github.com/actions/setup-python).
@@ -271,8 +269,6 @@ By default, the `setup-python` action searches for the dependency file (`require
 
 If you have a custom requirement or need finer controls for caching, you can use the [`cache` action](https://github.com/marketplace/actions/cache). Pip caches dependencies in different locations, depending on the operating system of the runner. The path you'll need to cache may differ from the Ubuntu example above, depending on the operating system you use. For more information, see [Python caching examples](https://github.com/actions/cache/blob/main/examples.md#python---pip) in the `cache` action repository.
 
-{% endif %}
-
 ## Testing your code
 
 You can use the same commands that you use locally to build and test your code.

content/actions/use-cases-and-examples/building-and-testing/building-and-testing-ruby.md

@@ -175,8 +175,6 @@ steps:
 - run: bundle install
 ```
 
-{% ifversion actions-caching %}
-
 ### Caching dependencies
 
 The `setup-ruby` actions provides a method to automatically handle the caching of your gems between runs.
@@ -230,8 +228,6 @@ steps:
     bundle install --jobs 4 --retry 3
 ```
 
-{% endif %}
-
 ## Matrix testing your code
 
 The following example matrix tests all stable releases and head versions of MRI, JRuby and TruffleRuby on Ubuntu and macOS.

content/actions/writing-workflows/about-workflows.md

@@ -123,8 +123,6 @@ jobs:
 
 For more information, see "[AUTOTITLE](/actions/using-jobs/using-a-matrix-for-your-jobs)."
 
-{% ifversion actions-caching %}
-
 ### Caching dependencies
 
 If your jobs regularly reuse dependencies, you can consider caching these files to help improve performance. Once the cache is created, it is available to all workflows in the same repository.
@@ -147,7 +145,6 @@ jobs:
 ```
 
 For more information, see "[AUTOTITLE](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)."
-{% endif %}
 
 ### Using databases and service containers
 

content/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows.md

@@ -10,7 +10,9 @@ redirect_from:
   - /actions/advanced-guides/caching-dependencies-to-speed-up-workflows
   - /actions/using-workflows/caching-dependencies-to-speed-up-workflows
 versions:
-  feature: actions-caching
+  fpt: '*'
+  ghec: '*'
+  ghes: '*'
 type: tutorial
 topics:
   - Workflows