diff --git a/content/actions/guides/about-service-containers.md b/content/actions/guides/about-service-containers.md
index a91914c527..ceaed1b507 100644
--- a/content/actions/guides/about-service-containers.md
+++ b/content/actions/guides/about-service-containers.md
@@ -47,7 +47,7 @@ You can use the `services` keyword to create service containers that are part of
This example creates a service called `redis` in a job called `container-job`. The Docker host in this example is the `node:10.18-jessie` container.
{% raw %}
-```yaml
+```yaml{:copy}
name: Redis container example
on: push
@@ -89,7 +89,7 @@ When you specify the Docker host port but not the container port, the container
This example maps the service container `redis` port 6379 to the Docker host port 6379.
{% raw %}
-```yaml
+```yaml{:copy}
name: Redis Service Example
on: push
diff --git a/content/actions/guides/building-and-testing-java-with-ant.md b/content/actions/guides/building-and-testing-java-with-ant.md
index 96019ea729..3f062ffb28 100644
--- a/content/actions/guides/building-and-testing-java-with-ant.md
+++ b/content/actions/guides/building-and-testing-java-with-ant.md
@@ -38,7 +38,7 @@ To get started quickly, you can choose the preconfigured Ant template when you c
You can also add this workflow manually by creating a new file in the `.github/workflows` directory of your repository.
{% raw %}
-```yaml
+```yaml{:copy}
name: Java CI
on: [push]
@@ -79,7 +79,7 @@ The starter workflow will run the default target specified in your _build.xml_ f
If you use different commands to build your project, or you want to run a different target, you can specify those. For example, you may want to run the `jar` target that's configured in your _build-ci.xml_ file.
{% raw %}
-```yaml
+```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v1
@@ -97,7 +97,7 @@ After your build has succeeded and your tests have passed, you may want to uploa
Ant will usually create output files like JARs, EARs, or WARs in the `build/jar` directory. You can upload the contents of that directory using the `upload-artifact` action.
{% raw %}
-```yaml
+```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v1
diff --git a/content/actions/guides/building-and-testing-java-with-gradle.md b/content/actions/guides/building-and-testing-java-with-gradle.md
index 67e760c925..e3347e6cd1 100644
--- a/content/actions/guides/building-and-testing-java-with-gradle.md
+++ b/content/actions/guides/building-and-testing-java-with-gradle.md
@@ -38,7 +38,7 @@ To get started quickly, you can choose the preconfigured Gradle template when yo
You can also add this workflow manually by creating a new file in the `.github/workflows` directory of your repository.
{% raw %}
-```yaml
+```yaml{:copy}
name: Java CI
on: [push]
@@ -79,7 +79,7 @@ The starter workflow will run the `build` task by default. In the default Gradle
If you use different commands to build your project, or you want to use a different task, you can specify those. For example, you may want to run the `package` task that's configured in your _ci.gradle_ file.
{% raw %}
-```yaml
+```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v1
@@ -95,7 +95,7 @@ steps:
When using {% data variables.product.prodname_dotcom %}-hosted runners, you can cache your dependencies to speed up your workflow runs. After a successful run, your local Gradle package cache will be stored on GitHub Actions infrastructure. In future workflow runs, the cache will be restored so that dependencies don't need to be downloaded from remote package repositories. For more information, see "Caching dependencies to speed up workflows" and the [`cache` action](https://github.com/marketplace/actions/cache).
{% raw %}
-```yaml
+```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Set up JDK 1.8
@@ -122,7 +122,7 @@ After your build has succeeded and your tests have passed, you may want to uploa
Gradle will usually create output files like JARs, EARs, or WARs in the `build/libs` directory. You can upload the contents of that directory using the `upload-artifact` action.
{% raw %}
-```yaml
+```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v1
diff --git a/content/actions/guides/building-and-testing-java-with-maven.md b/content/actions/guides/building-and-testing-java-with-maven.md
index fbc8f90151..205a4116de 100644
--- a/content/actions/guides/building-and-testing-java-with-maven.md
+++ b/content/actions/guides/building-and-testing-java-with-maven.md
@@ -38,7 +38,7 @@ To get started quickly, you can choose the preconfigured Maven template when you
You can also add this workflow manually by creating a new file in the `.github/workflows` directory of your repository.
{% raw %}
-```yaml
+```yaml{:copy}
name: Java CI
on: [push]
@@ -79,7 +79,7 @@ The starter workflow will run the `package` target by default. In the default Ma
If you use different commands to build your project, or you want to use a different target, you can specify those. For example, you may want to run the `verify` target that's configured in a _pom-ci.xml_ file.
{% raw %}
-```yaml
+```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v1
@@ -95,7 +95,7 @@ steps:
When using {% data variables.product.prodname_dotcom %}-hosted runners, you can cache your dependencies to speed up your workflow runs. After a successful run, your local Maven repository will be stored on GitHub Actions infrastructure. In future workflow runs, the cache will be restored so that dependencies don't need to be downloaded from remote Maven repositories. For more information, see "Caching dependencies to speed up workflows" and the [`cache` action](https://github.com/marketplace/actions/cache).
{% raw %}
-```yaml
+```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Set up JDK 1.8
@@ -122,7 +122,7 @@ After your build has succeeded and your tests have passed, you may want to uploa
Maven will usually create output files like JARs, EARs, or WARs in the `target` directory. To upload those as artifacts, you can copy them into a new directory that contains artifacts to upload. For example, you can create a directory called `staging`. Then you can upload the contents of that directory using the `upload-artifact` action.
{% raw %}
-```yaml
+```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v1
diff --git a/content/actions/guides/building-and-testing-nodejs.md b/content/actions/guides/building-and-testing-nodejs.md
index 480d359be1..98d9469110 100644
--- a/content/actions/guides/building-and-testing-nodejs.md
+++ b/content/actions/guides/building-and-testing-nodejs.md
@@ -77,7 +77,7 @@ The template includes a matrix strategy that builds and tests your code with fou
Each job can access the value defined in the matrix `node-version` array using the `matrix` context. The `setup-node` action uses the context as the `node-version` input. The `setup-node` action configures each job with a different Node.js version before building and testing code. For more information about matrix strategies and contexts, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix)" and "[Context and expression syntax for {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)."
{% raw %}
-```yaml
+```yaml{:copy}
strategy:
matrix:
node-version: [10.x, 12.x, 14.x, 15.x]
@@ -93,7 +93,7 @@ steps:
Alternatively, you can build and test with exact Node.js versions.
-```yaml
+```yaml{:copy}
strategy:
matrix:
node-version: [8.16.2, 10.17.0]
@@ -102,7 +102,7 @@ strategy:
Or, you can build and test using a single version of Node.js too.
{% raw %}
-```yaml
+```yaml{:copy}
name: Node.js CI
on: [push]
@@ -136,7 +136,7 @@ When using {% data variables.product.prodname_dotcom %}-hosted runners, you can
This example installs the dependencies defined in the *package.json* file. For more information, see [`npm install`](https://docs.npmjs.com/cli/install).
-```yaml
+```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Use Node.js
@@ -150,7 +150,7 @@ steps:
Using `npm ci` installs the versions in the *package-lock.json* or *npm-shrinkwrap.json* file and prevents updates to the lock file. Using `npm ci` is generally faster than running `npm install`. For more information, see [`npm ci`](https://docs.npmjs.com/cli/ci.html) and "[Introducing `npm ci` for faster, more reliable builds](https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable)."
{% raw %}
-```yaml
+```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Use Node.js
@@ -166,7 +166,7 @@ steps:
This example installs the dependencies defined in the *package.json* file. For more information, see [`yarn install`](https://yarnpkg.com/en/docs/cli/install).
-```yaml
+```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Use Node.js
@@ -179,7 +179,7 @@ steps:
Alternatively, you can pass `--frozen-lockfile` to install the versions in the *yarn.lock* file and prevent updates to the *yarn.lock* file.
-```yaml
+```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Use Node.js
@@ -201,7 +201,7 @@ In the example below, the secret `NPM_TOKEN` stores the npm authentication token
Before installing dependencies, use the `setup-node` action to create the *.npmrc* file. The action has two input parameters. The `node-version` parameter sets the Node.js version, and the `registry-url` parameter sets the default registry. If your package registry uses scopes, you must use the `scope` parameter. For more information, see [`npm-scope`](https://docs.npmjs.com/misc/scope).
{% raw %}
-```yaml
+```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Use Node.js
@@ -231,7 +231,7 @@ always-auth=true
When using {% data variables.product.prodname_dotcom %}-hosted runners, you can cache dependencies using a unique key, and restore the dependencies when you run future workflows using the `cache` action. For more information, see "Caching dependencies to speed up workflows" and the [`cache` action](https://github.com/marketplace/actions/cache).
{% raw %}
-```yaml
+```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Use Node.js
@@ -256,7 +256,7 @@ steps:
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.
-```yaml
+```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Use Node.js
diff --git a/content/actions/guides/building-and-testing-python.md b/content/actions/guides/building-and-testing-python.md
index 6f44851aed..37941d1612 100644
--- a/content/actions/guides/building-and-testing-python.md
+++ b/content/actions/guides/building-and-testing-python.md
@@ -37,7 +37,7 @@ We recommend that you have a basic understanding of Python, PyPy, and pip. For m
To get started quickly, add the template to the `.github/workflows` directory of your repository.
{% raw %}
-```yaml
+```yaml{:copy}
name: Python package
on: [push]
@@ -94,7 +94,7 @@ If you are using a self-hosted runner, you can configure the runner to use the `
#### Using multiple Python versions
{% raw %}
-```yaml
+```yaml{:copy}
name: Python package
on: [push]
@@ -126,7 +126,7 @@ jobs:
You can configure a specific version of python. For example, 3.8. Alternatively, you can use semantic version syntax to get the latest minor release. This example uses the latest minor release of Python 3.
{% raw %}
-```yaml
+```yaml{:copy}
name: Python package
on: [push]
@@ -158,7 +158,7 @@ If you specify a version of Python that is not available, `setup-python` fails w
You can also use the `exclude` keyword in your workflow if there is a configuration of Python that you do not wish to run. For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategy)."
{% raw %}
-```yaml
+```yaml{:copy}
name: Python package
on: [push]
@@ -196,7 +196,7 @@ We recommend using `setup-python` to configure the version of Python used in you
When using {% data variables.product.prodname_dotcom %}-hosted runners, you can also cache dependencies to speed up your workflow. For more information, see "Caching dependencies to speed up workflows."
{% raw %}
-```yaml
+```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Set up Python
@@ -213,7 +213,7 @@ steps:
After you update `pip`, a typical next step is to install dependencies from *requirements.txt*.
{% raw %}
-```yaml
+```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Set up Python
@@ -234,7 +234,7 @@ When using {% data variables.product.prodname_dotcom %}-hosted runners, you can
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 below 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).
{% raw %}
-```yaml
+```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Setup Python
@@ -271,7 +271,7 @@ You can use the same commands that you use locally to build and test your code.
This example installs or upgrades `pytest` and `pytest-cov`. Tests are then run and output in JUnit format while code coverage results are output in Cobertura. For more information, see [JUnit](https://junit.org/junit5/) and [Cobertura](https://cobertura.github.io/cobertura/).
{% raw %}
-```yaml
+```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Set up Python
@@ -295,7 +295,7 @@ steps:
The following example installs or upgrades `flake8` and uses it to lint all files. For more information, see [Flake8](http://flake8.pycqa.org/en/latest/).
{% raw %}
-```yaml
+```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Set up Python
@@ -318,7 +318,7 @@ steps:
With {% data variables.product.prodname_actions %}, you can run tests with tox and spread the work across multiple jobs. You'll need to invoke tox using the `-e py` option to choose the version of Python in your `PATH`, rather than specifying a specific version. For more information, see [tox](https://tox.readthedocs.io/en/latest/).
{% raw %}
-```yaml
+```yaml{:copy}
name: Python package
on: [push]
@@ -352,7 +352,7 @@ You can upload artifacts to view after a workflow completes. For example, you ma
The following example demonstrates how you can use the `upload-artifact` action to archive test results from running `pytest`. For more information, see the [`upload-artifact` action](https://github.com/actions/upload-artifact).
{% raw %}
-```yaml
+```yaml{:copy}
name: Python package
on: [push]
@@ -395,7 +395,7 @@ You can configure your workflow to publish your Python package to any package re
You can store any access tokens or credentials needed to publish your package using secrets. The following example creates and publishes a package to PyPI using `twine` and `dist`. For more information, see "[Creating and using encrypted secrets](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
{% raw %}
-```yaml
+```yaml{:copy}
name: Upload Python Package
on:
diff --git a/content/actions/guides/caching-dependencies-to-speed-up-workflows.md b/content/actions/guides/caching-dependencies-to-speed-up-workflows.md
index 1e43aea478..9954a6229d 100644
--- a/content/actions/guides/caching-dependencies-to-speed-up-workflows.md
+++ b/content/actions/guides/caching-dependencies-to-speed-up-workflows.md
@@ -68,7 +68,7 @@ For more information, see [`actions/cache`](https://github.com/actions/cache).
This example creates a new cache when the packages in `package-lock.json` file change, or when the runner's operating system changes. The cache key uses contexts and expressions to generate a key that includes the runner's operating system and a SHA-256 hash of the `package-lock.json` file.
{% raw %}
-```yaml
+```yaml{:copy}
name: Caching with npm
on: push
diff --git a/content/actions/guides/creating-postgresql-service-containers.md b/content/actions/guides/creating-postgresql-service-containers.md
index e3967ef172..76a41c11a9 100644
--- a/content/actions/guides/creating-postgresql-service-containers.md
+++ b/content/actions/guides/creating-postgresql-service-containers.md
@@ -37,7 +37,7 @@ You may also find it helpful to have a basic understanding of YAML, the syntax f
{% data reusables.github-actions.copy-workflow-file %}
{% raw %}
-```yaml
+```yaml{:copy}
name: PostgreSQL service example
on: push
@@ -94,7 +94,7 @@ jobs:
{% data reusables.github-actions.postgres-label-description %}
-```yaml
+```yaml{:copy}
jobs:
# Label of the container job
container-job:
@@ -124,7 +124,7 @@ jobs:
{% data reusables.github-actions.service-template-steps %}
-```yaml
+```yaml{:copy}
steps:
# Downloads a copy of the code in your repository before running CI tests
- name: Check out repository code
@@ -159,7 +159,7 @@ When you run a job directly on the runner machine, you'll need to map the ports
{% data reusables.github-actions.copy-workflow-file %}
{% raw %}
-```yaml
+```yaml{:copy}
name: PostgreSQL Service Example
on: push
@@ -220,7 +220,7 @@ jobs:
The workflow maps port 5432 on the PostgreSQL service container to the Docker host. For more information about the `ports` keyword, see "[About service containers](/actions/automating-your-workflow-with-github-actions/about-service-containers#mapping-docker-host-and-service-container-ports)."
-```yaml
+```yaml{:copy}
jobs:
# Label of the runner job
runner-job:
@@ -251,7 +251,7 @@ jobs:
{% data reusables.github-actions.service-template-steps %}
-```yaml
+```yaml{:copy}
steps:
# Downloads a copy of the code in your repository before running CI tests
- name: Check out repository code
@@ -287,7 +287,7 @@ You can modify *client.js* to include any PostgreSQL operations needed by your w
{% data reusables.github-actions.service-container-add-script %}
-```javascript
+```javascript{:copy}
const { Client } = require('pg');
const pgclient = new Client({
diff --git a/content/actions/guides/creating-redis-service-containers.md b/content/actions/guides/creating-redis-service-containers.md
index 4b7c9918c4..ae29fc7e07 100644
--- a/content/actions/guides/creating-redis-service-containers.md
+++ b/content/actions/guides/creating-redis-service-containers.md
@@ -37,7 +37,7 @@ You may also find it helpful to have a basic understanding of YAML, the syntax f
{% data reusables.github-actions.copy-workflow-file %}
{% raw %}
-```yaml
+```yaml{:copy}
name: Redis container example
on: push
@@ -91,7 +91,7 @@ jobs:
{% data reusables.github-actions.redis-label-description %}
-```yaml
+```yaml{:copy}
jobs:
# Label of the container job
container-job:
@@ -118,7 +118,7 @@ jobs:
{% data reusables.github-actions.service-template-steps %}
-```yaml
+```yaml{:copy}
steps:
# Downloads a copy of the code in your repository before running CI tests
- name: Check out repository code
@@ -152,7 +152,7 @@ When you run a job directly on the runner machine, you'll need to map the ports
{% data reusables.github-actions.copy-workflow-file %}
{% raw %}
-```yaml
+```yaml{:copy}
name: Redis runner example
on: push
@@ -210,7 +210,7 @@ jobs:
The workflow maps port 6379 on the Redis service container to the Docker host. For more information about the `ports` keyword, see "[About service containers](/actions/automating-your-workflow-with-github-actions/about-service-containers#mapping-docker-host-and-service-container-ports)."
-```yaml
+```yaml{:copy}
jobs:
# Label of the runner job
runner-job:
@@ -238,7 +238,7 @@ jobs:
{% data reusables.github-actions.service-template-steps %}
-```yaml
+```yaml{:copy}
steps:
# Downloads a copy of the code in your repository before running CI tests
- name: Check out repository code
@@ -274,7 +274,7 @@ You can modify *client.js* to include any Redis operations needed by your workfl
{% data reusables.github-actions.service-container-add-script %}
-```javascript
+```javascript{:copy}
const redis = require("redis");
// Creates a new Redis client
diff --git a/content/actions/guides/publishing-docker-images.md b/content/actions/guides/publishing-docker-images.md
index b0f2ca729f..7d372f4a1e 100644
--- a/content/actions/guides/publishing-docker-images.md
+++ b/content/actions/guides/publishing-docker-images.md
@@ -55,7 +55,7 @@ The `build-push-action` options required for Docker Hub are:
* `repository`: Your Docker Hub repository in the format `DOCKER-HUB-NAMESPACE/DOCKER-HUB-REPOSITORY`.
{% raw %}
-```yaml
+```yaml{:copy}
name: Publish Docker image
on:
release:
@@ -93,7 +93,7 @@ The `build-push-action` options required for {% data variables.product.prodname_
* `repository`: Must be set in the format `OWNER/REPOSITORY/IMAGE_NAME`. For example, for an image named `octo-image` stored on {% data variables.product.prodname_dotcom %} at `http://github.com/octo-org/octo-repo`, the `repository` option should be set to `octo-org/octo-repo/octo-image`.
{% raw %}
-```yaml
+```yaml{:copy}
name: Publish Docker image
on:
release:
@@ -126,7 +126,7 @@ In a single workflow, you can publish your Docker image to multiple registries b
The following example workflow uses the `build-push-action` steps from the previous sections ("[Publishing images to Docker Hub](#publishing-images-to-docker-hub)" and "[Publishing images to {% data variables.product.prodname_registry %}](#publishing-images-to-github-packages)") to create a single workflow that pushes to both registries.
{% raw %}
-```yaml
+```yaml{:copy}
name: Publish Docker image
on:
release:
diff --git a/content/actions/guides/publishing-java-packages-with-gradle.md b/content/actions/guides/publishing-java-packages-with-gradle.md
index 7eca03c8c0..351685c7cd 100644
--- a/content/actions/guides/publishing-java-packages-with-gradle.md
+++ b/content/actions/guides/publishing-java-packages-with-gradle.md
@@ -43,7 +43,7 @@ Each time you create a new release, you can trigger a workflow to publish your p
You can define a new Maven repository in the publishing block of your _build.gradle_ file that points to your package repository. For example, if you were deploying to the Maven Central Repository through the OSSRH hosting project, your _build.gradle_ could specify a repository with the name `"OSSRH"`.
{% raw %}
-```groovy
+```groovy{:copy}
publishing {
...
@@ -67,7 +67,7 @@ In the deploy step, you’ll need to set environment variables for the username
{% raw %}
-```yaml
+```yaml{:copy}
name: Publish package to the Maven Central Repository
on:
release:
@@ -105,7 +105,7 @@ The `GITHUB_TOKEN` exists in your repository by default and has read and write p
For example, if your organization is named "octocat" and your repository is named "hello-world", then the {% data variables.product.prodname_registry %} configuration in _build.gradle_ would look similar to the below example.
{% raw %}
-```groovy
+```groovy{:copy}
publishing {
...
@@ -126,7 +126,7 @@ publishing {
With this configuration, you can create a workflow that publishes your package to the Maven Central Repository by running the `gradle publish` command.
{% raw %}
-```yaml
+```yaml{:copy}
name: Publish package to GitHub Packages
on:
release:
@@ -162,7 +162,7 @@ For example, if you deploy to the Central Repository through the OSSRH hosting p
If your organization is named "octocat" and your repository is named "hello-world", then the {% data variables.product.prodname_registry %} configuration in _build.gradle_ would look similar to the below example.
{% raw %}
-```groovy
+```groovy{:copy}
publishing {
...
@@ -191,7 +191,7 @@ publishing {
With this configuration, you can create a workflow that publishes your package to both the Maven Central Repository and {% data variables.product.prodname_registry %} by running the `gradle publish` command.
{% raw %}
-```yaml
+```yaml{:copy}
name: Publish package to the Maven Central Repository and GitHub Packages
on:
release:
diff --git a/content/actions/guides/publishing-java-packages-with-maven.md b/content/actions/guides/publishing-java-packages-with-maven.md
index 0b2c6c89be..e615b185ff 100644
--- a/content/actions/guides/publishing-java-packages-with-maven.md
+++ b/content/actions/guides/publishing-java-packages-with-maven.md
@@ -47,7 +47,7 @@ In this workflow, you can use the `setup-java` action. This action installs the
For example, if you were deploying to the Maven Central Repository through the OSSRH hosting project, your _pom.xml_ could specify a distribution management repository with the `id` of `ossrh`.
{% raw %}
-```xml
+```xml{:copy}
...
@@ -67,7 +67,7 @@ In the deploy step, you’ll need to set the environment variables to the userna
{% raw %}
-```yaml
+```yaml{:copy}
name: Publish package to the Maven Central Repository
on:
release:
@@ -113,7 +113,7 @@ For a Maven-based project, you can make use of these settings by creating a dist
For example, if your organization is named "octocat" and your repository is named "hello-world", then the {% data variables.product.prodname_registry %} configuration in _pom.xml_ would look similar to the below example.
{% raw %}
-```xml
+```xml{:copy}
...
@@ -130,7 +130,7 @@ For example, if your organization is named "octocat" and your repository is name
With this configuration, you can create a workflow that publishes your package to {% data variables.product.prodname_registry %} by making use of the automatically generated _settings.xml_.
{% raw %}
-```yaml
+```yaml{:copy}
name: Publish package to GitHub Packages
on:
release:
@@ -165,7 +165,7 @@ You can publish your packages to both the Maven Central Repository and {% data v
Ensure your _pom.xml_ file includes a distribution management repository for both your {% data variables.product.prodname_dotcom %} repository and your Maven Central Repository provider. For example, if you deploy to the Central Repository through the OSSRH hosting project, you might want to specify it in a distribution management repository with the `id` set to `ossrh`, and you might want to specify {% data variables.product.prodname_registry %} in a distribution management repository with the `id` set to `github`.
{% raw %}
-```yaml
+```yaml{:copy}
name: Publish package to the Maven Central Repository and GitHub Packages
on:
release:
diff --git a/content/actions/guides/publishing-nodejs-packages.md b/content/actions/guides/publishing-nodejs-packages.md
index 8b79ba457c..726e1f9bd2 100644
--- a/content/actions/guides/publishing-nodejs-packages.md
+++ b/content/actions/guides/publishing-nodejs-packages.md
@@ -54,7 +54,7 @@ If you're publishing a package that includes a scope prefix, include the scope i
This example stores the `NPM_TOKEN` secret in the `NODE_AUTH_TOKEN` environment variable. When the `setup-node` action creates an *.npmrc* file, it references the token from the `NODE_AUTH_TOKEN` environment variable.
{% raw %}
-```yaml
+```yaml{:copy}
name: Node.js Package
on:
release:
@@ -114,7 +114,7 @@ If you want to publish your package to a different repository, you must use a pe
This example stores the `GITHUB_TOKEN` secret in the `NODE_AUTH_TOKEN` environment variable. When the `setup-node` action creates an *.npmrc* file, it references the token from the `NODE_AUTH_TOKEN` environment variable.
{% raw %}
-```yaml
+```yaml{:copy}
name: Node.js Package
on:
release:
@@ -151,7 +151,7 @@ always-auth=true
If you use the Yarn package manager, you can install and publish packages using Yarn.
{% raw %}
-```yaml
+```yaml{:copy}
name: Node.js Package
on:
release:
@@ -196,7 +196,7 @@ When you use the `scope` input to the `setup-node` action, the action creates an
This workflow calls the `setup-node` action two times. Each time the `setup-node` action runs, it overwrites the *.npmrc* file. The *.npmrc* file references the token that allows you to perform authenticated operations against the package registry from the `NODE_AUTH_TOKEN` environment variable. The workflow sets the `NODE_AUTH_TOKEN` environment variable each time the `npm publish` command is run, first with a token to publish to npm (`NPM_TOKEN`) and then with a token to publish to {% data variables.product.prodname_registry %} (`GITHUB_TOKEN`).
{% raw %}
-```yaml
+```yaml{:copy}
name: Node.js Package
on:
release:
diff --git a/content/actions/guides/storing-workflow-data-as-artifacts.md b/content/actions/guides/storing-workflow-data-as-artifacts.md
index 763158ff58..a382ebc76b 100644
--- a/content/actions/guides/storing-workflow-data-as-artifacts.md
+++ b/content/actions/guides/storing-workflow-data-as-artifacts.md
@@ -79,7 +79,7 @@ This example shows you how to create a workflow for a Node.js project that build
The workflow uploads the production artifacts in the `dist` directory, but excludes any markdown files. It also and uploads the `code-coverage.html` report as another artifact.
-```yaml
+```yaml{:copy}
name: Node CI
on: [push]
@@ -114,7 +114,7 @@ jobs:
You can define a custom retention period for individual artifacts created by a workflow. When using a workflow to create a new artifact, you can use `retention-days` with the `upload-artifact` action. This example demonstrates how to set a custom retention period of 5 days for the artifact named `my-artifact`:
-```yaml
+```yaml{:copy}
- name: 'Upload Artifact'
uses: actions/upload-artifact@v2
with:
@@ -183,7 +183,7 @@ Job 3 displays the result uploaded in the previous job:
The full math operation performed in this workflow example is `(3 + 7) x 9 = 90`.
-```yaml
+```yaml{:copy}
name: Share data between jobs
on: [push]
diff --git a/data/reusables/github-actions/java-jvm-architecture.md b/data/reusables/github-actions/java-jvm-architecture.md
index 2ad79b4182..33c7bd3120 100644
--- a/data/reusables/github-actions/java-jvm-architecture.md
+++ b/data/reusables/github-actions/java-jvm-architecture.md
@@ -5,7 +5,7 @@ The starter workflow template sets up the `PATH` to contain OpenJDK 8 for the x6
For example, to use version 9.0.4 of the JDK for the x64 platform, you can use the `setup-java` action and configure the `java-version` and `architecture` parameters to `'9.0.4'` and `x64`.
{% raw %}
-```yaml
+```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Set up JDK 9.0.4 for x64