Merge pull request #34745 from github/repo-sync

Repo sync

Author: docs-bot

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/[email protected]
 ```
 
-{% 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)."