diff --git a/content/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners.md b/content/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners.md index e5c3b667879c..c62301e6e147 100644 --- a/content/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners.md +++ b/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 diff --git a/content/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners.md b/content/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners.md index 9d93794ffb06..d90f15fb5bd2 100644 --- a/content/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners.md +++ b/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 %} diff --git a/content/actions/hosting-your-own-runners/managing-self-hosted-runners/monitoring-and-troubleshooting-self-hosted-runners.md b/content/actions/hosting-your-own-runners/managing-self-hosted-runners/monitoring-and-troubleshooting-self-hosted-runners.md index 6fdd8b601a95..9bcc24b35bd2 100644 --- a/content/actions/hosting-your-own-runners/managing-self-hosted-runners/monitoring-and-troubleshooting-self-hosted-runners.md +++ b/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 %} diff --git a/content/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/approving-workflow-runs-from-private-forks.md b/content/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/approving-workflow-runs-from-private-forks.md index 83b30cf0fa27..2a6cdf1e90fd 100644 --- a/content/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/approving-workflow-runs-from-private-forks.md +++ b/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 diff --git a/content/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-circleci-to-github-actions.md b/content/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-circleci-to-github-actions.md index db96290fd7fa..c06cb28bedcc 100644 --- a/content/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-circleci-to-github-actions.md +++ b/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 diff --git a/content/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-gitlab-cicd-to-github-actions.md b/content/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-gitlab-cicd-to-github-actions.md index 980ac75325ef..2623cc2f56f0 100644 --- a/content/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-gitlab-cicd-to-github-actions.md +++ b/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. diff --git a/content/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-travis-ci-to-github-actions.md b/content/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-travis-ci-to-github-actions.md index 81e493993c30..887755233f7d 100644 --- a/content/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-travis-ci-to-github-actions.md +++ b/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. diff --git a/content/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions.md b/content/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions.md index c74a4cc0eb76..a778e478b015 100644 --- a/content/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions.md +++ b/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: diff --git a/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-go.md b/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-go.md index 7a179c5ddba2..aac9837ef0e1 100644 --- a/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-go.md +++ b/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: diff --git a/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-java-with-gradle.md b/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-java-with-gradle.md index 82e67b9c8ae3..a021729d421d 100644 --- a/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-java-with-gradle.md +++ b/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)." diff --git a/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-java-with-maven.md b/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-java-with-maven.md index 5981622124dd..304a52e98438 100644 --- a/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-java-with-maven.md +++ b/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)." diff --git a/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-net.md b/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-net.md index edc95340a042..98fe86a22189 100644 --- a/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-net.md +++ b/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: diff --git a/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-nodejs.md b/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-nodejs.md index 44a394c64f7d..87cfba84cfa6 100644 --- a/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-nodejs.md +++ b/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. diff --git a/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-powershell.md b/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-powershell.md index f64ca95bb3b9..f3244b084dec 100644 --- a/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-powershell.md +++ b/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. diff --git a/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-python.md b/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-python.md index f93ff7c84845..b4034203eefc 100644 --- a/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-python.md +++ b/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. diff --git a/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-ruby.md b/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-ruby.md index bdbadf2bfe24..60792bf1282e 100644 --- a/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-ruby.md +++ b/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. diff --git a/content/actions/writing-workflows/about-workflows.md b/content/actions/writing-workflows/about-workflows.md index 28ae2fbf948a..189a303a76c3 100644 --- a/content/actions/writing-workflows/about-workflows.md +++ b/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 diff --git a/content/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows.md b/content/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows.md index ea455ca382d8..92485288a8de 100644 --- a/content/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows.md +++ b/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 diff --git a/content/actions/writing-workflows/choosing-what-your-workflow-does/storing-and-sharing-data-from-a-workflow.md b/content/actions/writing-workflows/choosing-what-your-workflow-does/storing-and-sharing-data-from-a-workflow.md index c01f60c4245c..72a910a365e0 100644 --- a/content/actions/writing-workflows/choosing-what-your-workflow-does/storing-and-sharing-data-from-a-workflow.md +++ b/content/actions/writing-workflows/choosing-what-your-workflow-does/storing-and-sharing-data-from-a-workflow.md @@ -56,14 +56,10 @@ To share data between jobs: The steps of a job share the same environment on the runner machine, but run in their own individual processes. To pass data between steps in a job, you can use inputs and outputs. For more information about inputs and outputs, see "[AUTOTITLE](/actions/creating-actions/metadata-syntax-for-github-actions)." -{% ifversion actions-caching %} - {% data reusables.actions.comparing-artifacts-caching %} For more information on dependency caching, see "[AUTOTITLE](/actions/using-workflows/caching-dependencies-to-speed-up-workflows#comparing-artifacts-and-dependency-caching)." -{% endif %} - ## Uploading build and test artifacts You can create a continuous integration (CI) workflow to build and test your code. For more information about using {% data variables.product.prodname_actions %} to perform CI, see "[AUTOTITLE](/actions/automating-builds-and-tests/about-continuous-integration)." diff --git a/content/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities.md b/content/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities.md index 36de59aba05d..7495fd7b4e74 100644 --- a/content/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities.md +++ b/content/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities.md @@ -325,7 +325,6 @@ This utility lists all of the services that have been started or stopped (are ru ```shell $ ghe-service-list -{% ifversion viewscreen-and-notebooks %} active - alambic - alive @@ -378,26 +377,6 @@ active inactive - wireguard -{% else %} -start/running - - github-resqued, process 12711 - - github-unicorn, process 12726 - - github-gitauth, process 12743 - - git-daemon, process 12755 - - babeld, process 12771 - - github-svn-proxy, process 12802 - - gist-unicorn, process 12832 - - gist-resqued, process 12881 - - render-unicorn, process 12939 - - hookshot-unicorn, process 13076 - - nodeload2, process 13192 - - slumlord-unicorn, process 13304 - - ghe-storage, process 2012 - - enterprise-manage-unicorn, process 2024 - - enterprise-manage-resque, process 2053 -stop/waiting - - ghe-replica-mode - {% endif %} ``` ### ghe-set-password diff --git a/content/admin/configuring-settings/configuring-user-applications-for-your-enterprise/configuring-applications.md b/content/admin/configuring-settings/configuring-user-applications-for-your-enterprise/configuring-applications.md index 5da6e89c2295..4108dfbd827a 100644 --- a/content/admin/configuring-settings/configuring-user-applications-for-your-enterprise/configuring-applications.md +++ b/content/admin/configuring-settings/configuring-user-applications-for-your-enterprise/configuring-applications.md @@ -24,8 +24,6 @@ You can choose the amount of time that {% data variables.location.product_locati 1. Under "Avatar image cache time (seconds)", type the number of seconds that you would like {% data variables.location.product_location %} to cache avatar images. {% data reusables.enterprise_management_console.save-settings %} -{% ifversion status-check-retention %} - ## Enabling retention policy for checks You can enable a retention policy for checks, actions, and associated data by setting thresholds for archival and deletion. For more information about configuring actions, see "[AUTOTITLE](/admin/github-actions/getting-started-with-github-actions-for-your-enterprise/about-github-actions-for-enterprises)." @@ -37,7 +35,6 @@ You can enable a retention policy for checks, actions, and associated data by se 1. Under "Archive threshold (days)", type the number of days for the archival threshold. Checks older than this number of days will be archived before being permanently deleted. 1. Under "Delete threshold (days)", type the number of days for the deletion threshold. An archived check exists in an archived state for the number of days specified here. After this threshold, the check will be permanently deleted. {% data reusables.enterprise_management_console.save-settings %} -{% endif %} {% ifversion azure-maps %} {% ifversion ghes < 3.13 %} diff --git a/content/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise.md b/content/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise.md index 9f905ed7720a..a751ae345315 100644 --- a/content/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise.md +++ b/content/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise.md @@ -77,8 +77,6 @@ When specifying actions{% ifversion actions-workflow-policy %} and reusable work * To allow all actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %} in organizations that start with `space-org`, use `space-org*/*`. * To allow all actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %} in repositories that start with octocat, use `*/octocat**@*`. -{% ifversion actions-disable-repo-runners %} - ## Runners By default, anyone with admin access to a repository can add a self-hosted runner for the repository, and self-hosted runners come with risks: @@ -95,8 +93,6 @@ In the "Runners" section, you can mediate these risks by disabling the use of re {% data reusables.actions.disable-selfhosted-runners-note %} -{% endif %} - ## {% ifversion ghes %}Artifact, log, and cache settings{% else %}Artifact and log retention{% endif %} {% ifversion ghes %} @@ -155,9 +151,7 @@ You can control how users can run workflows on `pull_request` events in private * **Run workflows from fork pull requests**. Users can run workflows from fork pull requests. By default, workflows will use a `GITHUB_TOKEN` with read-only permission, with no access to secrets. * **Send write tokens to workflows from pull requests**. Workflows will use a `GITHUB_TOKEN` with write permission. * **Send secrets to workflows from pull requests**. All secrets are available to the pull request. -{%- ifversion actions-private-fork-workflow-approvals %} * **Require approval for fork pull request workflows**. Workflows on pull requests from collaborators without write permission will require approval from someone with write permission before they will run. -{%- endif %} If a policy is enabled for an enterprise, the policy can be selectively disabled in individual organizations or repositories. If a policy is disabled for an enterprise, individual organizations or repositories cannot enable it. diff --git a/content/admin/managing-github-actions-for-your-enterprise/getting-started-with-github-actions-for-your-enterprise/getting-started-with-github-actions-for-github-enterprise-server.md b/content/admin/managing-github-actions-for-your-enterprise/getting-started-with-github-actions-for-your-enterprise/getting-started-with-github-actions-for-github-enterprise-server.md index 09aebe93ffcd..3aeff00439db 100644 --- a/content/admin/managing-github-actions-for-your-enterprise/getting-started-with-github-actions-for-your-enterprise/getting-started-with-github-actions-for-github-enterprise-server.md +++ b/content/admin/managing-github-actions-for-your-enterprise/getting-started-with-github-actions-for-your-enterprise/getting-started-with-github-actions-for-github-enterprise-server.md @@ -24,7 +24,7 @@ topics: This article explains how site administrators can configure {% data variables.product.prodname_ghe_server %} to use {% data variables.product.prodname_actions %}. -{% data reusables.actions.ghes-actions-not-enabled-by-default %} You'll need to determine whether your instance has adequate CPU and memory resources to handle the load from {% data variables.product.prodname_actions %} without causing performance loss, and possibly increase those resources. You'll also need to decide which storage provider you'll use for the blob storage required to store artifacts{% ifversion actions-caching %} and caches{% endif %} generated by workflow runs. Then, you'll enable {% data variables.product.prodname_actions %} for your enterprise, manage access permissions, and add self-hosted runners to run workflows. +{% data reusables.actions.ghes-actions-not-enabled-by-default %} You'll need to determine whether your instance has adequate CPU and memory resources to handle the load from {% data variables.product.prodname_actions %} without causing performance loss, and possibly increase those resources. You'll also need to decide which storage provider you'll use for the blob storage required to store artifacts and caches generated by workflow runs. Then, you'll enable {% data variables.product.prodname_actions %} for your enterprise, manage access permissions, and add self-hosted runners to run workflows. {% data reusables.actions.introducing-enterprise %} diff --git a/content/admin/managing-github-actions-for-your-enterprise/getting-started-with-github-actions-for-your-enterprise/getting-started-with-self-hosted-runners-for-your-enterprise.md b/content/admin/managing-github-actions-for-your-enterprise/getting-started-with-github-actions-for-your-enterprise/getting-started-with-self-hosted-runners-for-your-enterprise.md index 3841c861ef9c..a71a94fae9a8 100644 --- a/content/admin/managing-github-actions-for-your-enterprise/getting-started-with-github-actions-for-your-enterprise/getting-started-with-self-hosted-runners-for-your-enterprise.md +++ b/content/admin/managing-github-actions-for-your-enterprise/getting-started-with-github-actions-for-your-enterprise/getting-started-with-self-hosted-runners-for-your-enterprise.md @@ -33,7 +33,7 @@ This guide shows you how to apply a centralized management approach to self-host 1. Deploy a self-hosted runner for your enterprise 1. Create a group to manage access to the runners available to your enterprise 1. Optionally, further restrict the repositories that can use the runner -1. Optionally, {% ifversion actions-runner-controller %}to build and scale self-hosted runners automatically, use {% data variables.product.prodname_actions_runner_controller %} (ARC). For more information, see "[AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/about-actions-runner-controller)."{% else %}build custom tooling to automatically scale your self-hosted runners{% endif %} +1. Optionally, to build and scale self-hosted runners automatically, use {% data variables.product.prodname_actions_runner_controller %} (ARC). For more information, see "[AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/about-actions-runner-controller)." You'll also find additional information about how to monitor and secure your self-hosted runners,{% ifversion ghes %} how to access actions from {% data variables.product.prodname_dotcom_the_website %},{% endif %} and how to customize the software on your runner machines. @@ -111,10 +111,7 @@ For more information, see "[AUTOTITLE](/actions/hosting-your-own-runners/managin ## 5. Automatically scale your self-hosted runners -{% ifversion actions-runner-controller %}Optionally, you can use {% data variables.product.prodname_actions_runner_controller %} (ARC) to automatically scale self-hosted runners. {% data reusables.actions.actions-runner-controller-about-arc %} - -{% else %}Optionally, you can build custom tooling to automatically scale the self-hosted runners for {% ifversion ghec %}your enterprise{% elsif ghes %}{% data variables.location.product_location %}{% endif %}. For example, your tooling can respond to webhook events from {% data variables.location.product_location %} to automatically scale a cluster of runner machines. For more information, see "[AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/autoscaling-with-self-hosted-runners)." -{% endif %} +Optionally, you can use {% data variables.product.prodname_actions_runner_controller %} (ARC) to automatically scale self-hosted runners. {% data reusables.actions.actions-runner-controller-about-arc %} ## Next steps diff --git a/content/admin/managing-github-actions-for-your-enterprise/getting-started-with-github-actions-for-your-enterprise/introducing-github-actions-to-your-enterprise.md b/content/admin/managing-github-actions-for-your-enterprise/getting-started-with-github-actions-for-your-enterprise/introducing-github-actions-to-your-enterprise.md index 645e4515fa3d..ce53d1dc3f25 100644 --- a/content/admin/managing-github-actions-for-your-enterprise/getting-started-with-github-actions-for-your-enterprise/introducing-github-actions-to-your-enterprise.md +++ b/content/admin/managing-github-actions-for-your-enterprise/getting-started-with-github-actions-for-your-enterprise/introducing-github-actions-to-your-enterprise.md @@ -102,7 +102,7 @@ If you want more control over the networking policies for your runners, use self {% ifversion ghec %}If you are using self-hosted runners, you have to decide whether you want to use physical machines, virtual machines, or containers.{% else %}Decide whether you want to use physical machines, virtual machines, or containers for your self-hosted runners.{% endif %} Physical machines will retain remnants of previous jobs, and so will virtual machines unless you use a fresh image for each job or clean up the machines after each job run. If you choose containers, you should be aware that the runner auto-updating will shut down the container, which can cause workflows to fail. You should come up with a solution for this by preventing auto-updates or skipping the command to kill the container. -You also have to decide where to add each runner. You can add a self-hosted runner to an individual repository, or you can make the runner available to an entire organization or your entire enterprise. Adding runners at the organization or enterprise levels allows sharing of runners, which might reduce the size of your runner infrastructure. You can use policies to limit access to self-hosted runners at the organization and enterprise levels by assigning groups of runners to specific repositories or organizations. For more information, see "[AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners)" and "[AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/managing-access-to-self-hosted-runners-using-groups)." {% ifversion actions-disable-repo-runners %}You can also use policies to prevent people using repository-level self-hosted runners. For more information, see "[AUTOTITLE](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#disabling-repository-level-self-hosted-runners)."{% endif %} +You also have to decide where to add each runner. You can add a self-hosted runner to an individual repository, or you can make the runner available to an entire organization or your entire enterprise. Adding runners at the organization or enterprise levels allows sharing of runners, which might reduce the size of your runner infrastructure. You can use policies to limit access to self-hosted runners at the organization and enterprise levels by assigning groups of runners to specific repositories or organizations. For more information, see "[AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners)" and "[AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/managing-access-to-self-hosted-runners-using-groups)." You can also use policies to prevent people using repository-level self-hosted runners. For more information, see "[AUTOTITLE](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#disabling-repository-level-self-hosted-runners)." {% ifversion ghec or ghes %} You should consider using autoscaling to automatically increase or decrease the number of available self-hosted runners. For more information, see "[AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/autoscaling-with-self-hosted-runners)." diff --git a/content/contributing/writing-for-github-docs/creating-diagrams-for-github-docs.md b/content/contributing/writing-for-github-docs/creating-diagrams-for-github-docs.md index 8e193d7d9dd2..dfcef7accf94 100644 --- a/content/contributing/writing-for-github-docs/creating-diagrams-for-github-docs.md +++ b/content/contributing/writing-for-github-docs/creating-diagrams-for-github-docs.md @@ -114,7 +114,7 @@ If you are creating a diagram to explain what or where things are, consider one If you are creating a diagram to explain why something is the way that it is, consider one of these diagram types. * [Continuum diagram](https://en.wikipedia.org/wiki/Continuum_(measurement)): Continuum diagrams are useful for showing where things fall on a linear spectrum. In this example, the blue rectangle shows that the item of interest is closer to Option 2 than Option 1 on the continuum. - + ![An example continuum with a horizontal axis representing the continuum between two options and the position of an item on the continuum.](/assets/images/help/diagrams/continuum-example.png) * [Quadrant diagram](https://en.wikipedia.org/wiki/Quadrant_(plane_geometry)): Quadrant diagrams are useful for explaining the relationship between two axes and where things fall on both axes. In this example, the horizontal axis is labelled "Purely decorative" on the left and "Meets a specific acceptance criteria" on the right. The vertical axis is labelled "Compliment written text" on the top and "The only way information is presented" on the bottom. The blue square labelled "Diagrams in the {% data variables.product.prodname_docs %}" is in the upper right quadrant formed by the overlap of "Compliment written text" and "Meets a specific acceptance criteria," which means that it has those two properties. @@ -199,7 +199,7 @@ The preferred colors for diagrams in {% data variables.product.prodname_docs %} * File size of 250 KB or less * Descriptive file names, such as `merge-conflict-diagram.png` instead of `diagram-02.png` -If you need to create a diagram that is difficult to view at small resolutions, include a link to a larger version of the diagram in a relevant repository or other appropriate location.{% ifversion actions-runner-controller %} See "[AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/about-actions-runner-controller)" for an example.{% endif %} +If you need to create a diagram that is difficult to view at small resolutions, include a link to a larger version of the diagram in a relevant repository or other appropriate location. See "[AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/about-actions-runner-controller)" for an example. ## Tools for creating diagrams diff --git a/content/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization.md b/content/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization.md index 78e488a0015c..896ae5b6cf53 100644 --- a/content/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization.md +++ b/content/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization.md @@ -50,8 +50,6 @@ You can choose to disable {% data variables.product.prodname_actions %} for all 1. Under "Policies", select {% data reusables.actions.policy-label-for-select-actions-workflows %} and add your required actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %} to the list. 1. Click **Save**. -{% ifversion actions-disable-repo-runners %} - ## Limiting the use of self-hosted runners {% data reusables.actions.disable-selfhosted-runners-overview %} @@ -84,8 +82,6 @@ If a repository already has self-hosted runners when you disable their use, thes 1. Select the check boxes for the repositories for which you want to allow self-hosted runners. 1. Click **Select repositories**. -{% endif %} - {% ifversion fpt or ghec %} ## Configuring required approval for workflows from public forks diff --git a/content/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks.md b/content/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks.md index 075c201d2cad..0687fb1fcdd5 100644 --- a/content/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks.md +++ b/content/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks.md @@ -87,10 +87,6 @@ Alternatively, to skip or request _all_ checks for your commit, add one of the f {% data reusables.commits.about-commit-cleanup %} -{% ifversion status-check-retention %} - ### Retention of checks {% data reusables.pull_requests.retention-checks-data %} - -{% endif %} diff --git a/data/reusables/actions/caching-availability.md b/data/reusables/actions/caching-availability.md index f774728a440a..01505ee350e9 100644 --- a/data/reusables/actions/caching-availability.md +++ b/data/reusables/actions/caching-availability.md @@ -1,5 +1,5 @@ {% ifversion ghes %} -{% data variables.product.prodname_actions %} caching is only available for repositories hosted on {% data variables.product.prodname_ghe_server %} 3.5 and later. For more information, see "[Caching dependencies to speed up workflows]({% ifversion actions-caching %}{% else %}/free-pro-team@latest{% endif %}/actions/guides/caching-dependencies-to-speed-up-workflows)." +{% data variables.product.prodname_actions %} caching is only available for repositories hosted on {% data variables.product.prodname_ghe_server %} 3.5 and later. For more information, see "[Caching dependencies to speed up workflows](/actions/guides/caching-dependencies-to-speed-up-workflows)." {% endif %} diff --git a/data/reusables/actions/enterprise-storage-contents.md b/data/reusables/actions/enterprise-storage-contents.md index 430ca2344d1c..0a245198a399 100644 --- a/data/reusables/actions/enterprise-storage-contents.md +++ b/data/reusables/actions/enterprise-storage-contents.md @@ -1 +1 @@ -{% data variables.product.prodname_actions %} uses external blob storage to store data generated by workflow runs. Stored data includes workflow logs{% ifversion actions-caching %}, caches,{% endif %} and user-uploaded build artifacts. +{% data variables.product.prodname_actions %} uses external blob storage to store data generated by workflow runs. Stored data includes workflow logs, caches, and user-uploaded build artifacts. diff --git a/data/reusables/actions/private-repository-forks-options.md b/data/reusables/actions/private-repository-forks-options.md index bb458ff401a2..cabf2b1a086d 100644 --- a/data/reusables/actions/private-repository-forks-options.md +++ b/data/reusables/actions/private-repository-forks-options.md @@ -1,4 +1,4 @@ * **Run workflows from fork pull requests** - Allows users to run workflows from fork pull requests, using a `GITHUB_TOKEN` with read-only permission, and with no access to secrets. * **Send write tokens to workflows from pull requests** - Allows pull requests from forks to use a `GITHUB_TOKEN` with write permission. -* **Send secrets to workflows from pull requests** - Makes all secrets available to the pull request.{% ifversion actions-private-fork-workflow-approvals %} -* **Require approval for fork pull request workflows** - Workflow runs on pull requests from collaborators without write permission will require approval from someone with write permission before they will run.{% endif %} +* **Send secrets to workflows from pull requests** - Makes all secrets available to the pull request. +* **Require approval for fork pull request workflows** - Workflow runs on pull requests from collaborators without write permission will require approval from someone with write permission before they will run. diff --git a/data/ui.yml b/data/ui.yml index e41931591939..d52e803c6667 100644 --- a/data/ui.yml +++ b/data/ui.yml @@ -262,7 +262,6 @@ scroll_button: scroll_to_top: Scroll to top popovers: role_description: hovercard link - keyboard_shortcut_description: Press alt+up to activate alerts: NOTE: Note IMPORTANT: Important diff --git a/src/fixtures/fixtures/data/ui.yml b/src/fixtures/fixtures/data/ui.yml index e41931591939..d52e803c6667 100644 --- a/src/fixtures/fixtures/data/ui.yml +++ b/src/fixtures/fixtures/data/ui.yml @@ -262,7 +262,6 @@ scroll_button: scroll_to_top: Scroll to top popovers: role_description: hovercard link - keyboard_shortcut_description: Press alt+up to activate alerts: NOTE: Note IMPORTANT: Important diff --git a/src/fixtures/tests/playwright-rendering.spec.ts b/src/fixtures/tests/playwright-rendering.spec.ts index 491fe55c57a0..5674c55fe31f 100644 --- a/src/fixtures/tests/playwright-rendering.spec.ts +++ b/src/fixtures/tests/playwright-rendering.spec.ts @@ -286,16 +286,27 @@ test.describe('hover cards', () => { ).not.toBeVisible() }) - test('internal links get a aria-roledescription and aria-describedby', async ({ page }) => { + test('able to use Esc to close hovercard', async ({ page }) => { await page.goto('/pages/quickstart') - const link = page.locator('#article-contents').getByRole('link', { name: 'Start your journey' }) - await expect(link).toHaveAttribute('aria-roledescription', 'hovercard link') - - // The link gets a `aria-describedby="...ID..."` attribute that points to - // another element in the DOM that has the description text. - const id = 'popover-describedby' - await expect(link).toHaveAttribute('aria-describedby', id) - await expect(page.locator(`#${id}`)).toHaveText('Press alt+up to activate') + + // hover over a link and check for intro content from hovercard + await page + .locator('#article-contents') + .getByRole('link', { name: 'Start your journey' }) + .hover() + await expect( + page.getByText( + 'Get started using HubGit to manage Git repositories and collaborate with others.', + ), + ).toBeVisible() + + // click the Esc key to close the hovercard + await page.keyboard.press('Escape') + await expect( + page.getByText( + 'Get started using GitHub to manage Git repositories and collaborate with others.', + ), + ).not.toBeVisible() }) }) diff --git a/src/links/components/LinkPreviewPopover.tsx b/src/links/components/LinkPreviewPopover.tsx index d0290608bd4a..00c0d628f496 100644 --- a/src/links/components/LinkPreviewPopover.tsx +++ b/src/links/components/LinkPreviewPopover.tsx @@ -1,6 +1,4 @@ import { useEffect } from 'react' -import { useTranslation } from 'src/languages/components/useTranslation' -import { useRouter } from 'next/router' // We postpone the initial delay a bit in case the user didn't mean to // hover over the link. Perhaps they just dragged the mouse over on their @@ -36,14 +34,6 @@ let currentlyOpen: HTMLLinkElement | null = null // change according to the popover's true height. But this can cause a flicker. const BOUNDING_TOP_MARGIN = 300 -// All links that should have a hover card also get a -// `aria-describedby="..."`. That ID is used to look up another DOM -// element, that has a `visually-hidden` class. The value if the ID -// isn't very important as long as it connects. -// Note; at the moment this value is duplicated in the Playwright -// tests because of trying to extract the value of `aria-describedby`. -const DESCRIBEDBY_ELEMENT_ID = 'popover-describedby' - // used to identify the first focusable element in the hover card const FIRST_LINK_ID = '_hc_first_focusable' const TITLE_ID = '_hc_title' @@ -70,7 +60,7 @@ function getOrCreatePopoverGlobal() { // Semantics for the hovercard so SR users are aware they're about to be // focus trapped - wrapper.setAttribute('role', 'dialog') + wrapper.setAttribute('role', 'region') wrapper.setAttribute('aria-modal', 'true') wrapper.setAttribute('aria-label', 'user hovercard') wrapper.setAttribute('aria-labelledby', TITLE_ID) @@ -202,28 +192,6 @@ function getOrCreatePopoverGlobal() { return popoverGlobal } -function getOrCreateDescribeByElement() { - let element = document.querySelector(`#${DESCRIBEDBY_ELEMENT_ID}`) - if (!element) { - element = document.createElement('p') - element.id = DESCRIBEDBY_ELEMENT_ID - element.classList.add('visually-hidden') - // "All page content should be contained by landmarks" - // https://dequeuniversity.com/rules/axe/4.7/region - // The element that we use for the `aria-describedby` attribute - // needs to exist in the DOM inside a landmark. For example - // `
`. In our case we use our - // `
` element. - // We "know" that this querySelector() query will always find a - // valid element, but it's theoretically not perfectly true, so we have to - // use a fallback. - const main = document.querySelector('main') || document.body - main.appendChild(element) - } - - return element -} - function popoverWrap(element: HTMLLinkElement, filledCallback?: (popover: HTMLDivElement) => void) { if (element.parentElement && element.parentElement.classList.contains('Popover')) { return @@ -474,16 +442,6 @@ function popoverHide() { let lastFocussedLink: HTMLLinkElement | null = null export function LinkPreviewPopover() { - const { t } = useTranslation('popovers') - const { locale } = useRouter() - - useEffect(() => { - const element = getOrCreateDescribeByElement() - if (element) { - element.textContent = t('keyboard_shortcut_description') - } - }, [locale]) - // This is to track if the user entirely tabs out of the window. // For example if they go to the address bar. useEffect(() => { @@ -587,13 +545,6 @@ export function LinkPreviewPopover() { link.addEventListener('mouseover', showPopover) link.addEventListener('mouseout', hidePopover) link.addEventListener('keydown', keyboardHandler) - - if (!link.getAttribute('aria-roledescription')) { - link.setAttribute('aria-roledescription', t('role_description')) - } - if (!link.getAttribute('aria-describedby')) { - link.setAttribute('aria-describedby', DESCRIBEDBY_ELEMENT_ID) - } } document.addEventListener('keydown', escapeHandler)