jprdonnelly/docs
1
0
Fork 0
mirror of synced 2026-01-05 21:04:17 -05:00
Code Issues Projects Releases Wiki Activity

Merge branch 'main' into patch-2

Browse Source
This commit is contained in:
mc
2022-04-04 11:06:46 +01:00
committed by GitHub
parent 35f503443c 3296d5a802
commit 8d4d5250e5
478 changed files with 6644 additions and 9800 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
CONTRIBUTING.md
View File

@@ -42,6 +42,10 @@ Click **Make a contribution** at the bottom of any docs page to make small chang
<img src="./assets/images/contribution_cta.png" width="300" height="150" />
#### Make changes in a codespace
For more information about using a codespace for working on GitHub documentation, see "[Working in a codespace](https://github.com/github/docs/blob/main/contributing/codespace.md)."
#### Make changes locally
1. [Install Git LFS](https://docs.github.com/en/github/managing-large-files/versioning-large-files/installing-git-large-file-storage).
@@ -54,9 +58,6 @@ Click **Make a contribution** at the bottom of any docs page to make small chang
- Using the command line:
- [Fork the repo](https://docs.github.com/en/github/getting-started-with-github/fork-a-repo#fork-an-example-repository) so that you can make your changes without affecting the original project until you're ready to merge them.
- GitHub Codespaces:
- [Fork, edit, and preview](https://docs.github.com/en/free-pro-team@latest/github/developing-online-with-codespaces/creating-a-codespace) using [GitHub Codespaces](https://github.com/features/codespaces) without having to install and run the project locally.
3. Install or update to **Node.js v16**. For more information, see [the development guide](contributing/development.md).
4. Create a working branch and start with your changes!

BIN
assets/images/help/billing/pay-now-button-disabled.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 25 KiB

After

Width:  |  Height:  |  Size: 12 KiB

BIN
assets/images/help/billing/pay-now-button.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 32 KiB

After

Width:  |  Height:  |  Size: 60 KiB

BIN
assets/images/help/billing/payment-summary-edit.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 60 KiB

After

Width:  |  Height:  |  Size: 52 KiB

BIN
assets/images/help/billing/payment-summary.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 46 KiB

After

Width:  |  Height:  |  Size: 39 KiB

BIN
assets/images/help/pull_requests/merge-queue-link.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 15 KiB

BIN
assets/images/help/pull_requests/merge-queue-merging-method.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 40 KiB

BIN
assets/images/help/pull_requests/merge-queue-options.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 40 KiB

After

Width:  |  Height:  |  Size: 22 KiB

BIN
assets/images/help/pull_requests/merge-queue-view.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 26 KiB

After

Width:  |  Height:  |  Size: 21 KiB

BIN
assets/images/help/pull_requests/remove-from-queue-button.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 15 KiB

BIN
assets/images/help/pull_requests/view-merge-queue-button.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 19 KiB

14
components/context/ProductLandingContext.tsx
View File

@@ -38,11 +38,7 @@ export type ProductLandingContextT = {
intro: string
beta_product: boolean
product: Product
introLinks: {
quickstart?: string
reference?: string
overview?: string
} | null
introLinks: Record<string, string> | null
product_video?: string
featuredLinks: Record<string, Array<FeaturedLink>>
productCodeExamples: Array<CodeExample>
@@ -128,13 +124,7 @@ export const getProductLandingContextFromRequest = (req: any): ProductLandingCon
})
),
introLinks: page.introLinks
? {
quickstart: page.introLinks.quickstart,
reference: page.introLinks.reference,
overview: page.introLinks.overview,
}
: null,
introLinks: page.introLinks || null,
featuredLinks: getFeaturedLinksFromReq(req),

31
components/landing/LandingHero.tsx
View File

@@ -1,8 +1,9 @@
import { useEffect, useState } from 'react'
import cx from 'classnames'
import { useRouter } from 'next/router'
import { useMainContext } from 'components/context/MainContext'
import { LinkExternalIcon } from '@primer/octicons-react'
import { useMainContext } from 'components/context/MainContext'
import { Link } from 'components/Link'
import { useProductLandingContext } from 'components/context/ProductLandingContext'
import { useTranslation } from 'components/hooks/useTranslation'
@@ -46,7 +47,7 @@ export const LandingHero = () => {
href={link}
className={cx('btn btn-large f4 mt-3 mr-3 ', i === 0 && 'btn-primary')}
>
{t(key)}
{t(key) || key}
</FullLink>
)
})}
@@ -72,7 +73,8 @@ export const LandingHero = () => {
)
}
// Fully Qualified Link - it includes the version and locale in the path
// Fully Qualified Link - it includes the version and locale in the path if
// the href is not an external link.
type Props = {
href: string
children: React.ReactNode
@@ -81,13 +83,24 @@ type Props = {
export const FullLink = ({ href, children, className }: Props) => {
const router = useRouter()
const { currentVersion } = useVersion()
const locale = router.locale || 'en'
const fullyQualifiedHref = `/${locale}${
currentVersion !== 'free-pro-team@latest' ? `/${currentVersion}` : ''
}${href}`
const isExternal = href.startsWith('https')
let linkHref = href
if (!isExternal) {
const locale = router.locale || 'en'
linkHref = `/${locale}${
currentVersion !== 'free-pro-team@latest' ? `/${currentVersion}` : ''
}${href}`
}
return (
<Link href={fullyQualifiedHref} className={className}>
{children}
<Link href={linkHref} className={className}>
{children}{' '}
{isExternal && (
<span className="ml-1">
<LinkExternalIcon size="small" />
</span>
)}
</Link>
)
}

40
components/playground/content/actions/guides/building-and-testing-nodejs-or-python/nodejs.tsx
View File

@@ -242,9 +242,9 @@ const article: PlaygroundArticleT = {
node-version: [10.x, 12.x, 14.x, 15.x]
steps:
- uses: actions/checkout@v2
- uses: actions/checkout@v3
- name: Use Node.js \${{ matrix.node-version }}
uses: actions/setup-node@v2
uses: actions/setup-node@v3
with:
node-version: \${{ matrix.node-version }}
- name: Install dependencies
@@ -275,9 +275,9 @@ const article: PlaygroundArticleT = {
node-version: [8.16.2, 10.17.0]
steps:
- uses: actions/checkout@v2
- uses: actions/checkout@v3
- name: Use Node.js \${{ matrix.node-version }}
uses: actions/setup-node@v2
uses: actions/setup-node@v3
with:
node-version: \${{ matrix.node-version }}
- name: Install dependencies
@@ -304,9 +304,9 @@ const article: PlaygroundArticleT = {
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/checkout@v3
- name: Use Node.js
uses: actions/setup-node@v1
uses: actions/setup-node@v3
with:
node-version: '12.x'
- name: Install dependencies
@@ -333,9 +333,9 @@ const article: PlaygroundArticleT = {
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/checkout@v3
- name: Use Node.js
uses: actions/setup-node@v1
uses: actions/setup-node@v3
with:
node-version: '12.x'
- name: Install dependencies
@@ -362,9 +362,9 @@ const article: PlaygroundArticleT = {
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/checkout@v3
- name: Use Node.js
uses: actions/setup-node@v1
uses: actions/setup-node@v3
with:
node-version: '12.x'
- name: Install dependencies
@@ -391,9 +391,9 @@ const article: PlaygroundArticleT = {
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/checkout@v3
- name: Use Node.js
uses: actions/setup-node@v1
uses: actions/setup-node@v3
with:
node-version: '12.x'
- name: Install dependencies
@@ -420,9 +420,9 @@ const article: PlaygroundArticleT = {
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/checkout@v3
- name: Use Node.js
uses: actions/setup-node@v1
uses: actions/setup-node@v3
with:
node-version: '12.x'
- name: Install dependencies
@@ -450,9 +450,9 @@ const article: PlaygroundArticleT = {
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/checkout@v3
- name: Use Node.js
uses: actions/setup-node@v1
uses: actions/setup-node@v3
with:
always-auth: true
node-version: '12.x'
@@ -492,9 +492,9 @@ const article: PlaygroundArticleT = {
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/checkout@v3
- name: Use Node.js
uses: actions/setup-node@v1
uses: actions/setup-node@v3
with:
node-version: '12.x'
cache: 'npm'
@@ -520,9 +520,9 @@ const article: PlaygroundArticleT = {
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/checkout@v3
- name: Use Node.js
uses: actions/setup-node@v1
uses: actions/setup-node@v3
with:
node-version: '12.x'
- run: npm install

44
components/playground/content/actions/guides/building-and-testing-nodejs-or-python/python.tsx
View File

@@ -228,9 +228,9 @@ const article: PlaygroundArticleT = {
python-version: ["3.6", "3.7", "3.8", "3.9"]
steps:
- uses: actions/checkout@v2
- uses: actions/checkout@v3
- name: Set up Python \${{ matrix.python-version }}
uses: actions/setup-python@v2
uses: actions/setup-python@v3
with:
python-version: \${{ matrix.python-version }}
- name: Install dependencies
@@ -268,9 +268,9 @@ const article: PlaygroundArticleT = {
python-version: ["2.7", "3.6", "3.7", "3.8", "3.9"]
steps:
- uses: actions/checkout@v2
- uses: actions/checkout@v3
- name: Set up Python \${{ matrix.python-version }}
uses: actions/setup-python@v2
uses: actions/setup-python@v3
with:
python-version: \${{ matrix.python-version }}
# You can test your matrix by printing the current Python version
@@ -292,9 +292,9 @@ const article: PlaygroundArticleT = {
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/checkout@v3
- name: Set up Python 3.x
uses: actions/setup-python@v2
uses: actions/setup-python@v3
with:
# Semantic version range syntax or exact version of a Python version
python-version: '3.x'
@@ -341,9 +341,9 @@ const article: PlaygroundArticleT = {
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/checkout@v3
- name: Set up Python
uses: actions/setup-python@v2
uses: actions/setup-python@v3
with:
python-version: '3.x'
- name: Install dependencies
@@ -363,9 +363,9 @@ const article: PlaygroundArticleT = {
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/checkout@v3
- name: Set up Python
uses: actions/setup-python@v2
uses: actions/setup-python@v3
with:
python-version: '3.x'
- name: Install dependencies
@@ -387,9 +387,9 @@ const article: PlaygroundArticleT = {
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/checkout@v3
- name: Setup Python
uses: actions/setup-python@v2
uses: actions/setup-python@v3
with:
python-version: '3.x'
cache: 'pip'
@@ -410,9 +410,9 @@ const article: PlaygroundArticleT = {
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/checkout@v3
- name: Set up Python
uses: actions/setup-python@v2
uses: actions/setup-python@v3
with:
python-version: '3.x'
- name: Install dependencies
@@ -439,9 +439,9 @@ const article: PlaygroundArticleT = {
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/checkout@v3
- name: Set up Python
uses: actions/setup-python@v2
uses: actions/setup-python@v3
with:
python-version: '3.x'
- name: Install dependencies
@@ -471,9 +471,9 @@ const article: PlaygroundArticleT = {
python: ["3.7", "3.8", "3.9"]
steps:
- uses: actions/checkout@v2
- uses: actions/checkout@v3
- name: Setup Python
uses: actions/setup-python@v2
uses: actions/setup-python@v3
with:
python-version: \${{ matrix.python }}
- name: Install Tox and any other packages
@@ -500,9 +500,9 @@ const article: PlaygroundArticleT = {
python-version: ["3.6", "3.7", "3.8", "3.9"]
steps:
- uses: actions/checkout@v2
- uses: actions/checkout@v3
- name: Setup Python # Set Python version
uses: actions/setup-python@v2
uses: actions/setup-python@v3
with:
python-version: \${{ matrix.python-version }}
# Install pip and pytest
@@ -540,9 +540,9 @@ const article: PlaygroundArticleT = {
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/checkout@v3
- name: Set up Python
uses: actions/setup-python@v2
uses: actions/setup-python@v3
with:
python-version: '3.x'
- name: Install dependencies

20
content/actions/automating-builds-and-tests/building-and-testing-java-with-ant.md
View File

@@ -48,7 +48,6 @@ To get started quickly, you can choose the preconfigured Ant starter workflow wh
You can also add this workflow manually by creating a new file in the `.github/workflows` directory of your repository.
{% raw %}
```yaml{:copy}
name: Java CI
@@ -59,16 +58,15 @@ jobs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Set up JDK 11
uses: actions/setup-java@v2
uses: {% data reusables.actions.action-setup-java %}
with:
java-version: '11'
distribution: 'adopt'
- name: Build with Ant
run: ant -noinput -buildfile build.xml
```
{% endraw %}
This workflow performs the following steps:
@@ -90,18 +88,16 @@ 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{:copy}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v2
- uses: {% data reusables.actions.action-checkout %}
- uses: {% data reusables.actions.action-setup-java %}
with:
java-version: '11'
distribution: 'adopt'
- name: Run the Ant jar target
run: ant -noinput -buildfile build-ci.xml jar
```
{% endraw %}
## Packaging workflow data as artifacts
@@ -109,19 +105,17 @@ 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{:copy}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v2
- uses: {% data reusables.actions.action-checkout %}
- uses: {% data reusables.actions.action-setup-java %}
with:
java-version: '11'
distribution: 'adopt'
- run: ant -noinput -buildfile build.xml
- uses: actions/upload-artifact@v3
- uses: {% data reusables.actions.action-upload-artifact %}
with:
name: Package
path: build/jar
```
{% endraw %}

24
content/actions/automating-builds-and-tests/building-and-testing-java-with-gradle.md
View File

@@ -60,16 +60,16 @@ jobs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Set up JDK 11
uses: actions/setup-java@v2
uses: {% data reusables.actions.action-setup-java %}
with:
java-version: '11'
distribution: 'adopt'
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b
- name: Build with Gradle
uses: gradle/gradle-build-action@937999e9cc2425eddc7fd62d1053baf041147db7
uses: gradle/gradle-build-action@0d13054264b0bb894ded474f08ebb30921341cee
with:
arguments: build
```
@@ -95,22 +95,20 @@ 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{:copy}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v2
- uses: {% data reusables.actions.action-checkout %}
- uses: {% data reusables.actions.action-setup-java %}
with:
java-version: '11'
distribution: 'adopt'
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b
- name: Run the Gradle package task
uses: gradle/gradle-build-action@937999e9cc2425eddc7fd62d1053baf041147db7
uses: gradle/gradle-build-action@0d13054264b0bb894ded474f08ebb30921341cee
with:
arguments: -b ci.gradle package
```
{% endraw %}
## Caching dependencies
@@ -124,23 +122,21 @@ 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{:copy}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v2
- uses: {% data reusables.actions.action-checkout %}
- uses: {% data reusables.actions.action-setup-java %}
with:
java-version: '11'
distribution: 'adopt'
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b
- name: Build with Gradle
uses: gradle/gradle-build-action@937999e9cc2425eddc7fd62d1053baf041147db7
uses: gradle/gradle-build-action@0d13054264b0bb894ded474f08ebb30921341cee
with:
arguments: build
- uses: actions/upload-artifact@v3
- uses: {% data reusables.actions.action-upload-artifact %}
with:
name: Package
path: build/libs
```
{% endraw %}

26
content/actions/automating-builds-and-tests/building-and-testing-java-with-maven.md
View File

@@ -48,7 +48,6 @@ To get started quickly, you can choose the preconfigured Maven starter workflow
You can also add this workflow manually by creating a new file in the `.github/workflows` directory of your repository.
{% raw %}
```yaml{:copy}
name: Java CI
@@ -59,16 +58,15 @@ jobs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Set up JDK 11
uses: actions/setup-java@v2
uses: {% data reusables.actions.action-setup-java %}
with:
java-version: '11'
distribution: 'adopt'
- name: Build with Maven
run: mvn --batch-mode --update-snapshots verify
```
{% endraw %}
This workflow performs the following steps:
@@ -90,29 +88,26 @@ 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{:copy}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v2
- uses: {% data reusables.actions.action-checkout %}
- uses: {% data reusables.actions.action-setup-java %}
with:
java-version: '11'
distribution: 'adopt'
- name: Run the Maven verify phase
run: mvn --batch-mode --update-snapshots verify
```
{% endraw %}
## Caching dependencies
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. 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.
{% raw %}
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Set up JDK 11
uses: actions/setup-java@v2
uses: {% data reusables.actions.action-setup-java %}
with:
java-version: '11'
distribution: 'adopt'
@@ -120,7 +115,6 @@ steps:
- name: Build with Maven
run: mvn --batch-mode --update-snapshots verify
```
{% endraw %}
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.
@@ -130,19 +124,17 @@ 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{:copy}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v2
- uses: {% data reusables.actions.action-checkout %}
- uses: {% data reusables.actions.action-setup-java %}
with:
java-version: '11'
distribution: 'adopt'
- run: mvn --batch-mode --update-snapshots verify
- run: mkdir staging && cp target/*.jar staging
- uses: actions/upload-artifact@v3
- uses: {% data reusables.actions.action-upload-artifact %}
with:
name: Package
path: staging
```
{% endraw %}

73
content/actions/automating-builds-and-tests/building-and-testing-net.md
View File

@@ -34,8 +34,6 @@ We recommend that you have a basic understanding of the .NET Core SDK. For more
To get started quickly, add the starter workflow to the `.github/workflows` directory of your repository.
{% raw %}
```yaml
name: dotnet package
@@ -50,11 +48,11 @@ jobs:
dotnet-version: ['3.0', '3.1.x', '5.0.x' ]
steps:
- uses: actions/checkout@v2
- name: Setup .NET Core SDK ${{ matrix.dotnet-version }}
uses: actions/setup-dotnet@v1.7.2
- uses: {% data reusables.actions.action-checkout %}
- name: Setup .NET Core SDK {% raw %}${{ matrix.dotnet-version }}{% endraw %}
uses: {% data reusables.actions.action-setup-dotnet %}
with:
dotnet-version: ${{ matrix.dotnet-version }}
dotnet-version: {% raw %}${{ matrix.dotnet-version }}{% endraw %}
- name: Install dependencies
run: dotnet restore
- name: Build
@@ -63,8 +61,6 @@ jobs:
run: dotnet test --no-restore --verbosity normal
```
{% endraw %}
## Specifying a .NET version
To use a preinstalled version of the .NET Core SDK on a {% data variables.product.prodname_dotcom %}-hosted runner, use the `setup-dotnet` action. This action finds a specific version of .NET from the tools cache on each runner, and adds the necessary binaries to `PATH`. These changes will persist for the remainder of the job.
@@ -73,7 +69,6 @@ The `setup-dotnet` action is the recommended way of using .NET with {% data vari
### Using multiple .NET versions
{% raw %}
```yaml
name: dotnet package
@@ -88,47 +83,42 @@ jobs:
dotnet-version: [ '3.0', '3.1.x', '5.0.x' ]
steps:
- uses: actions/checkout@v2
- name: Setup dotnet ${{ matrix.dotnet-version }}
uses: actions/setup-dotnet@v1
- uses: {% data reusables.actions.action-checkout %}
- name: Setup dotnet {% raw %}${{ matrix.dotnet-version }}{% endraw %}
uses: {% data reusables.actions.action-setup-dotnet %}
with:
dotnet-version: ${{ matrix.dotnet-version }}
dotnet-version: {% raw %}${{ matrix.dotnet-version }}{% endraw %}
# You can test your matrix by printing the current dotnet version
- name: Display dotnet version
run: dotnet --version
```
{% endraw %}
### Using a specific .NET version
You can configure your job to use a specific version of .NET, such as `3.1.3`. Alternatively, you can use semantic version syntax to get the latest minor release. This example uses the latest minor release of .NET 3.
{% raw %}
```yaml
- name: Setup .NET 3.x
uses: actions/setup-dotnet@v1
uses: {% data reusables.actions.action-setup-dotnet %}
with:
# Semantic version range syntax or exact version of a dotnet version
dotnet-version: '3.x'
```
{% endraw %}
## Installing dependencies
{% data variables.product.prodname_dotcom %}-hosted runners have the NuGet package manager installed. You can use the dotnet CLI to install dependencies from the NuGet package registry before building and testing your code. For example, the YAML below installs the `Newtonsoft` package.
{% raw %}
```yaml
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Setup dotnet
uses: actions/setup-dotnet@v1
uses: {% data reusables.actions.action-setup-dotnet %}
with:
dotnet-version: '3.1.x'
- name: Install dependencies
run: dotnet add package Newtonsoft.Json --version 12.0.1
```
{% endraw %}
{% ifversion fpt or ghec %}
@@ -138,25 +128,23 @@ You can cache NuGet dependencies using a unique key, which allows you to restore
For more information, see "[Caching dependencies to speed up workflows](/actions/guides/caching-dependencies-to-speed-up-workflows)."
{% raw %}
```yaml
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Setup dotnet
uses: actions/setup-dotnet@v1
uses: {% data reusables.actions.action-setup-dotnet %}
with:
dotnet-version: '3.1.x'
- uses: actions/cache@v2
- uses: {% data reusables.actions.action-cache %}
with:
path: ~/.nuget/packages
# Look to see if there is a cache hit for the corresponding requirements file
key: ${{ runner.os }}-nuget-${{ hashFiles('**/packages.lock.json') }}
key: {% raw %}${{ runner.os }}-nuget-${{ hashFiles('**/packages.lock.json') }}
restore-keys: |
${{ runner.os }}-nuget
${{ runner.os }}-nuget{% endraw %}
- name: Install dependencies
run: dotnet add package Newtonsoft.Json --version 12.0.1
```
{% endraw %}
{% note %}
@@ -170,12 +158,11 @@ steps:
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:
{% raw %}
```yaml
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Setup dotnet
uses: actions/setup-dotnet@v1
uses: {% data reusables.actions.action-setup-dotnet %}
with:
dotnet-version: '3.1.x'
- name: Install dependencies
@@ -185,7 +172,6 @@ steps:
- name: Test with the dotnet CLI
run: dotnet test
```
{% endraw %}
## Packaging workflow data as artifacts
@@ -193,7 +179,7 @@ After a workflow completes, you can upload the resulting artifacts for analysis.
For more information, see "[Persisting workflow data using artifacts](/github/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)."
{% raw %}
```yaml
name: dotnet package
@@ -208,24 +194,23 @@ jobs:
dotnet-version: [ '3.0', '3.1.x', '5.0.x' ]
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Setup dotnet
uses: actions/setup-dotnet@v1
uses: {% data reusables.actions.action-setup-dotnet %}
with:
dotnet-version: ${{ matrix.dotnet-version }}
dotnet-version: {% raw %}${{ matrix.dotnet-version }}{% endraw %}
- name: Install dependencies
run: dotnet restore
- name: Test with dotnet
run: dotnet test --logger trx --results-directory "TestResults-${{ matrix.dotnet-version }}"
run: dotnet test --logger trx --results-directory {% raw %}"TestResults-${{ matrix.dotnet-version }}"{% endraw %}
- name: Upload dotnet test results
uses: actions/upload-artifact@v3
uses: {% data reusables.actions.action-upload-artifact %}
with:
name: dotnet-results-${{ matrix.dotnet-version }}
path: TestResults-${{ matrix.dotnet-version }}
name: {% raw %}dotnet-results-${{ matrix.dotnet-version }}{% endraw %}
path: {% raw %}TestResults-${{ matrix.dotnet-version }}{% endraw %}
# Use always() to always run this step to publish test results when there are test failures
if: ${{ always() }}
if: {% raw %}${{ always() }}{% endraw %}
```
{% endraw %}
## Publishing to package registries
@@ -245,8 +230,8 @@ jobs:
packages: write
contents: read{% endif %}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-dotnet@v1
- uses: {% data reusables.actions.action-checkout %}
- uses: {% data reusables.actions.action-setup-dotnet %}
with:
dotnet-version: '3.1.x' # SDK Version to use.
source-url: https://nuget.pkg.github.com/<owner>/index.json

69
content/actions/automating-builds-and-tests/building-and-testing-nodejs.md
View File

@@ -42,7 +42,6 @@ We recommend that you have a basic understanding of Node.js, YAML, workflow conf
To get started quickly, add the starter workflow to the `.github/workflows` directory of your repository. The workflow shown below assumes that the default branch for your repository is `main`.
{% raw %}
```yaml{:copy}
name: Node.js CI
@@ -62,16 +61,15 @@ jobs:
node-version: [10.x, 12.x, 14.x, 15.x]
steps:
- uses: actions/checkout@v2
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Use Node.js {% raw %}${{ matrix.node-version }}{% endraw %}
uses: {% data reusables.actions.action-setup-node %}
with:
node-version: ${{ matrix.node-version }}
node-version: {% raw %}${{ matrix.node-version }}{% endraw %}
- run: npm ci
- run: npm run build --if-present
- run: npm test
```
{% endraw %}
{% data reusables.actions.example-github-runner %}
@@ -85,20 +83,18 @@ The starter workflow includes a matrix strategy that builds and tests your code
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 "[Contexts](/actions/learn-github-actions/contexts)."
{% raw %}
```yaml{:copy}
strategy:
matrix:
node-version: [10.x, 12.x, 14.x, 15.x]
steps:
- uses: actions/checkout@v2
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Use Node.js {% raw %}${{ matrix.node-version }}{% endraw %}
uses: {% data reusables.actions.action-setup-node %}
with:
node-version: ${{ matrix.node-version }}
node-version: {% raw %}${{ matrix.node-version }}{% endraw %}
```
{% endraw %}
Alternatively, you can build and test with exact Node.js versions.
@@ -110,7 +106,6 @@ strategy:
Or, you can build and test using a single version of Node.js too.
{% raw %}
```yaml{:copy}
name: Node.js CI
@@ -122,16 +117,15 @@ jobs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Use Node.js
uses: actions/setup-node@v2
uses: {% data reusables.actions.action-setup-node %}
with:
node-version: '12.x'
- run: npm ci
- run: npm run build --if-present
- run: npm test
```
{% endraw %}
If you don't specify a Node.js version, {% data variables.product.prodname_dotcom %} uses the environment's default Node.js version.
{% ifversion ghae %} {% data reusables.actions.self-hosted-runners-software %}
@@ -150,9 +144,9 @@ This example installs the dependencies defined in the *package.json* file. For m
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Use Node.js
uses: actions/setup-node@v2
uses: {% data reusables.actions.action-setup-node %}
with:
node-version: '12.x'
- name: Install dependencies
@@ -161,18 +155,16 @@ 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{:copy}
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Use Node.js
uses: actions/setup-node@v2
uses: {% data reusables.actions.action-setup-node %}
with:
node-version: '12.x'
- name: Install dependencies
run: npm ci
```
{% endraw %}
### Example using Yarn
@@ -180,9 +172,9 @@ This example installs the dependencies defined in the *package.json* file. For m
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Use Node.js
uses: actions/setup-node@v2
uses: {% data reusables.actions.action-setup-node %}
with:
node-version: '12.x'
- name: Install dependencies
@@ -193,9 +185,9 @@ Alternatively, you can pass `--frozen-lockfile` to install the versions in the `
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Use Node.js
uses: actions/setup-node@v2
uses: {% data reusables.actions.action-setup-node %}
with:
node-version: '12.x'
- name: Install dependencies
@@ -212,12 +204,11 @@ 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{:copy}
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Use Node.js
uses: actions/setup-node@v2
uses: {% data reusables.actions.action-setup-node %}
with:
always-auth: true
node-version: '12.x'
@@ -226,9 +217,8 @@ steps:
- name: Install dependencies
run: npm ci
env:
NODE_AUTH_TOKEN: ${{secrets.NPM_TOKEN}}
NODE_AUTH_TOKEN: {% raw %}${{ secrets.NPM_TOKEN }}{% endraw %}
```
{% endraw %}
The example above creates an *.npmrc* file with the following contents:
@@ -243,10 +233,11 @@ always-auth=true
When using {% data variables.product.prodname_dotcom %}-hosted runners, you can cache and restore the dependencies using the [`setup-node` action](https://github.com/actions/setup-node).
The following example caches dependencies for npm.
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v2
- uses: {% data reusables.actions.action-checkout %}
- uses: {% data reusables.actions.action-setup-node %}
with:
node-version: '14'
cache: 'npm'
@@ -258,8 +249,8 @@ The following example caches dependencies for Yarn.
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v2
- uses: {% data reusables.actions.action-checkout %}
- uses: {% data reusables.actions.action-setup-node %}
with:
node-version: '14'
cache: 'yarn'
@@ -275,11 +266,11 @@ The following example caches dependencies for pnpm (v6.10+).
# NOTE: pnpm caching support requires pnpm version >= 6.10.0
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- uses: pnpm/action-setup@646cdf48217256a3d0b80361c5a50727664284f2
with:
version: 6.10.0
- uses: actions/setup-node@v2
- uses: {% data reusables.actions.action-setup-node %}
with:
node-version: '14'
cache: 'pnpm'
@@ -295,9 +286,9 @@ You can use the same commands that you use locally to build and test your code.
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Use Node.js
uses: actions/setup-node@v2
uses: {% data reusables.actions.action-setup-node %}
with:
node-version: '12.x'
- run: npm install

34
content/actions/automating-builds-and-tests/building-and-testing-powershell.md
View File

@@ -47,7 +47,6 @@ To automate your testing with PowerShell and Pester, you can add a workflow that
This example workflow file must be added to your repository's `.github/workflows/` directory:
{% raw %}
```yaml
name: Test PowerShell on Ubuntu
on: push
@@ -58,7 +57,7 @@ jobs:
runs-on: ubuntu-latest
steps:
- name: Check out repository code
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
- name: Perform a Pester test from the command-line
shell: pwsh
run: Test-Path resultsfile.log | Should -Be $true
@@ -67,7 +66,6 @@ jobs:
run: |
Invoke-Pester Unit.Tests.ps1 -Passthru
```
{% endraw %}
* `shell: pwsh` - Configures the job to use PowerShell when running the `run` commands.
* `run: Test-Path resultsfile.log` - Check whether a file called `resultsfile.log` is present in the repository's root directory.
@@ -110,21 +108,19 @@ When using {% data variables.product.prodname_dotcom %}-hosted runners, you can
For example, the following job installs the `SqlServer` and `PSScriptAnalyzer` modules:
{% raw %}
```yaml
jobs:
install-dependencies:
name: Install dependencies
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Install from PSGallery
shell: pwsh
run: |
Set-PSRepository PSGallery -InstallationPolicy Trusted
Install-Module SqlServer, PSScriptAnalyzer
```
{% endraw %}
{% note %}
@@ -138,16 +134,15 @@ When using {% data variables.product.prodname_dotcom %}-hosted runners, you can
PowerShell caches its dependencies in different locations, depending on the runner's operating system. For example, the `path` location used in the following Ubuntu example will be different for a Windows operating system.
{% raw %}
```yaml
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Setup PowerShell module cache
id: cacher
uses: actions/cache@v2
uses: {% data reusables.actions.action-cache %}
with:
path: "~/.local/share/powershell/Modules"
key: ${{ runner.os }}-SqlServer-PSScriptAnalyzer
key: {% raw %}${{ runner.os }}-SqlServer-PSScriptAnalyzer{% endraw %}
- name: Install required PowerShell modules
if: steps.cacher.outputs.cache-hit != 'true'
shell: pwsh
@@ -155,7 +150,6 @@ steps:
Set-PSRepository PSGallery -InstallationPolicy Trusted
Install-Module SqlServer, PSScriptAnalyzer -ErrorAction Stop
```
{% endraw %}
## Testing your code
@@ -165,13 +159,12 @@ You can use the same commands that you use locally to build and test your code.
The following example installs `PSScriptAnalyzer` and uses it to lint all `ps1` files in the repository. For more information, see [PSScriptAnalyzer on GitHub](https://github.com/PowerShell/PSScriptAnalyzer).
{% raw %}
```yaml
lint-with-PSScriptAnalyzer:
name: Install and run PSScriptAnalyzer
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Install PSScriptAnalyzer module
shell: pwsh
run: |
@@ -189,7 +182,6 @@ The following example installs `PSScriptAnalyzer` and uses it to lint all `ps1`
Write-Output "There were $($errors.Count) errors and $($warnings.Count) warnings total."
}
```
{% endraw %}
## Packaging workflow data as artifacts
@@ -197,7 +189,6 @@ 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 the test results received from `Invoke-Pester`. For more information, see the [`upload-artifact` action](https://github.com/actions/upload-artifact).
{% raw %}
```yaml
name: Upload artifact from Ubuntu
@@ -208,18 +199,17 @@ jobs:
name: Run Pester and upload results
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Test with Pester
shell: pwsh
run: Invoke-Pester Unit.Tests.ps1 -Passthru | Export-CliXml -Path Unit.Tests.xml
- name: Upload test results
uses: actions/upload-artifact@v3
uses: {% data reusables.actions.action-upload-artifact %}
with:
name: ubuntu-Unit-Tests
path: Unit.Tests.xml
if: ${{ always() }}
if: {% raw %}${{ always() }}{% endraw %}
```
{% endraw %}
The `always()` function configures the job to continue processing even if there are test failures. For more information, see "[always](/actions/reference/context-and-expression-syntax-for-github-actions#always)."
@@ -229,7 +219,6 @@ You can configure your workflow to publish your PowerShell module to the PowerSh
The following example creates a package and uses `Publish-Module` to publish it to the PowerShell Gallery:
{% raw %}
```yaml
name: Publish PowerShell Module
@@ -241,13 +230,12 @@ jobs:
publish-to-gallery:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Build and publish
env:
NUGET_KEY: ${{ secrets.NUGET_KEY }}
NUGET_KEY: {% raw %}${{ secrets.NUGET_KEY }}{% endraw %}
shell: pwsh
run: |
./build.ps1 -Path /tmp/samplemodule
Publish-Module -Path /tmp/samplemodule -NuGetApiKey $env:NUGET_KEY -Verbose
```
{% endraw %}

92
content/actions/automating-builds-and-tests/building-and-testing-python.md
View File

@@ -48,7 +48,6 @@ We recommend that you have a basic understanding of Python, PyPy, and pip. For m
To get started quickly, add the starter workflow to the `.github/workflows` directory of your repository.
{% raw %}
```yaml{:copy}
name: Python package
@@ -63,11 +62,11 @@ jobs:
python-version: ["3.6", "3.7", "3.8", "3.9"]
steps:
- uses: actions/checkout@v2
- name: Set up Python ${{ matrix.python-version }}
uses: actions/setup-python@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Set up Python {% raw %}${{ matrix.python-version }}{% endraw %}
uses: {% data reusables.actions.action-setup-python %}
with:
python-version: ${{ matrix.python-version }}
python-version: {% raw %}${{ matrix.python-version }}{% endraw %}
- name: Install dependencies
run: |
python -m pip install --upgrade pip
@@ -83,7 +82,6 @@ jobs:
run: |
pytest
```
{% endraw %}
## Specifying a Python version
@@ -105,7 +103,6 @@ If you are using a self-hosted runner, you can configure the runner to use the `
### Using multiple Python versions
{% raw %}
```yaml{:copy}
name: Python package
@@ -117,27 +114,25 @@ jobs:
runs-on: ubuntu-latest
strategy:
# You can use PyPy versions in python-version.
# For example, pypy2 and pypy3
# For example, {% if actions-node16-action %}pypy-2.7 and pypy-3.8{% else %}pypy2 and pypy3{% endif %}
matrix:
python-version: ["2.7", "3.6", "3.7", "3.8", "3.9"]
steps:
- uses: actions/checkout@v2
- name: Set up Python ${{ matrix.python-version }}
uses: actions/setup-python@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Set up Python {% raw %}${{ matrix.python-version }}{% endraw %}
uses: {% data reusables.actions.action-setup-python %}
with:
python-version: ${{ matrix.python-version }}
python-version: {% raw %}${{ matrix.python-version }}{% endraw %}
# You can test your matrix by printing the current Python version
- name: Display Python version
run: python -c "import sys; print(sys.version)"
```
{% endraw %}
### Using a specific Python version
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{:copy}
name: Python package
@@ -149,9 +144,9 @@ jobs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Set up Python 3.x
uses: actions/setup-python@v2
uses: {% data reusables.actions.action-setup-python %}
with:
# Semantic version range syntax or exact version of a Python version
python-version: '3.x'
@@ -161,7 +156,6 @@ jobs:
- name: Display Python version
run: python -c "import sys; print(sys.version)"
```
{% endraw %}
### Excluding a version
@@ -169,7 +163,6 @@ 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{:copy}
name: Python package
@@ -178,18 +171,17 @@ on: [push]
jobs:
build:
runs-on: ${{ matrix.os }}
runs-on: {% raw %}${{ matrix.os }}{% endraw %}
strategy:
matrix:
os: [ubuntu-latest, macos-latest, windows-latest]
python-version: ["3.6", "3.7", "3.8", "3.9", pypy2, pypy3]
python-version: ["3.6", "3.7", "3.8", "3.9", {% if actions-node16-action %}pypy-2.7, pypy-3.8{% else %}pypy2, pypy3{% endif %}]
exclude:
- os: macos-latest
python-version: "3.6"
- os: windows-latest
python-version: "3.6"
```
{% endraw %}
### Using the default Python version
@@ -207,29 +199,26 @@ 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 "<a href="/actions/guides/caching-dependencies-to-speed-up-workflows" class="dotcom-only">Caching dependencies to speed up workflows</a>."
{% raw %}
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Set up Python
uses: actions/setup-python@v2
uses: {% data reusables.actions.action-setup-python %}
with:
python-version: '3.x'
- name: Install dependencies
run: python -m pip install --upgrade pip setuptools wheel
```
{% endraw %}
### Requirements file
After you update `pip`, a typical next step is to install dependencies from *requirements.txt*. For more information, see [pip](https://pip.pypa.io/en/stable/cli/pip_install/#example-requirements-file).
{% raw %}
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Set up Python
uses: actions/setup-python@v2
uses: {% data reusables.actions.action-setup-python %}
with:
python-version: '3.x'
- name: Install dependencies
@@ -237,7 +226,6 @@ steps:
python -m pip install --upgrade pip
pip install -r requirements.txt
```
{% endraw %}
### Caching Dependencies
@@ -247,8 +235,8 @@ The following example caches dependencies for pip.
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-python@v2
- uses: {% data reusables.actions.action-checkout %}
- uses: {% data reusables.actions.action-setup-python %}
with:
python-version: '3.9'
cache: 'pip'
@@ -268,12 +256,11 @@ 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{:copy}
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Set up Python
uses: actions/setup-python@v2
uses: {% data reusables.actions.action-setup-python %}
with:
python-version: '3.x'
- name: Install dependencies
@@ -286,18 +273,16 @@ steps:
pip install pytest-cov
pytest tests.py --doctest-modules --junitxml=junit/test-results.xml --cov=com --cov-report=xml --cov-report=html
```
{% endraw %}
### Using Flake8 to lint code
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{:copy}
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Set up Python
uses: actions/setup-python@v2
uses: {% data reusables.actions.action-setup-python %}
with:
python-version: '3.x'
- name: Install dependencies
@@ -310,7 +295,6 @@ steps:
flake8 .
continue-on-error: true
```
{% endraw %}
The linting step has `continue-on-error: true` set. This will keep the workflow from failing if the linting step doesn't succeed. Once you've addressed all of the linting errors, you can remove this option so the workflow will catch new issues.
@@ -318,7 +302,6 @@ The linting step has `continue-on-error: true` set. This will keep the workflow
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{:copy}
name: Python package
@@ -333,18 +316,17 @@ jobs:
python: ["3.7", "3.8", "3.9"]
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Setup Python
uses: actions/setup-python@v2
uses: {% data reusables.actions.action-setup-python %}
with:
python-version: ${{ matrix.python }}
python-version: {% raw %}${{ matrix.python }}{% endraw %}
- name: Install tox and any other packages
run: pip install tox
- name: Run tox
# Run tox using the version of Python in `PATH`
run: tox -e py
```
{% endraw %}
## Packaging workflow data as artifacts
@@ -352,7 +334,6 @@ 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{:copy}
name: Python package
@@ -367,27 +348,26 @@ jobs:
python-version: ["3.6", "3.7", "3.8", "3.9"]
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Setup Python # Set Python version
uses: actions/setup-python@v2
uses: {% data reusables.actions.action-setup-python %}
with:
python-version: ${{ matrix.python-version }}
python-version: {% raw %}${{ matrix.python-version }}{% endraw %}
# Install pip and pytest
- name: Install dependencies
run: |
python -m pip install --upgrade pip
pip install pytest
- name: Test with pytest
run: pytest tests.py --doctest-modules --junitxml=junit/test-results-${{ matrix.python-version }}.xml
run: pytest tests.py --doctest-modules {% raw %}--junitxml=junit/test-results-${{ matrix.python-version }}.xml{% endraw %}
- name: Upload pytest test results
uses: actions/upload-artifact@v3
uses: {% data reusables.actions.action-upload-artifact %}
with:
name: pytest-results-${{ matrix.python-version }}
path: junit/test-results-${{ matrix.python-version }}.xml
name: {% raw %}pytest-results-${{ matrix.python-version }}{% endraw %}
path: {% raw %}junit/test-results-${{ matrix.python-version }}.xml{% endraw %}
# Use always() to always run this step to publish test results when there are test failures
if: ${{ always() }}
if: {% raw %}${{ always() }}{% endraw %}
```
{% endraw %}
## Publishing to package registries
@@ -408,9 +388,9 @@ jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Set up Python
uses: actions/setup-python@v2
uses: {% data reusables.actions.action-setup-python %}
with:
python-version: '3.x'
- name: Install dependencies

38
content/actions/automating-builds-and-tests/building-and-testing-ruby.md
View File

@@ -52,7 +52,7 @@ jobs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Set up Ruby
uses: ruby/setup-ruby@359bebbc29cbe6c87da6bc9ea3bc930432750108
with:
@@ -71,17 +71,15 @@ Using Ruby's `ruby/setup-ruby` action is the recommended way of using Ruby with
The `setup-ruby` action takes a Ruby version as an input and configures that version on the runner.
{% raw %}
```yaml
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- uses: ruby/setup-ruby@359bebbc29cbe6c87da6bc9ea3bc930432750108
with:
ruby-version: '3.1' # Not needed with a .ruby-version file
- run: bundle install
- run: bundle exec rake
```
{% endraw %}
Alternatively, you can check a `.ruby-version` file into the root of your repository and `setup-ruby` will use the version defined in that file.
@@ -122,7 +120,7 @@ jobs:
ruby-version: ['3.1', '3.0', '2.7']
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: {% raw %}Set up Ruby ${{ matrix.ruby-version }}{% endraw %}
uses: ruby/setup-ruby@359bebbc29cbe6c87da6bc9ea3bc930432750108
with:
@@ -137,16 +135,14 @@ jobs:
The `setup-ruby` action will automatically install bundler for you. The version is determined by your `gemfile.lock` file. If no version is present in your lockfile, then the latest compatible version will be installed.
{% raw %}
```yaml
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- uses: ruby/setup-ruby@359bebbc29cbe6c87da6bc9ea3bc930432750108
with:
ruby-version: '3.1'
- run: bundle install
```
{% endraw %}
### Caching dependencies
@@ -169,39 +165,35 @@ This will configure bundler to install your gems to `vendor/cache`. For each suc
For greater control over caching, if you are using {% data variables.product.prodname_dotcom %}-hosted runners, you can use the `actions/cache` Action directly. For more information, see "<a href="/actions/guides/caching-dependencies-to-speed-up-workflows" class="dotcom-only">Caching dependencies to speed up workflows</a>."
{% raw %}
```yaml
steps:
- uses: actions/cache@v2
- uses: {% data reusables.actions.action-cache %}
with:
path: vendor/bundle
key: ${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }}
key: {% raw %}${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }}{% endraw %}
restore-keys: |
${{ runner.os }}-gems-
{% raw %}${{ runner.os }}-gems-{% endraw %}
- name: Bundle install
run: |
bundle config path vendor/bundle
bundle install --jobs 4 --retry 3
```
{% endraw %}
If you're using a matrix build, you will want to include the matrix variables in your cache key. For example, if you have a matrix strategy for different ruby versions (`matrix.ruby-version`) and different operating systems (`matrix.os`), your workflow steps might look like this:
{% raw %}
```yaml
steps:
- uses: actions/cache@v2
- uses: {% data reusables.actions.action-cache %}
with:
path: vendor/bundle
key: bundle-use-ruby-${{ matrix.os }}-${{ matrix.ruby-version }}-${{ hashFiles('**/Gemfile.lock') }}
key: {% raw %}bundle-use-ruby-${{ matrix.os }}-${{ matrix.ruby-version }}-${{ hashFiles('**/Gemfile.lock') }}{% endraw %}
restore-keys: |
bundle-use-ruby-${{ matrix.os }}-${{ matrix.ruby-version }}-
{% raw %}bundle-use-ruby-${{ matrix.os }}-${{ matrix.ruby-version }}-{% endraw %}
- name: Bundle install
run: |
bundle config path vendor/bundle
bundle install --jobs 4 --retry 3
```
{% endraw %}
## Matrix testing your code
@@ -228,7 +220,7 @@ jobs:
ruby: [2.5, 2.6, 2.7, head, debug, jruby, jruby-head, truffleruby, truffleruby-head]
continue-on-error: {% raw %}${{ endsWith(matrix.ruby, 'head') || matrix.ruby == 'debug' }}{% endraw %}
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- uses: ruby/setup-ruby@477b21f02be01bcb8030d50f37cfec92bfa615b6
with:
ruby-version: {% raw %}${{ matrix.ruby }}{% endraw %}
@@ -251,7 +243,7 @@ jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- uses: ruby/setup-ruby@477b21f02be01bcb8030d50f37cfec92bfa615b6
with:
ruby-version: 2.6
@@ -288,8 +280,8 @@ jobs:
packages: write
contents: read{% endif %}
steps:{% raw %}
- uses: actions/checkout@v2
steps:
- uses: {% data reusables.actions.action-checkout %}
- name: Set up Ruby 2.6
uses: ruby/setup-ruby@477b21f02be01bcb8030d50f37cfec92bfa615b6
with:
@@ -297,7 +289,7 @@ jobs:
- run: bundle install
- name: Publish to GPR
run: |
run: |{% raw %}
mkdir -p $HOME/.gem
touch $HOME/.gem/credentials
chmod 0600 $HOME/.gem/credentials

10
content/actions/automating-builds-and-tests/building-and-testing-swift.md
View File

@@ -37,7 +37,6 @@ We recommend that you have a basic understanding of Swift packages. For more inf
To get started quickly, add the starter workflow to the `.github/workflows` directory of your repository.
{% raw %}
```yaml{:copy}
name: Swift
@@ -49,13 +48,12 @@ jobs:
runs-on: macos-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Build
run: swift build
- name: Run tests
run: swift test
```
{% endraw %}
## Specifying a Swift version
@@ -88,7 +86,7 @@ jobs:
- uses: fwal/setup-swift@2040b795e5c453c3a05fcb8316496afc8a74f192
with:
swift-version: {% raw %}${{ matrix.swift }}{% endraw %}
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Build
run: swift build
- name: Run tests
@@ -114,10 +112,9 @@ steps:
You can use the same commands that you use locally to build and test your code using Swift. This example demonstrates how to use `swift build` and `swift test` in a job:
{% raw %}
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- uses: fwal/setup-swift@2040b795e5c453c3a05fcb8316496afc8a74f192
with:
swift-version: "5.3.3"
@@ -126,4 +123,3 @@ steps:
- name: Run tests
run: swift test
```
{% endraw %}

12
content/actions/automating-builds-and-tests/building-and-testing-xamarin-applications.md
View File

@@ -45,7 +45,6 @@ We recommend that you have a basic understanding of Xamarin, .NET Core SDK, YAML
The example below demonstrates how to change the default Xamarin SDK versions and build a Xamarin.iOS application.
{% raw %}
```yaml
name: Build Xamarin.iOS app
@@ -57,7 +56,7 @@ jobs:
runs-on: macos-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Set default Xamarin SDK versions
run: |
$VM_ASSETS/select-xamarin-sdk-v2.sh --mono=6.12 --ios=14.10
@@ -69,7 +68,7 @@ jobs:
sudo xcode-select -s $XCODE_ROOT
- name: Setup .NET Core SDK 5.0.x
uses: actions/setup-dotnet@v1
uses: {% data reusables.actions.action-setup-dotnet %}
with:
dotnet-version: '5.0.x'
@@ -79,13 +78,11 @@ jobs:
- name: Build
run: msbuild <csproj_file_path> /p:Configuration=Debug /p:Platform=iPhoneSimulator /t:Rebuild
```
{% endraw %}
## Building Xamarin.Android apps
The example below demonstrates how to change default Xamarin SDK versions and build a Xamarin.Android application.
{% raw %}
```yaml
name: Build Xamarin.Android app
@@ -97,13 +94,13 @@ jobs:
runs-on: macos-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Set default Xamarin SDK versions
run: |
$VM_ASSETS/select-xamarin-sdk-v2.sh --mono=6.10 --android=10.2
- name: Setup .NET Core SDK 5.0.x
uses: actions/setup-dotnet@v1
uses: {% data reusables.actions.action-setup-dotnet %}
with:
dotnet-version: '5.0.x'
@@ -113,7 +110,6 @@ jobs:
- name: Build
run: msbuild <csproj_file_path> /t:PackageForAndroid /p:Configuration=Debug
```
{% endraw %}
## Specifying a .NET version

6
content/actions/creating-actions/creating-a-composite-action.md
View File

@@ -117,7 +117,6 @@ The following workflow code uses the completed hello world action that you made
Copy the workflow code into a `.github/workflows/main.yml` file in another repository, but replace `actions/hello-world-composite-action@v1` with the repository and tag you created. You can also replace the `who-to-greet` input with your name.
{% raw %}
**.github/workflows/main.yml**
```yaml
on: [push]
@@ -127,14 +126,13 @@ jobs:
runs-on: ubuntu-latest
name: A job to say hello
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- id: foo
uses: actions/hello-world-composite-action@v1
with:
who-to-greet: 'Mona the Octocat'
- run: echo random-number ${{ steps.foo.outputs.random-number }}
- run: echo random-number {% raw %}${{ steps.foo.outputs.random-number }}{% endraw %}
shell: bash
```
{% endraw %}
From your repository, click the **Actions** tab, and select the latest workflow run. The output should include: "Hello Mona the Octocat", the result of the "Goodbye" script, and a random number.

6
content/actions/creating-actions/creating-a-docker-container-action.md
View File

@@ -212,7 +212,6 @@ jobs:
Copy the following example workflow code into a `.github/workflows/main.yml` file in your action's repository. You can also replace the `who-to-greet` input with your name. {% ifversion fpt or ghec %}This private action can't be published to {% data variables.product.prodname_marketplace %}, and can only be used in this repository.{% endif %}
{% raw %}
**.github/workflows/main.yml**
```yaml{:copy}
on: [push]
@@ -225,7 +224,7 @@ jobs:
# To use this repository's private action,
# you must check out the repository
- name: Checkout
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
- name: Hello world action step
uses: ./ # Uses an action in the root directory
id: hello
@@ -233,9 +232,8 @@ jobs:
who-to-greet: 'Mona the Octocat'
# Use the output from the `hello` step
- name: Get the output time
run: echo "The time was ${{ steps.hello.outputs.time }}"
run: echo "The time was {% raw %}${{ steps.hello.outputs.time }}"{% endraw %}
```
{% endraw %}
From your repository, click the **Actions** tab, and select the latest workflow run. Under **Jobs** or in the visualization graph, click **A job to say hello**. You should see "Hello Mona the Octocat" or the name you used for the `who-to-greet` input and the timestamp printed in the log.

6
content/actions/creating-actions/creating-a-javascript-action.md
View File

@@ -243,7 +243,6 @@ When this workflow is triggered, the runner will download the `hello-world-javas
Copy the workflow code into a `.github/workflows/main.yml` file in your action's repository. You can also replace the `who-to-greet` input with your name.
{% raw %}
**.github/workflows/main.yml**
```yaml{:copy}
on: [push]
@@ -256,7 +255,7 @@ jobs:
# To use this repository's private action,
# you must check out the repository
- name: Checkout
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
- name: Hello world action step
uses: ./ # Uses an action in the root directory
id: hello
@@ -264,9 +263,8 @@ jobs:
who-to-greet: 'Mona the Octocat'
# Use the output from the `hello` step
- name: Get the output time
run: echo "The time was ${{ steps.hello.outputs.time }}"
run: echo "The time was {% raw %}${{ steps.hello.outputs.time }}{% endraw %}"
```
{% endraw %}
From your repository, click the **Actions** tab, and select the latest workflow run. Under **Jobs** or in the visualization graph, click **A job to say hello**. You should see "Hello Mona the Octocat" or the name you used for the `who-to-greet` input and the timestamp printed in the log.

4
content/actions/creating-actions/metadata-syntax-for-github-actions.md
View File

@@ -333,9 +333,9 @@ runs:
# Reference a specific commit
- uses: actions/checkout@a81bbbf8298c0fa03ea29cdc473d45769f953675
# Reference the major version of a release
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
# Reference a specific version
- uses: actions/checkout@v2.2.0
- uses: {% data reusables.actions.action-checkout %}.2.0
# Reference a branch
- uses: actions/checkout@main
# References a subdirectory in a public GitHub repository at a specific branch, ref, or SHA

6
content/actions/deployment/deploying-to-your-cloud-provider/deploying-to-amazon-elastic-container-service.md
View File

@@ -116,11 +116,11 @@ jobs:
runs-on: ubuntu-latest
environment: production
{% raw %}steps:
steps:
- name: Checkout
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
- name: Configure AWS credentials
{% raw %}- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@13d241b293754004c80624b5567555c4a39ffbe3
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}

2
content/actions/deployment/deploying-to-your-cloud-provider/deploying-to-azure/deploying-docker-to-azure-app-service.md
View File

@@ -100,7 +100,7 @@ jobs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v1

8
content/actions/deployment/deploying-to-your-cloud-provider/deploying-to-azure/deploying-java-to-azure-app-service.md
View File

@@ -83,10 +83,10 @@ jobs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Set up Java version
uses: actions/setup-java@v2.3.1
uses: {% data reusables.actions.action-setup-java %}
with:
java-version: {% raw %}${{ env.JAVA_VERSION }}{% endraw %}
cache: 'maven'
@@ -95,7 +95,7 @@ jobs:
run: mvn clean install
- name: Upload artifact for deployment job
uses: actions/upload-artifact@v3
uses: {% data reusables.actions.action-upload-artifact %}
with:
name: java-app
path: '{% raw %}${{ github.workspace }}{% endraw %}/target/*.jar'
@@ -109,7 +109,7 @@ jobs:
steps:
- name: Download artifact from build job
uses: actions/download-artifact@v3
uses: {% data reusables.actions.action-download-artifact %}
with:
name: java-app

10
content/actions/deployment/deploying-to-your-cloud-provider/deploying-to-azure/deploying-net-to-azure-app-service.md
View File

@@ -83,15 +83,15 @@ jobs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Set up .NET Core
uses: actions/setup-dotnet@v1
uses: {% data reusables.actions.action-setup-dotnet %}
with:
dotnet-version: {% raw %}${{ env.DOTNET_VERSION }}{% endraw %}
- name: Set up dependency caching for faster builds
uses: actions/cache@v2
uses: {% data reusables.actions.action-cache %}
with:
path: ~/.nuget/packages
key: {% raw %}${{ runner.os }}-nuget-${{ hashFiles('**/packages.lock.json') }}{% endraw %}
@@ -105,7 +105,7 @@ jobs:
run: dotnet publish -c Release -o {% raw %}${{env.DOTNET_ROOT}}{% endraw %}/myapp
- name: Upload artifact for deployment job
uses: actions/upload-artifact@v3
uses: {% data reusables.actions.action-upload-artifact %}
with:
name: .net-app
path: {% raw %}${{env.DOTNET_ROOT}}{% endraw %}/myapp
@@ -119,7 +119,7 @@ jobs:
steps:
- name: Download artifact from build job
uses: actions/download-artifact@v3
uses: {% data reusables.actions.action-download-artifact %}
with:
name: .net-app

8
content/actions/deployment/deploying-to-your-cloud-provider/deploying-to-azure/deploying-nodejs-to-azure-app-service.md
View File

@@ -86,10 +86,10 @@ jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Set up Node.js
uses: actions/setup-node@v2
uses: {% data reusables.actions.action-setup-node %}
with:
node-version: {% raw %}${{ env.NODE_VERSION }}{% endraw %}
cache: 'npm'
@@ -100,7 +100,7 @@ jobs:
npm run build --if-present
npm run test --if-present
- name: Upload artifact for deployment job
uses: actions/upload-artifact@v3
uses: {% data reusables.actions.action-upload-artifact %}
with:
name: node-app
path: .
@@ -114,7 +114,7 @@ jobs:
steps:
- name: Download artifact from build job
uses: actions/download-artifact@v3
uses: {% data reusables.actions.action-download-artifact %}
with:
name: node-app

8
content/actions/deployment/deploying-to-your-cloud-provider/deploying-to-azure/deploying-php-to-azure-app-service.md
View File

@@ -83,7 +83,7 @@ jobs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Setup PHP
uses: shivammathur/setup-php@v2
@@ -103,7 +103,7 @@ jobs:
echo "::set-output name=dir::$(composer config cache-files-dir)"
- name: Set up dependency caching for faster installs
uses: actions/cache@v2
uses: {% data reusables.actions.action-cache %}
if: steps.check_files.outputs.files_exists == 'true'
with:
path: {% raw %}${{ steps.composer-cache.outputs.dir }}{% endraw %}
@@ -116,7 +116,7 @@ jobs:
run: composer validate --no-check-publish && composer install --prefer-dist --no-progress
- name: Upload artifact for deployment job
uses: actions/upload-artifact@v3
uses: {% data reusables.actions.action-upload-artifact %}
with:
name: php-app
path: .
@@ -130,7 +130,7 @@ jobs:
steps:
- name: Download artifact from build job
uses: actions/download-artifact@v3
uses: {% data reusables.actions.action-download-artifact %}
with:
name: php-app

12
content/actions/deployment/deploying-to-your-cloud-provider/deploying-to-azure/deploying-python-to-azure-app-service.md
View File

@@ -85,10 +85,10 @@ jobs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Set up Python version
uses: actions/setup-python@v2.2.2
uses: {% data reusables.actions.action-setup-python %}
with:
python-version: {% raw %}${{ env.PYTHON_VERSION }}{% endraw %}
@@ -98,7 +98,7 @@ jobs:
source venv/bin/activate
- name: Set up dependency caching for faster installs
uses: actions/cache@v2
uses: {% data reusables.actions.action-cache %}
with:
path: ~/.cache/pip
key: {% raw %}${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }}{% endraw %}
@@ -111,11 +111,11 @@ jobs:
# Optional: Add a step to run tests here (PyTest, Django test suites, etc.)
- name: Upload artifact for deployment jobs
uses: actions/upload-artifact@v3
uses: {% data reusables.actions.action-upload-artifact %}
with:
name: python-app
path: |
.
.
!venv/
deploy:
runs-on: ubuntu-latest
@@ -126,7 +126,7 @@ jobs:
steps:
- name: Download artifact from build job
uses: actions/download-artifact@v3
uses: {% data reusables.actions.action-download-artifact %}
with:
name: python-app
path: .

2
content/actions/deployment/deploying-to-your-cloud-provider/deploying-to-azure/deploying-to-azure-kubernetes-service.md
View File

@@ -73,7 +73,7 @@ jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@master
- uses: {% data reusables.actions.action-checkout %}
- name: Azure Login
uses: azure/login@89d153571fe9a34ed70fcf9f1d95ab8debea7a73

2
content/actions/deployment/deploying-to-your-cloud-provider/deploying-to-azure/deploying-to-azure-static-web-app.md
View File

@@ -79,7 +79,7 @@ jobs:
runs-on: ubuntu-latest
name: Build and Deploy
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
with:
submodules: true
- name: Build And Deploy

2
content/actions/deployment/deploying-to-your-cloud-provider/deploying-to-google-kubernetes-engine.md
View File

@@ -159,7 +159,7 @@ jobs:
steps:
- name: Checkout
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
# Setup gcloud CLI
- uses: google-github-actions/setup-gcloud@94337306dda8180d967a56932ceb4ddcf01edae7

12
content/actions/deployment/deploying-xcode-applications/installing-an-apple-certificate-on-macos-runners-for-xcode-development.md
View File

@@ -74,7 +74,6 @@ Create secrets in your repository or organization for the following items:
This example workflow includes a step that imports the Apple certificate and provisioning profile from the {% data variables.product.prodname_dotcom %} secrets, and installs them on the runner.
{% raw %}
```yaml{:copy}
name: App build
on: push
@@ -85,13 +84,13 @@ jobs:
steps:
- name: Checkout repository
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
- name: Install the Apple certificate and provisioning profile
env:
BUILD_CERTIFICATE_BASE64: ${{ secrets.BUILD_CERTIFICATE_BASE64 }}
P12_PASSWORD: ${{ secrets.P12_PASSWORD }}
BUILD_PROVISION_PROFILE_BASE64: ${{ secrets.BUILD_PROVISION_PROFILE_BASE64 }}
KEYCHAIN_PASSWORD: ${{ secrets.KEYCHAIN_PASSWORD }}
BUILD_CERTIFICATE_BASE64: {% raw %}${{ secrets.BUILD_CERTIFICATE_BASE64 }}{% endraw %}
P12_PASSWORD: {% raw %}${{ secrets.P12_PASSWORD }}{% endraw %}
BUILD_PROVISION_PROFILE_BASE64: {% raw %}${{ secrets.BUILD_PROVISION_PROFILE_BASE64 }}{% endraw %}
KEYCHAIN_PASSWORD: {% raw %}${{ secrets.KEYCHAIN_PASSWORD }}{% endraw %}
run: |
# create variables
CERTIFICATE_PATH=$RUNNER_TEMP/build_certificate.p12
@@ -117,7 +116,6 @@ jobs:
- name: Build app
...
```
{% endraw %}
## Required clean-up on self-hosted runners

4
content/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services.md
View File

@@ -79,13 +79,13 @@ env:
# permission can be added at job level or workflow level
permissions:
id-token: write
contents: read # This is required for actions/checkout@v2
contents: read # This is required for actions/checkout
jobs:
S3PackageUpload:
runs-on: ubuntu-latest
steps:
- name: Git clone the repository
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
- name: configure aws credentials
uses: aws-actions/configure-aws-credentials@v1
with:

4
content/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-cloud-providers.md
View File

@@ -68,7 +68,7 @@ jobs:
- name: Install OIDC Client from Core Package
run: npm install @actions/core@1.6.0 @actions/http-client
- name: Get Id Token
uses: actions/github-script@v4
uses: {% data reusables.actions.action-github-script %}
id: idtoken
with:
script: |
@@ -90,7 +90,7 @@ jobs:
job:
runs-on: ubuntu-latest
steps:
- uses: actions/github-script@v4
- uses: {% data reusables.actions.action-github-script %}
id: script
timeout-minutes: 10
with:

66
content/actions/learn-github-actions/contexts.md
View File

@@ -272,7 +272,7 @@ jobs:
normal_ci:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Run normal CI
run: ./run-tests
@@ -280,7 +280,7 @@ jobs:
runs-on: ubuntu-latest
if: {% raw %}${{ github.event_name == 'pull_request' }}{% endraw %}
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Run PR CI
run: ./run-additional-pr-ci
```
@@ -382,7 +382,6 @@ This example `job` context uses a PostgreSQL service container with mapped ports
This example workflow configures a PostgreSQL service container, and automatically maps port 5432 in the service container to a randomly chosen available port on the host. The `job` context is used to access the number of the port that was assigned on the host.
{% raw %}
```yaml{:copy}
name: PostgreSQL Service Example
on: push
@@ -400,11 +399,10 @@ jobs:
- 5432
steps:
- uses: actions/checkout@v2
- run: pg_isready -h localhost -p ${{ job.services.postgres.ports[5432] }}
- uses: {% data reusables.actions.action-checkout %}
- run: pg_isready -h localhost -p {% raw %}${{ job.services.postgres.ports[5432] }}{% endraw %}
- run: ./run-tests
```
{% endraw %}
## `steps` context
@@ -443,7 +441,6 @@ This example `steps` context shows two previous steps that had an [`id`](/action
This example workflow generates a random number as an output in one step, and a later step uses the `steps` context to read the value of that output.
{% raw %}
```yaml{:copy}
name: Generate random failure
on: push
@@ -452,15 +449,14 @@ jobs:
runs-on: ubuntu-latest
steps:
- id: checkout
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
- name: Generate 0 or 1
id: generate_number
run: echo "::set-output name=random_number::$(($RANDOM % 2))"
- name: Pass or fail
run: |
if [[ ${{ steps.generate_number.outputs.random_number }} == 0 ]]; then exit 0; else exit 1; fi
if [[ {% raw %}${{ steps.generate_number.outputs.random_number }}{% endraw %} == 0 ]]; then exit 0; else exit 1; fi
```
{% endraw %}
## `runner` context
@@ -501,7 +497,6 @@ The following example context is from a Linux {% data variables.product.prodname
This example workflow uses the `runner` context to set the path to the temporary directory to write logs, and if the workflow fails, it uploads those logs as artifact.
{% raw %}
```yaml{:copy}
name: Build
on: push
@@ -510,19 +505,18 @@ jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Build with logs
run: |
mkdir ${{ runner.temp }}/build_logs
./build.sh --log-path ${{ runner.temp }}/build_logs
mkdir {% raw %}${{ runner.temp }}{% endraw %}/build_logs
./build.sh --log-path {% raw %}${{ runner.temp }}{% endraw %}/build_logs
- name: Upload logs on fail
if: ${{ failure() }}
uses: actions/upload-artifact@v3
if: {% raw %}${{ failure() }}{% endraw %}
uses: {% data reusables.actions.action-upload-artifact %}
with:
name: Build failure logs
path: ${{ runner.temp }}/build_logs
path: {% raw %}${{ runner.temp }}{% endraw %}/build_logs
```
{% endraw %}
## `secrets` context
@@ -583,7 +577,6 @@ The following example contents of the `strategy` context is from a build matrix
This example workflow uses the `strategy.job-index` property to set a unique name for a log file for each job in a build matrix.
{% raw %}
```yaml{:copy}
name: Test matrix
on: push
@@ -596,15 +589,14 @@ jobs:
test-group: [1, 2]
node: [14, 16]
steps:
- uses: actions/checkout@v2
- run: npm test > test-job-${{ strategy.job-index }}.txt
- uses: {% data reusables.actions.action-checkout %}
- run: npm test > test-job-{% raw %}${{ strategy.job-index }}{% endraw %}.txt
- name: Upload logs
uses: actions/upload-artifact@v3
uses: {% data reusables.actions.action-upload-artifact %}
with:
name: Build log for job ${{ strategy.job-index }}
path: test-job-${{ strategy.job-index }}.txt
name: Build log for job {% raw %}${{ strategy.job-index }}{% endraw %}
path: test-job-{% raw %}${{ strategy.job-index }}{% endraw %}.txt
```
{% endraw %}
## `matrix` context
@@ -632,29 +624,27 @@ The following example contents of the `matrix` context is from a job in a build
This example workflow creates a build matrix with `os` and `node` keys. It uses the `matrix.os` property to set the runner type for each job, and uses the `matrix.node` property to set the Node.js version for each job.
{% raw %}
```yaml{:copy}
name: Test matrix
on: push
jobs:
build:
runs-on: ${{ matrix.os }}
runs-on: {% raw %}${{ matrix.os }}{% endraw %}
strategy:
matrix:
os: [ubuntu-latest, windows-latest]
node: [14, 16]
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v2
- uses: {% data reusables.actions.action-checkout %}
- uses: {% data reusables.actions.action-setup-node %}
with:
node-version: ${{ matrix.node }}
node-version: {% raw %}${{ matrix.node }}{% endraw %}
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
```
{% endraw %}
## `needs` context
@@ -691,7 +681,6 @@ The following example contents of the `needs` context shows information for two
This example workflow has three jobs: a `build` job that does a build, a `deploy` job that requires the `build` job, and a `debug` job that requires both the `build` and `deploy` jobs and runs only if there is a failure in the workflow. The `deploy` job also uses the `needs` context to access an output from the `build` job.
{% raw %}
```yaml{:copy}
name: Build and deploy
on: push
@@ -700,9 +689,9 @@ jobs:
build:
runs-on: ubuntu-latest
outputs:
build_id: ${{ steps.build_step.outputs.build_id }}
build_id: {% raw %}${{ steps.build_step.outputs.build_id }}{% endraw %}
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Build
id: build_step
run: |
@@ -712,17 +701,16 @@ jobs:
needs: build
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- run: ./deploy --build ${{ needs.build.outputs.build_id }}
- uses: {% data reusables.actions.action-checkout %}
- run: ./deploy --build {% raw %}${{ needs.build.outputs.build_id }}{% endraw %}
debug:
needs: [build, deploy]
runs-on: ubuntu-latest
if: ${{ failure() }}
if: {% raw %}${{ failure() }}{% endraw %}
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- run: ./debug
```
{% endraw %}
{% ifversion fpt or ghec or ghes > 3.3 or ghae-issue-4757 %}
## `inputs` context

4
content/actions/learn-github-actions/essential-features-of-github-actions.md
View File

@@ -75,7 +75,7 @@ jobs:
run: |
expr 1 + 1 > output.log
- name: Upload output file
uses: actions/upload-artifact@v3
uses: {% data reusables.actions.action-upload-artifact %}
with:
name: output-log-file
path: output.log
@@ -88,7 +88,7 @@ jobs:
example-job:
steps:
- name: Download a single artifact
uses: actions/download-artifact@v3
uses: {% data reusables.actions.action-download-artifact %}
with:
name: output-log-file
```

4
content/actions/learn-github-actions/finding-and-customizing-actions.md
View File

@@ -99,7 +99,7 @@ jobs:
runs-on: ubuntu-latest
steps:
# This step checks out a copy of your repository.
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
# This step references the directory that contains the action.
- uses: ./.github/actions/hello-world-action
```
@@ -117,7 +117,7 @@ jobs:
my_first_job:
steps:
- name: My first step
uses: actions/setup-node@v1.1.0
uses: {% data reusables.actions.action-setup-node %}
```
### Referencing a container on Docker Hub

35
content/actions/learn-github-actions/understanding-github-actions.md
View File

@@ -94,20 +94,21 @@ You can create an example workflow in your repository that automatically trigger
1. In your repository, create the `.github/workflows/` directory to store your workflow files.
1. In the `.github/workflows/` directory, create a new file called `learn-github-actions.yml` and add the following code.
```yaml
name: learn-github-actions
on: [push]
jobs:
check-bats-version:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v2
with:
node-version: '14'
- run: npm install -g bats
- run: bats -v
```
```yaml
name: learn-github-actions
on: [push]
jobs:
check-bats-version:
runs-on: ubuntu-latest
steps:
- uses: {% data reusables.actions.action-checkout %}
- uses: {% data reusables.actions.action-setup-node %}
with:
node-version: '14'
- run: npm install -g bats
- run: bats -v
```
1. Commit these changes and push them to your {% data variables.product.prodname_dotcom %} repository.
Your new {% data variables.product.prodname_actions %} workflow file is now installed in your repository and will run automatically each time someone pushes a change to the repository. For details about a job's execution history, see "[Viewing the workflow's activity](/actions/learn-github-actions/introduction-to-github-actions#viewing-the-jobs-activity)."
@@ -187,7 +188,7 @@ Defines a job named <code>check-bats-version</code>. The child keys will define
<td>
```yaml
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
```
</td>
<td>
@@ -198,13 +199,13 @@ The <code>uses</code> keyword specifies that this step will run <code>v2</code>
<td>
```yaml
- uses: actions/setup-node@v2
- uses: {% data reusables.actions.action-setup-node %}
with:
node-version: '14'
```
</td>
<td>
This step uses the <code>actions/setup-node@v2</code> action to install the specified version of the Node.js (this example uses v14). This puts both the <code>node</code> and <code>npm</code> commands in your <code>PATH</code>.
This step uses the <code>{% data reusables.actions.action-setup-node %}</code> action to install the specified version of the Node.js (this example uses v14). This puts both the <code>node</code> and <code>npm</code> commands in your <code>PATH</code>.
</td>
</tr>
<tr>

2
content/actions/managing-issues-and-pull-requests/closing-inactive-issues.md
View File

@@ -42,7 +42,7 @@ In the tutorial, you will first make a workflow file that uses the [`actions/sta
issues: write
pull-requests: write{% endif %}
steps:
- uses: actions/stale@v3
- uses: {% data reusables.actions.action-stale %}
with:
days-before-issue-stale: 30
days-before-issue-close: 14

6
content/actions/migrating-to-github-actions/migrating-from-azure-pipelines-to-github-actions.md
View File

@@ -315,19 +315,19 @@ jobs:
{% endraw %}
</td>
<td class="d-table-cell v-align-top">
{% raw %}
```yaml
jobs:
run_python:
runs-on: ubuntu-latest
steps:
- uses: actions/setup-python@v2
- uses: {% data reusables.actions.action-setup-python %}
with:
python-version: '3.7'
architecture: 'x64'
- run: python script.py
```
{% endraw %}
</td>
</tr>
</table>

34
content/actions/migrating-to-github-actions/migrating-from-circleci-to-github-actions.md
View File

@@ -104,16 +104,16 @@ GitHub Actions
{% endraw %}
</td>
<td class="d-table-cell v-align-top">
{% raw %}
```yaml
- name: Cache node modules
uses: actions/cache@v2
uses: {% data reusables.actions.action-cache %}
with:
path: ~/.npm
key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}
key: {% raw %}v1-npm-deps-${{ hashFiles('**/package-lock.json') }}{% endraw %}
restore-keys: v1-npm-deps-
```
{% endraw %}
</td>
</tr>
</table>
@@ -154,10 +154,10 @@ GitHub Actions
{% endraw %}
</td>
<td class="d-table-cell v-align-top">
{% raw %}
```yaml
- name: Upload math result for job 1
uses: actions/upload-artifact@v3
uses: {% data reusables.actions.action-upload-artifact %}
with:
name: homework
path: math-homework.txt
@@ -165,11 +165,11 @@ GitHub Actions
...
- name: Download math result for job 1
uses: actions/download-artifact@v3
uses: {% data reusables.actions.action-download-artifact %}
with:
name: homework
```
{% endraw %}
</td>
</tr>
</table>
@@ -249,7 +249,7 @@ workflows:
{% endraw %}
</td>
<td class="d-table-cell v-align-top">
{% raw %}
```yaml
name: Containers
@@ -283,7 +283,7 @@ jobs:
# See https://docs.github.com/actions/reference/virtual-environments-for-github-hosted-runners#docker-container-filesystem
- name: Setup file system permissions
run: sudo chmod -R 777 $GITHUB_WORKSPACE /github /__w/_temp
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Install dependencies
run: bundle install --path vendor/bundle
- name: Setup environment configuration
@@ -293,7 +293,6 @@ jobs:
- name: Run tests
run: bundle exec rake
```
{% endraw %}
</td>
</tr>
</table>
@@ -400,9 +399,9 @@ workflows:
{% endraw %}
</td>
<td class="d-table-cell v-align-top">
{% raw %}
```yaml
{% endraw %}{% data reusables.actions.actions-not-certified-by-github-comment %}{% raw %}
{% data reusables.actions.actions-not-certified-by-github-comment %}
name: Containers
@@ -435,16 +434,16 @@ jobs:
options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Setup Ruby
uses: eregon/use-ruby-action@477b21f02be01bcb8030d50f37cfec92bfa615b6
with:
ruby-version: ${{ matrix.ruby }}
ruby-version: {% raw %}${{ matrix.ruby }}{% endraw %}
- name: Cache dependencies
uses: actions/cache@v2
uses: {% data reusables.actions.action-cache %}
with:
path: vendor/bundle
key: administrate-${{ matrix.image }}-${{ hashFiles('Gemfile.lock') }}
key: administrate-{% raw %}${{ matrix.image }}-${{ hashFiles('Gemfile.lock') }}{% endraw %}
- name: Install postgres headers
run: |
sudo apt-get update
@@ -462,7 +461,6 @@ jobs:
- name: Run appraisal
run: bundle exec appraisal rake
```
{% endraw %}
</td>
</tr>
</table>

26
content/actions/migrating-to-github-actions/migrating-from-gitlab-cicd-to-github-actions.md
View File

@@ -65,15 +65,15 @@ job1:
{% endraw %}
</td>
<td class="d-table-cell v-align-top">
{% raw %}
```yaml
jobs:
job1:
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- run: echo "Run your script here"
```
{% endraw %}
</td>
</tr>
</table>
@@ -341,20 +341,20 @@ test_async:
{% endraw %}
</td>
<td class="d-table-cell v-align-top">
{% raw %}
```yaml
jobs:
test_async:
runs-on: ubuntu-latest
steps:
- name: Cache node modules
uses: actions/cache@v2
uses: {% data reusables.actions.action-cache %}
with:
path: ~/.npm
key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}
key: {% raw %}v1-npm-deps-${{ hashFiles('**/package-lock.json') }}{% endraw %}
restore-keys: v1-npm-deps-
```
{% endraw %}
</td>
</tr>
</table>
@@ -388,15 +388,15 @@ artifacts:
{% endraw %}
</td>
<td class="d-table-cell v-align-top">
{% raw %}
```yaml
- name: Upload math result for job 1
uses: actions/upload-artifact@v3
uses: {% data reusables.actions.action-upload-artifact %}
with:
name: homework
path: math-homework.txt
```
{% endraw %}
</td>
</tr>
</table>
@@ -448,7 +448,7 @@ container-job:
{% endraw %}
</td>
<td class="d-table-cell v-align-top">
{% raw %}
```yaml
jobs:
container-job:
@@ -463,7 +463,7 @@ jobs:
steps:
- name: Check out repository code
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
# Performs a clean installation of all dependencies
# in the `package.json` file
@@ -481,7 +481,7 @@ jobs:
# The default PostgreSQL port
POSTGRES_PORT: 5432
```
{% endraw %}
</td>
</tr>
</table>

8
content/actions/migrating-to-github-actions/migrating-from-jenkins-to-github-actions.md
View File

@@ -263,28 +263,26 @@ pipeline {
</td>
<td>
{% raw %}
```yaml
name: demo-workflow
on:
push:
jobs:
test:
runs-on: ${{ matrix.os }}
runs-on: {% raw %}${{ matrix.os }}{% endraw %}
strategy:
fail-fast: false
matrix:
os: [macos-latest, ubuntu-latest]
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v2
- uses: {% data reusables.actions.action-checkout %}
- uses: {% data reusables.actions.action-setup-node %}
with:
node-version: 12
- run: npm install -g bats
- run: bats tests
working-directory: scripts/myapp
```
{% endraw %}
</td>
</tr>

28
content/actions/migrating-to-github-actions/migrating-from-travis-ci-to-github-actions.md
View File

@@ -165,13 +165,13 @@ git:
{% endraw %}
</td>
<td class="d-table-cell v-align-top">
{% raw %}
```yaml
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
with:
submodules: false
```
{% endraw %}
</td>
</tr>
</table>
@@ -284,19 +284,19 @@ script:
{% endraw %}
</td>
<td class="d-table-cell v-align-top">
{% raw %}
```yaml
jobs:
run_python:
runs-on: ubuntu-latest
steps:
- uses: actions/setup-python@v2
- uses: {% data reusables.actions.action-setup-python %}
with:
python-version: '3.7'
architecture: 'x64'
- run: python script.py
```
{% endraw %}
</td>
</tr>
</table>
@@ -324,16 +324,16 @@ cache: npm
{% endraw %}
</td>
<td class="d-table-cell v-align-top">
{% raw %}
```yaml
- name: Cache node modules
uses: actions/cache@v2
uses: {% data reusables.actions.action-cache %}
with:
path: ~/.npm
key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}
key: {% raw %}v1-npm-deps-${{ hashFiles('**/package-lock.json') }}{% endraw %}
restore-keys: v1-npm-deps-
```
{% endraw %}
</td>
</tr>
</table>
@@ -403,7 +403,7 @@ script:
{% endraw %}
</td>
<td>
{% raw %}
```yaml
name: Node.js CI
on: [push]
@@ -411,16 +411,16 @@ jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Use Node.js
uses: actions/setup-node@v2
uses: {% data reusables.actions.action-setup-node %}
with:
node-version: '12.x'
- run: npm install
- run: npm run build
- run: npm test
```
{% endraw %}
</td>
</tr>
</table>

6
content/actions/publishing-packages/publishing-docker-images.md
View File

@@ -81,7 +81,7 @@ jobs:
runs-on: ubuntu-latest
steps:
- name: Check out the repo
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
- name: Log in to Docker Hub
uses: docker/login-action@f054a8b539a109f9f41c372932f1ae047eff08c9
@@ -151,7 +151,7 @@ jobs:
contents: read{% endif %}
steps:
- name: Check out the repo
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
- name: Log in to GitHub Docker Registry
uses: docker/login-action@f054a8b539a109f9f41c372932f1ae047eff08c9
@@ -197,7 +197,7 @@ jobs:
contents: read{% endif %}
steps:
- name: Check out the repo
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
- name: Log in to Docker Hub
uses: docker/login-action@f054a8b539a109f9f41c372932f1ae047eff08c9

18
content/actions/publishing-packages/publishing-java-packages-with-gradle.md
View File

@@ -87,16 +87,16 @@ jobs:
publish:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Set up Java
uses: actions/setup-java@v2
uses: {% data reusables.actions.action-setup-java %}
with:
java-version: '11'
distribution: 'adopt'
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b
- name: Publish package
uses: gradle/gradle-build-action@937999e9cc2425eddc7fd62d1053baf041147db7
uses: gradle/gradle-build-action@0d13054264b0bb894ded474f08ebb30921341cee
with:
arguments: publish
env:
@@ -159,15 +159,15 @@ jobs:
contents: read
packages: write {% endif %}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v2
- uses: {% data reusables.actions.action-checkout %}
- uses: {% data reusables.actions.action-setup-java %}
with:
java-version: '11'
distribution: 'adopt'
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b
- name: Publish package
uses: gradle/gradle-build-action@937999e9cc2425eddc7fd62d1053baf041147db7
uses: gradle/gradle-build-action@0d13054264b0bb894ded474f08ebb30921341cee
with:
arguments: publish
env:
@@ -237,16 +237,16 @@ jobs:
contents: read
packages: write {% endif %}
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Set up Java
uses: actions/setup-java@v2
uses: {% data reusables.actions.action-setup-java %}
with:
java-version: '11'
distribution: 'adopt'
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b
- name: Publish package
uses: gradle/gradle-build-action@937999e9cc2425eddc7fd62d1053baf041147db7
uses: gradle/gradle-build-action@0d13054264b0bb894ded474f08ebb30921341cee
with:
arguments: publish
env: {% raw %}

28
content/actions/publishing-packages/publishing-java-packages-with-maven.md
View File

@@ -74,7 +74,6 @@ With this configuration, you can create a workflow that publishes your package t
In the deploy step, you’ll need to set the environment variables to the username that you authenticate with to the repository, and to a secret that you’ve configured with the password or token to authenticate with. For more information, see "[Creating and using encrypted secrets](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
{% raw %}
```yaml{:copy}
name: Publish package to the Maven Central Repository
on:
@@ -84,9 +83,9 @@ jobs:
publish:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Set up Maven Central Repository
uses: actions/setup-java@v2
uses: {% data reusables.actions.action-setup-java %}
with:
java-version: '11'
distribution: 'adopt'
@@ -96,10 +95,9 @@ jobs:
- name: Publish package
run: mvn --batch-mode deploy
env:
MAVEN_USERNAME: ${{ secrets.OSSRH_USERNAME }}
MAVEN_PASSWORD: ${{ secrets.OSSRH_TOKEN }}
MAVEN_USERNAME: {% raw %}${{ secrets.OSSRH_USERNAME }}{% endraw %}
MAVEN_PASSWORD: {% raw %}${{ secrets.OSSRH_TOKEN }}{% endraw %}
```
{% endraw %}
This workflow performs the following steps:
@@ -150,8 +148,8 @@ jobs:
contents: read
packages: write {% endif %}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v2
- uses: {% data reusables.actions.action-checkout %}
- uses: {% data reusables.actions.action-setup-java %}
with:
java-version: '11'
distribution: 'adopt'
@@ -187,9 +185,9 @@ jobs:
contents: read
packages: write {% endif %}
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Set up Java for publishing to Maven Central Repository
uses: actions/setup-java@v2
uses: {% data reusables.actions.action-setup-java %}
with:
java-version: '11'
distribution: 'adopt'
@@ -198,18 +196,18 @@ jobs:
server-password: MAVEN_PASSWORD
- name: Publish to the Maven Central Repository
run: mvn --batch-mode deploy
env:{% raw %}
MAVEN_USERNAME: ${{ secrets.OSSRH_USERNAME }}
MAVEN_PASSWORD: ${{ secrets.OSSRH_TOKEN }}
env:
MAVEN_USERNAME: {% raw %}${{ secrets.OSSRH_USERNAME }}{% endraw %}
MAVEN_PASSWORD: {% raw %}${{ secrets.OSSRH_TOKEN }}{% endraw %}
- name: Set up Java for publishing to GitHub Packages
uses: actions/setup-java@v2
uses: {% data reusables.actions.action-setup-java %}
with:
java-version: '11'
distribution: 'adopt'
- name: Publish to GitHub Packages
run: mvn --batch-mode deploy
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}{% endraw %}
GITHUB_TOKEN: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
```
This workflow calls the `setup-java` action twice. Each time the `setup-java` action runs, it overwrites the Maven _settings.xml_ file for publishing packages. For authentication to the repository, the _settings.xml_ file references the distribution management repository `id`, and the username and password.

20
content/actions/publishing-packages/publishing-nodejs-packages.md
View File

@@ -61,7 +61,6 @@ 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{:copy}
name: Publish Package to npmjs
on:
@@ -71,18 +70,17 @@ jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
# Setup .npmrc file to publish to npm
- uses: actions/setup-node@v2
- uses: {% data reusables.actions.action-setup-node %}
with:
node-version: '16.x'
registry-url: 'https://registry.npmjs.org'
- run: npm ci
- run: npm publish
env:
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
NODE_AUTH_TOKEN: {% raw %}${{ secrets.NPM_TOKEN }}{% endraw %}
```
{% endraw %}
In the example above, the `setup-node` action creates an *.npmrc* file on the runner with the following contents:
@@ -135,9 +133,9 @@ jobs:
contents: read
packages: write {% endif %}
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
# Setup .npmrc file to publish to GitHub Packages
- uses: actions/setup-node@v2
- uses: {% data reusables.actions.action-setup-node %}
with:
node-version: '16.x'
registry-url: 'https://npm.pkg.github.com'
@@ -161,7 +159,6 @@ always-auth=true
If you use the Yarn package manager, you can install and publish packages using Yarn.
{% raw %}
```yaml{:copy}
name: Publish Package to npmjs
on:
@@ -171,9 +168,9 @@ jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
# Setup .npmrc file to publish to npm
- uses: actions/setup-node@v2
- uses: {% data reusables.actions.action-setup-node %}
with:
node-version: '16.x'
registry-url: 'https://registry.npmjs.org'
@@ -182,6 +179,5 @@ jobs:
- run: yarn
- run: yarn publish
env:
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
NODE_AUTH_TOKEN: {% raw %}${{ secrets.NPM_TOKEN }}{% endraw %}
```
{% endraw %}

4
content/actions/quickstart.md
View File

@@ -39,9 +39,9 @@ The following example shows you how {% data variables.product.prodname_actions %
steps:
- run: echo "🎉 The job was automatically triggered by a ${{ github.event_name }} event."
- run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by GitHub!"
- run: echo "🔎 The name of your branch is ${{ github.ref }} and your repository is ${{ github.repository }}."
- run: echo "🔎 The name of your branch is ${{ github.ref }} and your repository is ${{ github.repository }}."{% endraw %}
- name: Check out repository code
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}{% raw %}
- run: echo "💡 The ${{ github.repository }} repository has been cloned to the runner."
- run: echo "🖥️ The workflow is now ready to test your code on the runner."
- name: List files in the repository

47
content/actions/security-guides/encrypted-secrets.md
View File

@@ -328,29 +328,27 @@ Secrets are limited to 64 KB in size. To use secrets that are larger than 64 KB,
1. From your workflow, use a `step` to call the shell script and decrypt the secret. To have a copy of your repository in the environment that your workflow runs in, you'll need to use the [`actions/checkout`](https://github.com/actions/checkout) action. Reference your shell script using the `run` command relative to the root of your repository.
{% raw %}
```yaml
name: Workflows with large secrets
on: push
jobs:
my-job:
name: My Job
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Decrypt large secret
run: ./.github/scripts/decrypt_secret.sh
env:
LARGE_SECRET_PASSPHRASE: ${{ secrets.LARGE_SECRET_PASSPHRASE }}
# This command is just an example to show your secret being printed
# Ensure you remove any print statements of your secrets. GitHub does
# not hide secrets that use this workaround.
- name: Test printing your secret (Remove this step in production)
run: cat $HOME/secrets/my_secret.json
```
{% endraw %}
```yaml
name: Workflows with large secrets
on: push
jobs:
my-job:
name: My Job
runs-on: ubuntu-latest
steps:
- uses: {% data reusables.actions.action-checkout %}
- name: Decrypt large secret
run: ./.github/scripts/decrypt_secret.sh
env:
LARGE_SECRET_PASSPHRASE: {% raw %}${{ secrets. LARGE_SECRET_PASSPHRASE }}{% endraw %}
# This command is just an example to show your secret being printed
# Ensure you remove any print statements of your secrets. GitHub does
# not hide secrets that use this workaround.
- name: Test printing your secret (Remove this step in production)
run: cat $HOME/secrets/my_secret.json
```
## Storing Base64 binary blobs as secrets
@@ -386,7 +384,7 @@ You can use Base64 encoding to store small binary blobs as secrets. You can then
decode-secret:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Retrieve the secret and decode it to a file
env:
{% raw %}CERTIFICATE_BASE64: ${{ secrets.CERTIFICATE_BASE64 }}{% endraw %}
@@ -396,4 +394,3 @@ You can use Base64 encoding to store small binary blobs as secrets. You can then
run: |
openssl x509 -in cert.der -inform DER -text -noout
```

12
content/actions/using-containerized-services/creating-postgresql-service-containers.md
View File

@@ -41,7 +41,6 @@ You may also find it helpful to have a basic understanding of YAML, the syntax f
{% data reusables.actions.copy-workflow-file %}
{% raw %}
```yaml{:copy}
name: PostgreSQL service example
on: push
@@ -73,7 +72,7 @@ jobs:
steps:
# Downloads a copy of the code in your repository before running CI tests
- name: Check out repository code
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
# Performs a clean installation of all dependencies in the `package.json` file
# For more information, see https://docs.npmjs.com/cli/ci.html
@@ -91,7 +90,6 @@ jobs:
# The default PostgreSQL port
POSTGRES_PORT: 5432
```
{% endraw %}
### Configuring the runner job
@@ -133,7 +131,7 @@ jobs:
steps:
# Downloads a copy of the code in your repository before running CI tests
- name: Check out repository code
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
# Performs a clean installation of all dependencies in the `package.json` file
# For more information, see https://docs.npmjs.com/cli/ci.html
@@ -163,7 +161,6 @@ When you run a job directly on the runner machine, you'll need to map the ports
{% data reusables.actions.copy-workflow-file %}
{% raw %}
```yaml{:copy}
name: PostgreSQL Service Example
on: push
@@ -196,7 +193,7 @@ jobs:
steps:
# Downloads a copy of the code in your repository before running CI tests
- name: Check out repository code
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
# Performs a clean installation of all dependencies in the `package.json` file
# For more information, see https://docs.npmjs.com/cli/ci.html
@@ -215,7 +212,6 @@ jobs:
# The default PostgreSQL port
POSTGRES_PORT: 5432
```
{% endraw %}
### Configuring the runner job
@@ -260,7 +256,7 @@ jobs:
steps:
# Downloads a copy of the code in your repository before running CI tests
- name: Check out repository code
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
# Performs a clean installation of all dependencies in the `package.json` file
# For more information, see https://docs.npmjs.com/cli/ci.html

12
content/actions/using-containerized-services/creating-redis-service-containers.md
View File

@@ -41,7 +41,6 @@ You may also find it helpful to have a basic understanding of YAML, the syntax f
{% data reusables.actions.copy-workflow-file %}
{% raw %}
```yaml{:copy}
name: Redis container example
on: push
@@ -70,7 +69,7 @@ jobs:
steps:
# Downloads a copy of the code in your repository before running CI tests
- name: Check out repository code
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
# Performs a clean installation of all dependencies in the `package.json` file
# For more information, see https://docs.npmjs.com/cli/ci.html
@@ -88,7 +87,6 @@ jobs:
# The default Redis port
REDIS_PORT: 6379
```
{% endraw %}
### Configuring the container job
@@ -127,7 +125,7 @@ jobs:
steps:
# Downloads a copy of the code in your repository before running CI tests
- name: Check out repository code
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
# Performs a clean installation of all dependencies in the `package.json` file
# For more information, see https://docs.npmjs.com/cli/ci.html
@@ -156,7 +154,6 @@ When you run a job directly on the runner machine, you'll need to map the ports
{% data reusables.actions.copy-workflow-file %}
{% raw %}
```yaml{:copy}
name: Redis runner example
on: push
@@ -186,7 +183,7 @@ jobs:
steps:
# Downloads a copy of the code in your repository before running CI tests
- name: Check out repository code
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
# Performs a clean installation of all dependencies in the `package.json` file
# For more information, see https://docs.npmjs.com/cli/ci.html
@@ -205,7 +202,6 @@ jobs:
# The default Redis port
REDIS_PORT: 6379
```
{% endraw %}
### Configuring the runner job
@@ -247,7 +243,7 @@ jobs:
steps:
# Downloads a copy of the code in your repository before running CI tests
- name: Check out repository code
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
# Performs a clean installation of all dependencies in the `package.json` file
# For more information, see https://docs.npmjs.com/cli/ci.html

8
content/actions/using-github-hosted-runners/customizing-github-hosted-runners.md
View File

@@ -22,7 +22,6 @@ This guide demonstrates how to create a job that installs additional software on
The following example demonstrates how to install an `apt` package as part of a job.
{% raw %}
```yaml
name: Build on Ubuntu
on: push
@@ -32,13 +31,12 @@ jobs:
runs-on: ubuntu-latest
steps:
- name: Check out repository code
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
- name: Install jq tool
run: |
sudo apt-get update
sudo apt-get install jq
```
{% endraw %}
{% note %}
@@ -50,7 +48,6 @@ jobs:
The following example demonstrates how to install Brew packages and casks as part of a job.
{% raw %}
```yaml
name: Build on macOS
on: push
@@ -60,7 +57,7 @@ jobs:
runs-on: macos-latest
steps:
- name: Check out repository code
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
- name: Install GitHub CLI
run: |
brew update
@@ -70,7 +67,6 @@ jobs:
brew update
brew install --cask microsoft-edge
```
{% endraw %}
## Installing software on Windows runners

16
content/actions/using-workflows/advanced-workflow-features.md
View File

@@ -74,7 +74,6 @@ For more information, see "[Defining prerequisite jobs](/actions/using-jobs/usin
You can use a build matrix if you want your workflow to run tests across multiple combinations of operating systems, platforms, and languages. The build matrix is created using the `strategy` keyword, which receives the build options as an array. For example, this build matrix will run the job multiple times, using different versions of Node.js:
{% raw %}
```yaml
jobs:
build:
@@ -83,11 +82,10 @@ jobs:
matrix:
node: [6, 8, 10]
steps:
- uses: actions/setup-node@v2
- uses: {% data reusables.actions.action-setup-node %}
with:
node-version: ${{ matrix.node }}
node-version: {% raw %}${{ matrix.node }}{% endraw %}
```
{% endraw %}
For more information, see "[Using a build matrix for your jobs](/actions/using-jobs/using-a-build-matrix-for-your-jobs)."
@@ -98,22 +96,20 @@ For more information, see "[Using a build matrix for your jobs](/actions/using-j
This example demonstrates how to cache the ` ~/.npm` directory:
{% raw %}
```yaml
jobs:
example-job:
steps:
- name: Cache node modules
uses: actions/cache@v2
uses: {% data reusables.actions.action-cache %}
env:
cache-name: cache-node-modules
with:
path: ~/.npm
key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
key: {% raw %}${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}{% endraw %}
restore-keys: |
${{ runner.os }}-build-${{ env.cache-name }}-
{% raw %}${{ runner.os }}-build-${{ env.cache-name }}-{% endraw %}
```
{% endraw %}
For more information, see "<a href="/actions/guides/caching-dependencies-to-speed-up-workflows" class="dotcom-only">Caching dependencies to speed up workflows</a>."
{% endif %}
@@ -132,7 +128,7 @@ jobs:
image: postgres
steps:
- name: Check out repository code
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
- name: Install dependencies
run: npm ci
- name: Connect to PostgreSQL

17
content/actions/using-workflows/caching-dependencies-to-speed-up-workflows.md
View File

@@ -92,9 +92,10 @@ For more information, see [`actions/cache`](https://github.com/actions/cache).
- `path`: **Required** The file path on the runner to cache or restore. The path can be an absolute path or relative to the workspace directory.
- Paths can be either directories or single files, and glob patterns are supported.
- With `v2` of the `cache` action, you can specify a single path, or you can add multiple paths on separate lines. For example:
```
- name: Cache Gradle packages
uses: actions/cache@v2
uses: {% data reusables.actions.action-cache %}
with:
path: |
~/.gradle/caches
@@ -111,7 +112,6 @@ 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{:copy}
name: Caching with npm
@@ -122,20 +122,20 @@ jobs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Cache node modules
uses: actions/cache@v2
uses: {% data reusables.actions.action-cache %}
env:
cache-name: cache-node-modules
with:
# npm cache files are stored in `~/.npm` on Linux/macOS
path: ~/.npm
key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
key: {% raw %}${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}{% endraw %}
restore-keys: |
${{ runner.os }}-build-${{ env.cache-name }}-
${{ runner.os }}-build-
${{ runner.os }}-
{% raw %}${{ runner.os }}-build-${{ env.cache-name }}-{% endraw %}
{% raw %}${{ runner.os }}-build-{% endraw %}
{% raw %}${{ runner.os }}-{% endraw %}
- name: Install Dependencies
run: npm install
@@ -146,7 +146,6 @@ jobs:
- name: Test
run: npm test
```
{% endraw %}
When `key` matches an existing cache, it's called a cache hit, and the action restores the cached files to the `path` directory.

2
content/actions/using-workflows/creating-starter-workflows-for-your-organization.md
View File

@@ -66,7 +66,7 @@ This procedure demonstrates how to create a starter workflow and metadata file.
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Run a one-line script
run: echo Hello from Octo Organization

12
content/actions/using-workflows/events-that-trigger-workflows.md
View File

@@ -1079,6 +1079,12 @@ on:
types: [on-demand-test]
```
{% note %}
**Note:** The `event_type` value is limited to 100 characters.
{% endnote %}
Any data that you send through the `client_payload` parameter will be available in the `github.event` context in your workflow. For example, if you send this request body when you create a repository dispatch event:
```json
@@ -1429,7 +1435,7 @@ jobs:
run: |
mkdir -p ./pr
echo $PR_NUMBER > ./pr/pr_number
- uses: actions/upload-artifact@v3
- uses: {% data reusables.actions.action-upload-artifact %}
with:
name: pr_number
path: pr/
@@ -1451,7 +1457,7 @@ jobs:
runs-on: ubuntu-latest
steps:
- name: 'Download artifact'
uses: actions/github-script@v5
uses: {% data reusables.actions.action-github-script %}
with:
script: |
let allArtifacts = await github.rest.actions.listWorkflowRunArtifacts({
@@ -1475,7 +1481,7 @@ jobs:
run: unzip pr_number.zip
- name: 'Comment on PR'
uses: actions/github-script@v5
uses: {% data reusables.actions.action-github-script %}
with:
github-token: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
script: |

20
content/actions/using-workflows/storing-workflow-data-as-artifacts.md
View File

@@ -94,21 +94,21 @@ jobs:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
- name: npm install, build, and test
run: |
npm install
npm run build --if-present
npm test
- name: Archive production artifacts
uses: actions/upload-artifact@v3
uses: {% data reusables.actions.action-upload-artifact %}
with:
name: dist-without-markdown
path: |
dist
!dist/**/*.md
- name: Archive code coverage results
uses: actions/upload-artifact@v3
uses: {% data reusables.actions.action-upload-artifact %}
with:
name: code-coverage-report
path: output/test/code-coverage.html
@@ -120,7 +120,7 @@ You can define a custom retention period for individual artifacts created by a w
```yaml{:copy}
- name: 'Upload Artifact'
uses: actions/upload-artifact@v3
uses: {% data reusables.actions.action-upload-artifact %}
with:
name: my-artifact
path: my_file.txt
@@ -149,7 +149,7 @@ Specify an artifact's name to download an individual artifact. If you uploaded a
```yaml
- name: Download a single artifact
uses: actions/download-artifact@v3
uses: {% data reusables.actions.action-download-artifact %}
with:
name: my-artifact
```
@@ -158,7 +158,7 @@ You can also download all artifacts in a workflow run by not specifying a name.
```yaml
- name: Download all workflow run artifacts
uses: actions/download-artifact@v3
uses: {% data reusables.actions.action-download-artifact %}
```
If you download all workflow run's artifacts, a directory for each artifact is created using its name.
@@ -200,7 +200,7 @@ jobs:
run: |
expr 3 + 7 > math-homework.txt
- name: Upload math result for job 1
uses: actions/upload-artifact@v3
uses: {% data reusables.actions.action-upload-artifact %}
with:
name: homework
path: math-homework.txt
@@ -211,7 +211,7 @@ jobs:
runs-on: windows-latest
steps:
- name: Download math result for job 1
uses: actions/download-artifact@v3
uses: {% data reusables.actions.action-download-artifact %}
with:
name: homework
- shell: bash
@@ -219,7 +219,7 @@ jobs:
value=`cat math-homework.txt`
expr $value \* 9 > math-homework.txt
- name: Upload math result for job 2
uses: actions/upload-artifact@v3
uses: {% data reusables.actions.action-upload-artifact %}
with:
name: homework
path: math-homework.txt
@@ -230,7 +230,7 @@ jobs:
runs-on: macOS-latest
steps:
- name: Download math result for job 2
uses: actions/download-artifact@v3
uses: {% data reusables.actions.action-download-artifact %}
with:
name: homework
- name: Print the final result

12
content/actions/using-workflows/workflow-syntax-for-github-actions.md
View File

@@ -391,9 +391,9 @@ steps:
# Reference a specific commit
- uses: actions/checkout@a81bbbf8298c0fa03ea29cdc473d45769f953675
# Reference the major version of a release
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
# Reference a specific version
- uses: actions/checkout@v2.2.0
- uses: {% data reusables.actions.action-checkout %}.2.0
# Reference a branch
- uses: actions/checkout@main
```
@@ -441,7 +441,7 @@ jobs:
my_first_job:
steps:
- name: Check out repository
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
- name: Use local my-action
uses: ./.github/actions/my-action
```
@@ -495,22 +495,20 @@ Your workflow must checkout the private repository and reference the action loca
Replace `PERSONAL_ACCESS_TOKEN` in the example with the name of your secret.
{% raw %}
```yaml
jobs:
my_first_job:
steps:
- name: Check out repository
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
with:
repository: octocat/my-private-repo
ref: v1.0
token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
token: {% raw %}${{ secrets.PERSONAL_ACCESS_TOKEN }}{% endraw %}
path: ./.github/actions/my-private-repo
- name: Run my action
uses: ./.github/actions/my-private-repo/my-action
```
{% endraw %}
### `jobs.<job_id>.steps[*].run`

16
content/admin/github-actions/managing-access-to-actions-from-githubcom/setting-up-the-tool-cache-on-self-hosted-runners-without-internet-access.md
View File

@@ -47,7 +47,6 @@ You can populate the runner tool cache by running a {% data variables.product.pr
The following example demonstrates a workflow that uploads the tool cache for an Ubuntu 18.04 environment, using the `setup-node` action with Node.js versions 10 and 12.
{% raw %}
```yaml
name: Upload Node.js 10 and 12 tool cache
on: push
@@ -57,26 +56,25 @@ You can populate the runner tool cache by running a {% data variables.product.pr
steps:
- name: Clear any existing tool cache
run: |
mv "${{ runner.tool_cache }}" "${{ runner.tool_cache }}.old"
mkdir -p "${{ runner.tool_cache }}"
mv "{% raw %}${{ runner.tool_cache }}" "${{ runner.tool_cache }}.old"{% endraw %}
mkdir -p "{% raw %}${{ runner.tool_cache }}{% endraw %}"
- name: Setup Node 10
uses: actions/setup-node@v2
uses: {% data reusables.actions.action-setup-node %}
with:
node-version: 10.x
- name: Setup Node 12
uses: actions/setup-node@v2
uses: {% data reusables.actions.action-setup-node %}
with:
node-version: 12.x
- name: Archive tool cache
run: |
cd "${{ runner.tool_cache }}"
cd "{% raw %}${{ runner.tool_cache }}{% endraw %}"
tar -czf tool_cache.tar.gz *
- name: Upload tool cache artifact
uses: actions/upload-artifact@v3
uses: {% data reusables.actions.action-upload-artifact %}
with:
path: ${{runner.tool_cache}}/tool_cache.tar.gz
path: {% raw %}${{runner.tool_cache}}/tool_cache.tar.gz{% endraw %}
```
{% endraw %}
1. Download the tool cache artifact from the workflow run. For instructions on downloading artifacts, see "[Downloading workflow artifacts](/actions/managing-workflow-runs/downloading-workflow-artifacts)."
1. Transfer the tool cache artifact to your self hosted runner and extract it to the local tool cache directory. The default tool cache directory is `RUNNER_DIR/_work/_tool`. If the runner hasn't processed any jobs yet, you might need to create the `_work/_tool` directories.

6
content/admin/github-actions/managing-access-to-actions-from-githubcom/using-the-latest-version-of-the-official-bundled-actions.md
View File

@@ -28,7 +28,7 @@ To update the bundled actions, you can use the `actions-sync` tool to update the
You can use {% data variables.product.prodname_github_connect %} to allow {% data variables.product.product_name %} to use actions from {% data variables.product.prodname_dotcom_the_website %}. For more information, see "[Enabling automatic access to {% data variables.product.prodname_dotcom_the_website %} actions using {% data variables.product.prodname_github_connect %}](/admin/github-actions/enabling-automatic-access-to-githubcom-actions-using-github-connect)."
Once {% data variables.product.prodname_github_connect %} is configured, you can use the latest version of an action by deleting its local repository in the `actions` organization on your instance. For example, if your enterprise instance is using the `actions/checkout@v1` action, and you need to use `actions/checkout@v2` which isn't available on your enterprise instance, perform the following steps to be able to use the latest `checkout` action from {% data variables.product.prodname_dotcom_the_website %}:
Once {% data variables.product.prodname_github_connect %} is configured, you can use the latest version of an action by deleting its local repository in the `actions` organization on your instance. For example, if your enterprise instance is using `v1` of the `actions/checkout` action, and you need to use `{% data reusables.actions.action-checkout %}` which isn't available on your enterprise instance, perform the following steps to be able to use the latest `checkout` action from {% data variables.product.prodname_dotcom_the_website %}:
1. From an enterprise owner account on {% data variables.product.product_name %}, navigate to the repository you want to delete from the *actions* organization (in this example `checkout`).
1. By default, site administrators are not owners of the bundled *actions* organization. To get the access required to delete the `checkout` repository, you must use the site admin tools. Click {% octicon "rocket" aria-label="The rocket ship" %} in the upper-right corner of any page in that repository.
@@ -44,8 +44,8 @@ Once {% data variables.product.prodname_github_connect %} is configured, you can
1. Under "Repository info", click **View code** to leave the site admin pages and display the `checkout` repository.
1. Delete the `checkout` repository within the `actions` organization. For information on how to delete a repository, see "[Deleting a repository](/github/administering-a-repository/deleting-a-repository)."
![View code link](/assets/images/enterprise/site-admin-settings/exit-admin-page-for-repository.png)
1. Configure your workflow's YAML to use `actions/checkout@v2`.
1. Each time your workflow runs, the runner will use the `v2` version of `actions/checkout` from {% data variables.product.prodname_dotcom_the_website %}.
1. Configure your workflow's YAML to use `{% data reusables.actions.action-checkout %}`.
1. Each time your workflow runs, the runner will use the specified version of `actions/checkout` from {% data variables.product.prodname_dotcom_the_website %}.
{% ifversion ghes > 3.2 or ghae-issue-4815 %}
{% note %}

2
content/admin/identity-and-access-management/managing-iam-for-your-enterprise/configuring-saml-single-sign-on-for-your-enterprise-using-okta.md
View File

@@ -31,7 +31,7 @@ Alternatively, you can also configure SAML SSO using Okta for an organization th
## Adding the {% data variables.product.prodname_ghe_cloud %} application in Okta
{% data reusables.saml.okta-sign-into-your-account %}
1. Navigate to the [Github Enterprise Cloud - Enterprise Accounts](https://www.okta.com/integrations/github-enterprise-cloud-enterprise-accounts) application in the Okta Integration Network and click **Add Integration**.
1. Navigate to the [{% data variables.product.prodname_ghe_cloud %} - Enterprise Accounts](https://www.okta.com/integrations/github-enterprise-cloud-enterprise-accounts) application in the Okta Integration Network and click **Add Integration**.
{% data reusables.saml.okta-dashboard-click-applications %}
1. Optionally, to the right of "Application label", type a descriptive name for the application.
1. To the right of "{% data variables.product.prodname_dotcom %} Enterprises", type the name of your enterprise account. For example, if your enterprise account's URL is `https://github.com/enterprises/octo-corp`, type `octo-corp`.

12
content/authentication/managing-commit-signature-verification/telling-git-about-your-signing-key.md
View File

@@ -96,16 +96,10 @@ If you have multiple GPG keys, you need to tell Git which one to use.
{% data reusables.gpg.list-keys-with-note %}
{% data reusables.gpg.copy-gpg-key-id %}
{% data reusables.gpg.paste-gpg-key-id %}
1. To add your GPG key to your bash profile, run the following command:
```shell
$ if [ -r ~/.bash_profile ]; then echo 'export GPG_TTY=$(tty)' >> ~/.bash_profile; \
else echo 'export GPG_TTY=$(tty)' >> ~/.profile; fi
1. To add your GPG key to your `.bashrc` startup file, run the following command:
```bash
$ [ -f ~/.bashrc ] && echo 'export GPG_TTY=$(tty)' >> ~/.bashrc
```
{% note %}
**Note:** If you don't have `.bash_profile`, this command adds your GPG key to `.profile`.
{% endnote %}
{% endlinux %}

1
content/billing/managing-billing-for-your-github-account/one-time-payments-for-customers-in-india.md
View File

@@ -67,3 +67,4 @@ Existing sponsorships will remain in place during this period and maintainers wi
![One-time payment edit summary](/assets/images/help/billing/payment-summary-edit.png)
6. Once payment for the current billing cycle has been successfully made, the **Pay now** button on your "Billing & plans" page will be disabled until your next payment is due.
![One-time payment pay now button disabled](/assets/images/help/billing/pay-now-button-disabled.png)

2
content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning-alerts.md
View File

@@ -108,7 +108,7 @@ The default {% data variables.product.prodname_codeql %} query suites do not inc
When you update your workflow to run an additional query suite this will increase the analysis time.
``` yaml
- uses: github/codeql-action/init@v1
- uses: {% data reusables.actions.action-codeql-action-init %}
with:
# Run extended queries including queries using machine learning
queries: security-extended

44
content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning.md
View File

@@ -193,13 +193,11 @@ For recommended specifications (RAM, CPU cores, and disk) for running {% data va
In general, you do not need to worry about where the {% data variables.product.prodname_codeql_workflow %} places {% data variables.product.prodname_codeql %} databases since later steps will automatically find databases created by previous steps. However, if you are writing a custom workflow step that requires the {% data variables.product.prodname_codeql %} database to be in a specific disk location, for example to upload the database as a workflow artifact, you can specify that location using the `db-location` parameter under the `init` action.
{% raw %}
``` yaml
- uses: github/codeql-action/init@v1
- uses: {% data reusables.actions.action-codeql-action-init %}
with:
db-location: '${{ github.workspace }}/codeql_dbs'
db-location: {% raw %}'${{ github.workspace }}/codeql_dbs'{% endraw %}
```
{% endraw %}
The {% data variables.product.prodname_codeql_workflow %} will expect the path provided in `db-location` to be writable, and either not exist, or be an empty directory. When using this parameter in a job running on a self-hosted runner or using a Docker container, it's the responsibility of the user to ensure that the chosen directory is cleared between runs, or that the databases are removed once they are no longer needed. {% ifversion fpt or ghec or ghes %} This is not necessary for jobs running on {% data variables.product.prodname_dotcom %}-hosted runners, which obtain a fresh instance and a clean filesystem each time they run. For more information, see "[About {% data variables.product.prodname_dotcom %}-hosted runners](/actions/using-github-hosted-runners/about-github-hosted-runners)."{% endif %}
@@ -232,7 +230,7 @@ jobs:
If your workflow does not contain a matrix called `language`, then {% data variables.product.prodname_codeql %} is configured to run analysis sequentially. If you don't specify languages in the workflow, {% data variables.product.prodname_codeql %} automatically detects, and attempts to analyze, any supported languages in the repository. If you want to choose which languages to analyze, without using a matrix, you can use the `languages` parameter under the `init` action.
```yaml
- uses: github/codeql-action/init@v1
- uses: {% data reusables.actions.action-codeql-action-init %}
with:
languages: cpp, csharp, python
```
@@ -257,9 +255,9 @@ jobs:
steps:
- name: Checkout repository
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
- name: Set up Python
uses: actions/setup-python@v2
uses: {% data reusables.actions.action-setup-python %}
with:
python-version: '3.x'
- name: Install dependencies
@@ -272,7 +270,7 @@ jobs:
# that includes the dependencies
echo "CODEQL_PYTHON=$(which python)" >> $GITHUB_ENV
- name: Initialize CodeQL
uses: github/codeql-action/init@v1
uses: {% data reusables.actions.action-codeql-action-init %}
with:
languages: python
# Override the default behavior so that the action doesn't attempt
@@ -288,17 +286,15 @@ Use `category` to distinguish between multiple analyses for the same tool and co
This parameter is particularly useful if you work with monorepos and have multiple SARIF files for different components of the monorepo.
{% raw %}
``` yaml
- name: Perform CodeQL Analysis
uses: github/codeql-action/analyze
uses: {% data reusables.actions.action-codeql-action-analyze %}
with:
# Optional. Specify a category to distinguish between multiple analyses
# for the same tool and ref. If you don't use `category` in your workflow,
# GitHub will generate a default category name for you
category: "my_category"
```
{% endraw %}
If you don't specify a `category` parameter in your workflow, {% data variables.product.product_name %} will generate a category name for you, based on the name of the workflow file triggering the action, the action name, and any matrix variables. For example:
- The `.github/workflows/codeql-analysis.yml` workflow and the `analyze` action will produce the category `.github/workflows/codeql.yml:analyze`.
@@ -319,7 +315,7 @@ Your specified category will not overwrite the details of the `runAutomationDeta
{% data reusables.code-scanning.beta-codeql-packs-cli %}
To add one or more {% data variables.product.prodname_codeql %} query packs (beta), add a `with: packs:` entry within the `uses: github/codeql-action/init@v1` section of the workflow. Within `packs` you specify one or more packages to use and, optionally, which version to download. Where you don't specify a version, the latest version is downloaded. If you want to use packages that are not publicly available, you need to set the `GITHUB_TOKEN` environment variable to a secret that has access to the packages. For more information, see "[Authentication in a workflow](/actions/reference/authentication-in-a-workflow)" and "[Encrypted secrets](/actions/reference/encrypted-secrets)."
To add one or more {% data variables.product.prodname_codeql %} query packs (beta), add a `with: packs:` entry within the `uses: {% data reusables.actions.action-codeql-action-init %}` section of the workflow. Within `packs` you specify one or more packages to use and, optionally, which version to download. Where you don't specify a version, the latest version is downloaded. If you want to use packages that are not publicly available, you need to set the `GITHUB_TOKEN` environment variable to a secret that has access to the packages. For more information, see "[Authentication in a workflow](/actions/reference/authentication-in-a-workflow)" and "[Encrypted secrets](/actions/reference/encrypted-secrets)."
{% note %}
@@ -329,28 +325,24 @@ To add one or more {% data variables.product.prodname_codeql %} query packs (bet
In the example below, `scope` is the organization or personal account that published the package. When the workflow runs, the three {% data variables.product.prodname_codeql %} query packs are downloaded from {% data variables.product.product_name %} and the default queries or query suite for each pack run. The latest version of `pack1` is downloaded as no version is specified. Version 1.2.3 of `pack2` is downloaded, as well as the latest version of `pack3` that is compatible with version 1.2.3.
{% raw %}
``` yaml
- uses: github/codeql-action/init@v1
- uses: {% data reusables.actions.action-codeql-action-init %}
with:
# Comma-separated list of packs to download
packs: scope/pack1,scope/pack2@1.2.3,scope/pack3@~1.2.3
```
{% endraw %}
### Using queries in QL packs
{% endif %}
To add one or more queries, add a `with: queries:` entry within the `uses: github/codeql-action/init@v1` section of the workflow. If the queries are in a private repository, use the `external-repository-token` parameter to specify a token that has access to checkout the private repository.
To add one or more queries, add a `with: queries:` entry within the `uses: {% data reusables.actions.action-codeql-action-init %}` section of the workflow. If the queries are in a private repository, use the `external-repository-token` parameter to specify a token that has access to checkout the private repository.
{% raw %}
``` yaml
- uses: github/codeql-action/init@v1
- uses: {% data reusables.actions.action-codeql-action-init %}
with:
queries: COMMA-SEPARATED LIST OF PATHS
# Optional. Provide a token to access queries stored in private repositories.
external-repository-token: ${{ secrets.ACCESS_TOKEN }}
external-repository-token: {% raw %}${{ secrets.ACCESS_TOKEN }}{% endraw %}
```
{% endraw %}
You can also specify query suites in the value of `queries`. Query suites are collections of queries, usually grouped by purpose or language.
@@ -365,13 +357,13 @@ If you also use a configuration file for custom settings, any additional {% if c
In the following example, the `+` symbol ensures that the specified additional {% if codeql-packs %}packs and {% endif %}queries are used together with any specified in the referenced configuration file.
``` yaml
- uses: github/codeql-action/init@v1
- uses: {% data reusables.actions.action-codeql-action-init %}
with:
config-file: ./.github/codeql/codeql-config.yml
queries: +security-and-quality,octo-org/python-qlpack/show_ifs.ql@main
{%- if codeql-packs %}
packs: +scope/pack1,scope/pack2@v1.2.3
{% endif %}
{%- endif %}
```
## Using a custom configuration file
@@ -381,7 +373,7 @@ A custom configuration file is an alternative way to specify additional {% if co
In the workflow file, use the `config-file` parameter of the `init` action to specify the path to the configuration file you want to use. This example loads the configuration file _./.github/codeql/codeql-config.yml_.
``` yaml
- uses: github/codeql-action/init@v1
- uses: {% data reusables.actions.action-codeql-action-init %}
with:
config-file: ./.github/codeql/codeql-config.yml
```
@@ -390,13 +382,11 @@ In the workflow file, use the `config-file` parameter of the `init` action to sp
If the configuration file is located in an external private repository, use the `external-repository-token` parameter of the `init` action to specify a token that has access to the private repository.
{% raw %}
```yaml
- uses: github/codeql-action/init@v1
- uses: {% data reusables.actions.action-codeql-action-init %}
with:
external-repository-token: ${{ secrets.ACCESS_TOKEN }}
external-repository-token: {% raw %}${{ secrets.ACCESS_TOKEN }}{% endraw %}
```
{% endraw %}
The settings in the configuration file are written in YAML format.

2
content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-the-codeql-workflow-for-compiled-languages.md
View File

@@ -121,7 +121,7 @@ If your repository contains multiple compiled languages, you can specify languag
```yaml
- if: matrix.language == 'cpp' || matrix.language == 'csharp'
name: Autobuild
uses: github/codeql-action/autobuild@v1
uses: {% data reusables.actions.action-codeql-action-autobuild %}
- if: matrix.language == 'java'
name: Build Java

6
content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/running-codeql-code-scanning-in-a-container.md
View File

@@ -82,9 +82,9 @@ jobs:
steps:
- name: Checkout repository
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
- name: Initialize {% data variables.product.prodname_codeql %}
uses: github/codeql-action/init@v1
uses: {% data reusables.actions.action-codeql-action-init %}
with:
languages: {% raw %}${{ matrix.language }}{% endraw %}
- name: Build
@@ -92,5 +92,5 @@ jobs:
./configure
make
- name: Perform {% data variables.product.prodname_codeql %} Analysis
uses: github/codeql-action/analyze@v1
uses: {% data reusables.actions.action-codeql-action-analyze %}
```

11
content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/troubleshooting-the-codeql-workflow.md
View File

@@ -51,10 +51,11 @@ You can obtain artifacts to help you debug {% data variables.product.prodname_co
```yaml
- name: Initialize CodeQL
uses: github/codeql-action/init@v1
uses: {% data reusables.actions.action-codeql-action-init %}
with:
debug: true
```
The debug artifacts will be uploaded to the workflow run as an artifact named `debug-artifacts`. The data contains the {% data variables.product.prodname_codeql %} logs, {% data variables.product.prodname_codeql %} database(s), and any SARIF file(s) produced by the workflow.
These artifacts will help you debug problems with {% data variables.product.prodname_codeql %} code scanning. If you contact GitHub support, they might ask for this data.
@@ -86,7 +87,7 @@ If an automatic build of code for a compiled language within your project fails,
steps:
...
- name: Initialize {% data variables.product.prodname_codeql %}
uses: github/codeql-action/init@v1
uses: {% data reusables.actions.action-codeql-action-init %}
with:
languages: {% raw %}${{ matrix.language }}{% endraw %}
```
@@ -151,7 +152,7 @@ You may be able to understand why some source files haven't been analyzed by ins
```yaml
- name: Initialize CodeQL
uses: github/codeql-action/init@v1
uses: {% data reusables.actions.action-codeql-action-init %}
with:
debug: true
```
@@ -294,11 +295,11 @@ The revised `steps` section of the workflow will look like this:
```yaml
steps:
- name: Checkout repository
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
# Initializes the {% data variables.product.prodname_codeql %} tools for scanning.
- name: Initialize {% data variables.product.prodname_codeql %}
uses: github/codeql-action/init@v1
uses: {% data reusables.actions.action-codeql-action-init %}
...
```

8
content/code-security/code-scanning/integrating-with-code-scanning/uploading-a-sarif-file-to-github.md
View File

@@ -94,9 +94,9 @@ jobs:
steps:
# This step checks out a copy of your repository.
- name: Checkout repository
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
- name: Upload SARIF file
uses: github/codeql-action/upload-sarif@v1
uses: {% data reusables.actions.action-codeql-action-upload-sarif %}
with:
# Path to SARIF file relative to the root of the repository
sarif_file: results.sarif
@@ -133,7 +133,7 @@ jobs:
actions: read
contents: read{% endif %}
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Run npm install
run: npm install
# Runs the ESlint code analysis
@@ -141,7 +141,7 @@ jobs:
# eslint exits 1 if it finds anything to report
run: node_modules/.bin/eslint build docs lib script spec-main -f node_modules/@microsoft/eslint-formatter-sarif/sarif.js -o results.sarif || true
# Uploads results.sarif to GitHub repository using the upload-sarif action
- uses: github/codeql-action/upload-sarif@v1
- uses: {% data reusables.actions.action-codeql-action-upload-sarif %}
with:
# Path to SARIF file relative to the root of the repository
sarif_file: results.sarif

2
content/code-security/dependabot/dependabot-alerts/viewing-and-updating-dependabot-alerts.md
View File

@@ -6,7 +6,7 @@ redirect_from:
- /github/managing-security-vulnerabilities/viewing-and-updating-vulnerable-dependencies-in-your-repository
- /code-security/supply-chain-security/viewing-and-updating-vulnerable-dependencies-in-your-repository
- /code-security/supply-chain-security/managing-vulnerabilities-in-your-projects-dependencies/viewing-and-updating-vulnerable-dependencies-in-your-repository
permissions: Repository administrators and organization owners can view and update dependencies.
permissions: Repository administrators and organization owners can view and update dependencies, as well as users and teams with explicit access.
shortTitle: View Dependabot alerts
versions:
fpt: '*'

30
content/code-security/dependabot/working-with-dependabot/automating-dependabot-with-github-actions.md
View File

@@ -82,8 +82,6 @@ If you have a workflow that will be triggered by {% data variables.product.prodn
To access a private container registry on AWS with a user name and password, a workflow must include a secret for `username` and `password`. In the example below, when {% data variables.product.prodname_dependabot %} triggers the workflow, the {% data variables.product.prodname_dependabot %} secrets with the names `READONLY_AWS_ACCESS_KEY_ID` and `READONLY_AWS_ACCESS_KEY` are used. If another actor triggers the workflow, the actions secrets with those names are used.
{% raw %}
```yaml
name: CI
on:
@@ -95,21 +93,19 @@ jobs:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
- name: Login to private container registry for dependencies
uses: docker/login-action@v1
with:
registry: https://1234567890.dkr.ecr.us-east-1.amazonaws.com
username: ${{ secrets.READONLY_AWS_ACCESS_KEY_ID }}
password: ${{ secrets.READONLY_AWS_ACCESS_KEY }}
username: {% raw %}${{ secrets.READONLY_AWS_ACCESS_KEY_ID }}{% endraw %}
password: {% raw %}${{ secrets.READONLY_AWS_ACCESS_KEY }}{% endraw %}
- name: Build the Docker image
run: docker build . --file Dockerfile --tag my-image-name:$(date +%s)
```
{% endraw %}
{% endif %}
{% ifversion ghes = 3.3 %}
@@ -128,8 +124,6 @@ If your workflow needs access to secrets or a `GITHUB_TOKEN` with write permissi
Below is a simple example of a `pull_request` workflow that might now be failing:
{% raw %}
```yaml
### This workflow now has no secrets and a read-only token
name: Dependabot Workflow
@@ -140,13 +134,11 @@ jobs:
dependabot:
runs-on: ubuntu-latest
# Always check the actor is Dependabot to prevent your workflow from failing on non-Dependabot PRs
if: ${{ github.actor == 'dependabot[bot]' }}
if: {% raw %}${{ github.actor == 'dependabot[bot]' }}{% endraw %}
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
```
{% endraw %}
You can replace `pull_request` with `pull_request_target`, which is used for pull requests from forks, and explicitly check out the pull request `HEAD`.
{% warning %}
@@ -155,8 +147,6 @@ You can replace `pull_request` with `pull_request_target`, which is used for pul
{% endwarning %}
{% raw %}
```yaml
### This workflow has access to secrets and a read-write token
name: Dependabot Workflow
@@ -169,17 +159,15 @@ permissions:
jobs:
dependabot:
runs-on: ubuntu-latest
if: ${{ github.actor == 'dependabot[bot]' }}
if: {% raw %}${{ github.actor == 'dependabot[bot]' }}{% endraw %}
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
with:
# Check out the pull request HEAD
ref: ${{ github.event.pull_request.head.sha }}
github-token: ${{ secrets.GITHUB_TOKEN }}
ref: {% raw %}${{ github.event.pull_request.head.sha }}{% endraw %}
github-token: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
```
{% endraw %}
It is also strongly recommended that you downscope the permissions granted to the `GITHUB_TOKEN` in order to avoid leaking a token with more privilege than necessary. For more information, see "[Permissions for the `GITHUB_TOKEN`](/actions/reference/authentication-in-a-workflow#permissions-for-the-github_token)."
### Handling `push` events

5
content/code-security/getting-started/securing-your-organization.md
View File

@@ -133,13 +133,14 @@ For more information, see "[Managing security and analysis settings for your org
{% data variables.product.prodname_code_scanning_capc %} is configured at the repository level. For more information, see "[Setting up {% data variables.product.prodname_code_scanning %} for a repository](/code-security/secure-coding/setting-up-code-scanning-for-a-repository)."
## Next steps
{% ifversion fpt or ghes > 3.1 or ghec %}You can view, filter, and sort security alerts for repositories owned by your organization in the security overview. For more information, see "[About the security overview](/code-security/security-overview/about-the-security-overview)."{% endif %}
You can view and manage alerts from security features to address dependencies and vulnerabilities in your code. For more information, see {% ifversion fpt or ghes or ghec %} "[Viewing {% data variables.product.prodname_dependabot_alerts %} for vulnerable dependencies](/code-security/supply-chain-security/viewing-and-updating-vulnerable-dependencies-in-your-repository),"{% endif %} {% ifversion fpt or ghec or ghes > 3.2 %}"[Managing pull requests for dependency updates](/code-security/supply-chain-security/managing-pull-requests-for-dependency-updates)," {% endif %}"[Managing {% data variables.product.prodname_code_scanning %} for your repository](/code-security/secure-coding/managing-code-scanning-alerts-for-your-repository)," and "[Managing alerts from {% data variables.product.prodname_secret_scanning %}](/code-security/secret-security/managing-alerts-from-secret-scanning)."
{% ifversion fpt or ghec %}If you have a security vulnerability, you can create a security advisory to privately discuss and fix the vulnerability. For more information, see "[About {% data variables.product.prodname_security_advisories %}](/code-security/security-advisories/about-github-security-advisories)" and "[Creating a security advisory](/code-security/security-advisories/creating-a-security-advisory)."
{% endif %}
{% ifversion fpt or ghes > 3.1 or ghec or ghae-issue-4554 %}{% ifversion ghes > 3.1 or ghec or ghae-issue-4554 %}You{% elsif fpt %}Organizations that use {% data variables.product.prodname_ghe_cloud %}{% endif %} can view, filter, and sort security alerts for repositories owned by {% ifversion ghes > 3.1 or ghec or ghae-issue-4554 %}your{% elsif fpt %}their{% endif %} organization in the security overview. For more information, see{% ifversion ghes or ghec or ghae-issue-4554 %} "[About the security overview](/code-security/security-overview/about-the-security-overview)."{% elsif fpt %} "[About the security overview](/enterprise-cloud@latest/code-security/security-overview/about-the-security-overview)" in the {% data variables.product.prodname_ghe_cloud %} documentation.{% endif %}{% endif %}
{% ifversion ghec %}
## Further reading

7
content/code-security/security-overview/about-the-security-overview.md
View File

@@ -26,8 +26,9 @@ shortTitle: About security overview
## About the security overview
You can use the security overview for a high-level view of the security status of your organization or to identify problematic repositories that require intervention. You can view aggregate or repository-specific security information in the security overview. You can also use the security overview to see which security features are enabled for your repositories and to configure any available security features that are not currently in use.
{% ifversion ghes or ghec or ghae %}You{% elsif fpt %}Organizations that use {% data variables.product.prodname_ghe_cloud %}{% endif %} can use the security overview for a high-level view of the security status of {% ifversion ghes or ghec or ghae %}your {% elsif fpt %}their{% endif %} organization or to identify problematic repositories that require intervention. {% ifversion ghes or ghec or ghae %}You {% elsif fpt %}These organizations{% endif %} can view aggregate or repository-specific security information in the security overview. {% ifversion ghes or ghec or ghae %}You {% elsif fpt %} Organizations that use {% data variables.product.prodname_ghe_cloud %}{% endif %} can also use the security overview to see which security features are enabled for {% ifversion ghes or ghec or ghae %}your {% elsif fpt %}their {% endif %} repositories and to configure any available security features that are not currently in use. {% ifversion fpt %}For more information, see [the {% data variables.product.prodname_ghe_cloud %} documentation](/enterprise-cloud@latest/code-security/security-overview/about-the-security-overview).{% endif %}
{% ifversion ghec or ghes or ghae %}
The security overview indicates whether {% ifversion fpt or ghes > 3.1 or ghec %}security{% endif %}{% ifversion ghae %}{% data variables.product.prodname_GH_advanced_security %}{% endif %} features are enabled for repositories owned by your organization and consolidates alerts for each feature.{% ifversion fpt or ghes > 3.1 or ghec %} Security features include {% data variables.product.prodname_GH_advanced_security %} features, such as {% data variables.product.prodname_code_scanning %} and {% data variables.product.prodname_secret_scanning %}, as well as {% data variables.product.prodname_dependabot_alerts %}.{% endif %} For more information about {% data variables.product.prodname_GH_advanced_security %} features, see "[About {% data variables.product.prodname_GH_advanced_security %}](/get-started/learning-about-github/about-github-advanced-security)."{% ifversion fpt or ghes > 3.1 or ghec %} For more information about {% data variables.product.prodname_dependabot_alerts %}, see "[About {% data variables.product.prodname_dependabot_alerts %}](/code-security/supply-chain-security/managing-vulnerabilities-in-your-projects-dependencies/about-alerts-for-vulnerable-dependencies#dependabot-alerts-for-vulnerable-dependencies)."{% endif %}
For more information about securing your code at the repository and organization levels, see "[Securing your repository](/code-security/getting-started/securing-your-repository)" and "[Securing your organization](/code-security/getting-started/securing-your-organization)."
@@ -77,6 +78,4 @@ At the enterprise-level, the security overview displays aggregate and repository
### About the team-level security overview
At the team-level, the security overview displays repository-specific security information for repositories that the team has admin privileges for. For more information, see "[Managing team access to an organization repository](/organizations/managing-access-to-your-organizations-repositories/managing-team-access-to-an-organization-repository)."
### About the repository-level security overview
At the repository-level, the security overview shows which security features are enabled for the repository, and offers the option to configure any available security features that are not currently enabled.
{% endif %}

5
content/code-security/security-overview/filtering-alerts-in-the-security-overview.md
View File

@@ -4,7 +4,6 @@ intro: Use filters to view specific categories of alerts
permissions: Organization owners and security managers can access the security overview for organizations. Members of a team can see the security overview for repositories that the team has admin privileges for.
product: '{% data reusables.gated-features.security-center %}'
versions:
fpt: '*'
ghae: issue-4554
ghes: '>3.1'
ghec: '*'
@@ -52,7 +51,7 @@ Available in the organization-level and team-level overview.
| Qualifier | Description |
| -------- | -------- |
{%- ifversion fpt or ghes or ghec %}
{%- ifversion ghes or ghec %}
| `is:public` | Display public repositories. |
{%- endif %}
{%- ifversion ghes or ghec or ghae %}
@@ -126,7 +125,7 @@ Available in the secret scanning alert views.
| Qualifier | Description |
| -------- | -------- |
| `secret-type:SERVICE_PROVIDER` | Displays alerts for the specified secret and provider. For more information, see "[{% data variables.product.prodname_secret_scanning_caps %} patterns](/code-security/secret-scanning/secret-scanning-patterns)." |
| `secret-type:CUSTOM-PATTERN` | Displays alerts for secrets matching the specified custom pattern. {% ifversion not fpt %}For more information, see "[Defining custom patterns for secret scanning](/code-security/secret-scanning/defining-custom-patterns-for-secret-scanning)."{% endif %} |
| `secret-type:CUSTOM-PATTERN` | Displays alerts for secrets matching the specified custom pattern. For more information, see "[Defining custom patterns for secret scanning](/code-security/secret-scanning/defining-custom-patterns-for-secret-scanning)." |
## Filter by provider

1
content/code-security/security-overview/viewing-the-security-overview.md
View File

@@ -4,7 +4,6 @@ intro: Navigate to the different views available in the security overview
permissions: Organization owners and security managers can access the security overview for organizations. Members of a team can see the security overview for repositories that the team has admin privileges for.
product: '{% data reusables.gated-features.security-center %}'
versions:
fpt: '*'
ghae: issue-5503
ghes: '>3.1'
ghec: '*'

4
content/codespaces/customizing-your-codespace/personalizing-codespaces-for-your-account.md
View File

@@ -87,9 +87,11 @@ You can use your selected dotfiles repository to personalize your {% data variab
You can add further script, preferences, configuration files to your dotfiles repository or edit existing files whenever you want. Changes to settings will only be picked up by new codespaces.
If your codespace fails to pick up configuration settings from dotfiles, see "[Troubleshooting dotfiles for {% data variables.product.prodname_codespaces %}](/codespaces/troubleshooting/troubleshooting-dotfiles-for-codespaces)."
## Other available settings
You can also personalize {% data variables.product.prodname_codespaces %} using additional [Codespaces settings](https://github.com/settings/codespaces):
You can also personalize {% data variables.product.prodname_codespaces %} using additional [{% data variables.product.prodname_codespaces %} settings](https://github.com/settings/codespaces):
- To set your default region, see "[Setting your default region for {% data variables.product.prodname_codespaces %}](/codespaces/managing-your-codespaces/setting-your-default-region-for-codespaces)."
- To set your editor, see "[Setting your default editor for {% data variables.product.prodname_codespaces %}](/codespaces/managing-your-codespaces/setting-your-default-editor-for-codespaces)."

2
content/developers/overview/managing-deploy-keys.md
View File

@@ -118,7 +118,7 @@ $ git clone git@{% ifversion fpt or ghec %}github.com{% else %}my-GHE-hostname.c
If your server needs to access repositories across one or more organizations, you can use a GitHub App to define the access you need, and then generate _tightly-scoped_, _server-to-server_ tokens from that GitHub App. The server-to-server tokens can be scoped to single or multiple repositories, and can have fine-grained permissions. For example, you can generate a token with read-only access to a repository's contents.
Since GitHub Apps are a first class actor on {% data variables.product.product_name %}, the server-to-server tokens are decoupled from any GitHub user, which makes them comparable to "service tokens". Additionally, server-to-server tokens have dedicated rate limits that scale with the size of the organizations that they act upon. For more information, see [Rate limits for Github Apps](/developers/apps/rate-limits-for-github-apps).
Since GitHub Apps are a first class actor on {% data variables.product.product_name %}, the server-to-server tokens are decoupled from any GitHub user, which makes them comparable to "service tokens". Additionally, server-to-server tokens have dedicated rate limits that scale with the size of the organizations that they act upon. For more information, see [Rate limits for {% data variables.product.prodname_github_apps %}](/developers/apps/rate-limits-for-github-apps).
#### Pros

9
content/github/site-policy-deprecated/github-enterprise-server-license-agreement.md
View File

@@ -8,12 +8,7 @@ versions:
fpt: '*'
---
_These terms apply to Customers who licensed the Products prior to January 4, 2021. Customers who purchase GitHub Products after that date are directed to https://www.github.com/enterprise-legal for current terms._
PLEASE READ THIS AGREEMENT CAREFULLY AS IT GOVERNS YOUR USE OF THE PRODUCTS (AS DEFINED BELOW), UNLESS WE HAVE EXECUTED A SEPARATE WRITTEN AGREEMENT WITH YOU FOR THAT PURPOSE.
BY CLICKING ON THE "I AGREE" OR SIMILAR BUTTON OR BY ACCESSING THE PRODUCTS, YOU ACCEPT ALL THE TERMS AND CONDITIONS OF THIS AGREEMENT. IF YOU ARE ENTERING INTO THIS AGREEMENT ON BEHALF OF A COMPANY OR OTHER LEGAL ENTITY (HEREINAFTER "**Customer**"), CUSTOMER REPRESENTS THAT IT HAS THE LEGAL AUTHORITY TO BIND THE COMPANY OR OTHER LEGAL ENTITY TO THIS AGREEMENT. GITHUB MAY MODIFY THIS AGREEMENT FROM TIME TO TIME, SUBJECT
TO SECTION 18.12.
_These terms apply to Customers who have executed agreements in place referencing them. All other corporate customers are directed to https://www.github.com/customer-terms for current terms._
This Agreement applies to the following GitHub offerings, as further defined below (collectively, the **“Products”**):
@@ -37,6 +32,8 @@ If Customer has purchased the Products from a GitHub Partner, the following prov
"**Beta Previews** means software, services, or features identified as alpha, beta, preview, early access, or evaluation, or words or phrases with similar meanings.
"**Customer**" means the company or organization that has entered into this Agreement with GitHub by clicking on the "I AGREE" or similar button or by accessing the Products.
"**Customer Modifications**" means Software modifications Customer may make solely for the purpose of developing bug fixes, customizations, or additional features to any libraries licensed under open source licenses that may be included with or linked to by the Software.
"**Documentation**" means any manuals, documentation and other supporting materials related to the Software that GitHub provides or makes available to Customer. Documentation is considered part of the Software.

4
content/github/site-policy-deprecated/github-enterprise-subscription-agreement.md
View File

@@ -9,9 +9,7 @@ versions:
fpt: '*'
---
_These terms apply to Customers who licensed the Products prior to January 4, 2021. Customers who purchase GitHub Products after that date are directed to https://www.github.com/enterprise-legal for current terms._
BY CLICKING THE "I AGREE" OR SIMILAR BUTTON OR BY USING ANY OF THE PRODUCTS (DEFINED BELOW), CUSTOMER ACCEPTS THE TERMS AND CONDITIONS OF THIS AGREEMENT. IF CUSTOMER IS ENTERING INTO THIS AGREEMENT ON BEHALF OF A LEGAL ENTITY, CUSTOMER REPRESENTS THAT IT HAS THE LEGAL AUTHORITY TO BIND THE LEGAL ENTITY TO THIS AGREEMENT.
_These terms apply to Customers who have executed agreements in place referencing them. All other corporate customers are directed to https://www.github.com/customer-terms for current terms._
This Agreement applies to the following GitHub offerings, as further defined below (collectively, the **"Products"**):

2
content/organizations/managing-saml-single-sign-on-for-your-organization/configuring-saml-single-sign-on-and-scim-using-okta.md
View File

@@ -41,7 +41,7 @@ Alternatively, you can configure SAML SSO for an enterprise using Okta. SCIM for
{% data reusables.saml.okta-provisioning-tab %}
{% data reusables.saml.okta-configure-api-integration %}
{% data reusables.saml.okta-enable-api-integration %}
1. Click **Authenticate with Github Enterprise Cloud - Organization**.
1. Click **Authenticate with {% data variables.product.prodname_ghe_cloud %} - Organization**.
1. To the right of your organization's name, click **Grant**.
!["Grant" button for authorizing Okta SCIM integration to access organization](/assets/images/help/saml/okta-scim-integration-grant-organization-access.png)

54
content/packages/managing-github-packages-using-github-actions-workflows/publishing-and-installing-a-package-with-github-actions.md
View File

@@ -102,12 +102,12 @@ jobs:
run-npm-build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: npm install and build webpack
run: |
npm install
npm run build
- uses: actions/upload-artifact@main
- uses: {% data reusables.actions.action-upload-artifact %}
with:
name: webpack artifacts
path: public/
@@ -119,13 +119,13 @@ jobs:
matrix:
os: [ubuntu-latest]
node-version: [12.x, 14.x]
steps: {% raw %}
- uses: actions/checkout@v2
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v2
steps:
- uses: {% data reusables.actions.action-checkout %}
- name: Use Node.js {% raw %}${{ matrix.node-version }}{% endraw %}
uses: {% data reusables.actions.action-setup-node %}
with:
node-version: ${{ matrix.node-version }}{% endraw %}
- uses: actions/download-artifact@main
node-version: {% raw %}${{ matrix.node-version }}{% endraw %}
- uses: {% data reusables.actions.action-download-artifact %}
with:
name: webpack artifacts
path: public
@@ -144,7 +144,7 @@ jobs:
packages: write {% endif %}
steps:
- name: Checkout
uses: actions/checkout@v2
uses: {% data reusables.actions.action-checkout %}
- name: Log in to GitHub Docker Registry
uses: docker/login-action@f054a8b539a109f9f41c372932f1ae047eff08c9
with:
@@ -214,22 +214,22 @@ jobs:
<tr>
<td>
{% raw %}
```yaml
run-npm-build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: {% data reusables.actions.action-checkout %}
- name: npm install and build webpack
run: |
npm install
npm run build
- uses: actions/upload-artifact@main
- uses: {% data reusables.actions.action-upload-artifact %}
with:
name: webpack artifacts
path: public/
```
{% endraw %}
</td>
<td>
This job installs NPM and uses it to build the app.
@@ -238,7 +238,7 @@ run-npm-build:
<tr>
<td>
{% raw %}
```yaml
run-npm-test:
runs-on: ubuntu-latest
@@ -248,12 +248,12 @@ run-npm-test:
os: [ubuntu-latest]
node-version: [12.x, 14.x]
steps:
- uses: actions/checkout@v2
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Use Node.js {% raw %}${{ matrix.node-version }}{% endraw %}
uses: {% data reusables.actions.action-setup-node %}
with:
node-version: ${{ matrix.node-version }}
- uses: actions/download-artifact@main
node-version: {% raw %}${{ matrix.node-version }}{% endraw %}
- uses: {% data reusables.actions.action-download-artifact %}
with:
name: webpack artifacts
path: public
@@ -264,7 +264,7 @@ run-npm-test:
env:
CI: true
```
{% endraw %}
</td>
<td>
This job uses <code>npm test</code> to test the code. The <code>needs: run-npm-build</code> command makes this job dependent on the <code>run-npm-build</code> job.
@@ -537,32 +537,32 @@ jobs:
packages: write
contents: read{% endif %}
{% raw %}steps:
- uses: actions/checkout@v2
steps:
- uses: {% data reusables.actions.action-checkout %}
- name: Build image
run: docker build . --file Dockerfile --tag $IMAGE_NAME --label "runnumber=${GITHUB_RUN_ID}"
- name: Log in to registry
# This is where you will update the PAT to GITHUB_TOKEN
run: echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin
run: echo "{% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin
- name: Push image
run: |
IMAGE_ID=ghcr.io/${{ github.repository_owner }}/$IMAGE_NAME
IMAGE_ID=ghcr.io/{% raw %}${{ github.repository_owner }}{% endraw %}/$IMAGE_NAME
# Change all uppercase to lowercase
IMAGE_ID=$(echo $IMAGE_ID | tr '[A-Z]' '[a-z]')
# Strip git ref prefix from version
VERSION=$(echo "${{ github.ref }}" | sed -e 's,.*/\(.*\),\1,')
VERSION=$(echo "{% raw %}${{ github.ref }}{% endraw %}" | sed -e 's,.*/\(.*\),\1,')
# Strip "v" prefix from tag name
[[ "${{ github.ref }}" == "refs/tags/"* ]] && VERSION=$(echo $VERSION | sed -e 's/^v//')
[[ "{% raw %}${{ github.ref }}{% endraw %}" == "refs/tags/"* ]] && VERSION=$(echo $VERSION | sed -e 's/^v//')
# Use Docker `latest` tag convention
[ "$VERSION" == "master" ] && VERSION=latest
echo IMAGE_ID=$IMAGE_ID
echo VERSION=$VERSION
docker tag $IMAGE_NAME $IMAGE_ID:$VERSION
docker push $IMAGE_ID:$VERSION{% endraw %}
docker push $IMAGE_ID:$VERSION
```
{% endif %}

8
content/packages/quickstart.md
View File

@@ -61,8 +61,8 @@ In this guide, you'll create a {% data variables.product.prodname_actions %} wor
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v2
- uses: {% data reusables.actions.action-checkout %}
- uses: {% data reusables.actions.action-setup-node %}
with:
node-version: 12
- run: npm ci
@@ -75,8 +75,8 @@ In this guide, you'll create a {% data variables.product.prodname_actions %} wor
packages: write
contents: read{% endif %}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v2
- uses: {% data reusables.actions.action-checkout %}
- uses: {% data reusables.actions.action-setup-node %}
with:
node-version: 12
registry-url: {% ifversion ghae %}https://npm.YOUR-HOSTNAME.com/{% else %}https://npm.pkg.github.com/{% endif %}

61
content/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/adding-a-pull-request-to-the-merge-queue.md
View File

@@ -1,61 +0,0 @@
---
title: Adding a pull request to the merge queue
intro: 'If merge queues are enabled for the repository, you can add your pull requests to the merge queue once all the required checks have passed. {% data variables.product.product_name %} will merge the pull requests for you.'
versions:
fpt: '*'
ghec: '*'
topics:
- Pull requests
shortTitle: Add PR to merge queue
redirect_from:
- /github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/adding-a-pull-request-to-the-merge-queue
---
{% data reusables.pull_requests.merge-queue-beta %}
## About pull request merge queue
{% data reusables.pull_requests.merge-queue-overview-short %}
{% data reusables.pull_requests.merge-queue-references %}
## Adding a pull request to the merge queue
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-pr %}
1. In the "Pull Requests" list, click the pull request you'd like to add to the merge queue.
1. Click **Add to merge queue** to add your pull request to the merge queue. This enables the default **Queue and merge in a group** option. Alternatively, you can:
- Add your pull request to the front of the queue by selecting the **Add to merge queue** drop down menu, and clicking **Jump the queue** (only available to repository maintainers and administrators).
- Directly merge your pull request by selecting the **Add to merge queue** drop down menu, and clicking **Directly merge** (only available to repository administrators).
![Merge queue options](/assets/images/help/pull_requests/merge-queue-options.png)
{% tip %}
**Tip:** The **Add to merge queue** button is only enabled once the pull request meets all the review/approval and status check requirements.
{% endtip %}
2. Confirm you want to add the pull request to the merge queue by clicking **Confirm add to merge queue**.
{% data variables.product.product_name %} adds the pull request to the merge queue and will merge it for you.
## Viewing the merge queue
You can view the merge queue in various places on {% data variables.product.product_name %}.
- On the **Branches** page for the repository. We recommend you use this route if you don't have or don't know about a pull request already in the queue, and if you want to see what's in the queue. For more information, see "[Viewing branches in your repository](/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/viewing-branches-in-your-repository)."
![View merge queue in Branches page](/assets/images/help/pull_requests/merge-queue-branches-page.png)
- On the **Pull requests** page of your repository, click {% octicon "clock" aria-label="The clock symbol" %}.
![View merge queue on Pull requests page](/assets/images/help/pull_requests/clock-icon-in-pull-request-list.png)
- On your pull request, scroll down to the section with the checks, and click **View merge queue**.
![View Merge queue button on pull request](/assets/images/help/pull_requests/view-merge-queue-button.png)
The merge queue view shows the pull requests that are currently in the queue, with your pull requests clearly marked.
![Merge queue view](/assets/images/help/pull_requests/merge-queue-view.png)
## Handling pull requests removed from the merge queue
{% data reusables.pull_requests.merge-queue-reject %}

2
content/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/index.md
View File

@@ -16,7 +16,7 @@ children:
- /about-pull-request-merges
- /merging-a-pull-request
- /automatically-merging-a-pull-request
- /adding-a-pull-request-to-the-merge-queue
- /merging-a-pull-request-with-a-merge-queue
- /closing-a-pull-request
- /reverting-a-pull-request
shortTitle: Incorporate changes

74
content/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request-with-a-merge-queue.md Normal file
View File

@@ -0,0 +1,74 @@
---
title: Merging a pull request with a merge queue
intro: 'If a merge queue is required by the branch protection setting for the branch, you can add your pull requests to a merge queue and {% data variables.product.product_name %} will merge the pull requests for you once all required checks have passed.'
versions:
fpt: '*'
ghec: '*'
topics:
- Pull requests
shortTitle: Merge PR with merge queue
redirect_from:
- /pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/adding-a-pull-request-to-the-merge-queue
---
{% data reusables.pull_requests.merge-queue-beta %}
## About merge queues
{% data reusables.pull_requests.merge-queue-overview %}
{% data reusables.pull_requests.merge-queue-references %}
## Adding a pull request to a merge queue
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-pr %}
1. In the "Pull Requests" list, click the pull request you would like to add to a merge queue.
1. Click **Merge when ready** to add the pull request to the merge queue. Alternatively, if you are an administrator, you can:
- Directly merge the pull request by checking **Merge without waiting for requirements to be met (administrators only)**, if allowed by branch protection settings, and follow the standard flow.
![Merge queue options](/assets/images/help/pull_requests/merge-queue-options.png)
{% tip %}
**Tip:** You can click **Merge when ready** whenever you're ready to merge your proposed changes. {% data variables.product.product_name %} will automatically add the pull request to the merge queue once required approval and status checks conditions are met.
{% endtip %}
1. Confirm you want to add the pull request to the merge queue by clicking **Confirm merge when ready**.
## Removing a pull request from a merge queue
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-pr %}
1. In the "Pull Requests" list, click the pull request you would like to remove from a merge queue.
1. To remove the pull request from the queue, click **Remove from queue**.
![Remove pull request from queue](/assets/images/help/pull_requests/remove-from-queue-button.png)
Alternatively, you can navigate to the merge queue page for the base branch, click **...** next to the pull request you want to remove, and select **Remove from queue**. For information on how to get to the merge queue page for the base branch, see the section below.
## Viewing merge queues
You can view the merge queue for a base branch in various places on {% data variables.product.product_name %}.
- On the **Branches** page for the repository. We recommend you use this route if you don't have or don't know about a pull request already in a queue, and if you want to see what's in that queue. For more information, see "[Viewing branches in your repository](/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/viewing-branches-in-your-repository)."
![View merge queue in Branches page](/assets/images/help/pull_requests/merge-queue-branches-page.png)
- On the **Pull requests** page of your repository, click {% octicon "clock" aria-label="The clock symbol" %} next to any pull request in the merge queue.
![View merge queue on Pull requests page](/assets/images/help/pull_requests/clock-icon-in-pull-request-list.png)
- On the pull request page when merge queue is required for merging, scroll to the bottom of the timeline and click **the merge queue** link.
![Merge queue link on pull request](/assets/images/help/pull_requests/merge-queue-link.png)
- The merge queue view shows the pull requests that are currently in the queue, with your pull requests clearly marked.
![Merge queue view](/assets/images/help/pull_requests/merge-queue-view.png)
## Handling pull requests removed from the merge queue
{% data reusables.pull_requests.merge-queue-reject %}

2
content/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/index.md
View File

@@ -15,7 +15,7 @@ children:
- /about-merge-methods-on-github
- /configuring-commit-squashing-for-pull-requests
- /configuring-commit-rebasing-for-pull-requests
- /using-a-merge-queue
- /managing-a-merge-queue
- /managing-suggestions-to-update-pull-request-branches
- /managing-auto-merge-for-pull-requests-in-your-repository
- /managing-the-automatic-deletion-of-branches

58
content/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue.md Normal file
View File

@@ -0,0 +1,58 @@
---
title: Managing a merge queue
intro: You can increase development velocity with a merge queue for pull requests in your repository.
versions:
fpt: '*'
ghec: '*'
permissions: People with admin permissions can manage merge queues for pull requests targeting selected branches of a repository.
topics:
- Repositories
- Pull requests
shortTitle: Managing merge queue
redirect_from:
- /repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/using-a-merge-queue
---
{% data reusables.pull_requests.merge-queue-beta %}
## About merge queues
{% data reusables.pull_requests.merge-queue-overview %}
The merge queue creates temporary branches with a special prefix to validate pull request changes. The changes in the pull request are then grouped with the latest version of the `base_branch` as well as changes ahead of it in the queue. {% data variables.product.product_name %} will merge all these changes into `base_branch` once the checks required by the branch protections of `base_branch` pass.
You may need to update your Continuous Integration (CI) configuration to trigger builds on branch names that begin with the special prefix `gh-readonly-queue/{base_branch}` after the group is created.
For example, with {% data variables.product.prodname_actions %}, a workflow with the following trigger will run each time a pull request that targets the base branch `main` is queued to merge.
```yaml
on:
push:
branches:
- gh-readonly-queue/main/**
```
{% data reusables.pull_requests.merge-queue-merging-method %}
For information about merge methods, see "[About pull request merges](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges)."
{% note %}
**Note:**
* A merge queue cannot be enabled with branch protection rules that use wildcard characters (`*`) in the branch name pattern.
{% endnote %}
{% data reusables.pull_requests.merge-queue-reject %}
## Managing a merge queue
Repository administrators can require a merge by enabling the branch protection setting "Require merge queue" in the protection rules for the base branch.
For information about how to enable the merge queue protection setting, see "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule#creating-a-branch-protection-rule)."
## Further reading
* "[Merging a pull request with a merge queue](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request-with-a-merge-queue)"
* "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)"

55
content/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/using-a-merge-queue.md
View File

@@ -1,55 +0,0 @@
---
title: Using a merge queue
intro: You can increase development velocity by enabling merge queues for pull requests in your repository.
versions:
fpt: '*'
ghec: '*'
permissions: People with admin permissions can configure merge queues for pull requests targeting selected branches of a repository.
topics:
- Repositories
- Pull requests
shortTitle: Use merge queue
---
{% data reusables.pull_requests.merge-queue-beta %}
## About pull request merge queue
{% data reusables.pull_requests.merge-queue-overview %}
The merge queue creates temporary preparatory branches to validate pull requests against the latest version of the base branch. To ensure that {% data variables.product.prodname_dotcom %} validates these preparatory branches, you may need to update your CI configuration to trigger builds on branch names starting with `gh-readonly-queue/{base_branch}`.
For example, with {% data variables.product.prodname_actions %}, adding the following trigger to a workflow will cause the workflow to run when any push is made to a merge queue preparatory branch that targets `main`.
```
on:
push:
branches:
- main
- gh-readonly-queue/main/**
```
{% data reusables.pull_requests.merge-queue-merging-method %}
For information about merge methods, see "[About pull request merges](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges)." For information about the "Require linear history" branch protection setting, see "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-linear-history)."
{% note %}
**Note:** During the beta, there are some limitations when using the merge queue:
* The merge queue cannot be enabled on branch protection rules using wildcards (`*`) in the name.
* There is no support for squash merge commits. (Only merge commits and "rebase and merge" commits are supported.)
{% endnote %}
{% data reusables.pull_requests.merge-queue-reject %}
## Managing pull request merge queue
Repository administrators can configure merge queues for pull requests targeting selected branches of a repository. The requirement to use a merge queue is a branch protection setting called "Require merge queue" that can be enabled in branch protection rules.
For information about how to enable the merge queue protection setting, see "[Managing a branch protection rule](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule#creating-a-branch-protection-rule)."
## Further reading
- "[Adding a pull request to the merge queue](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/adding-a-pull-request-to-the-merge-queue)"
- "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)"

8
content/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/troubleshooting-required-status-checks.md
View File

@@ -69,11 +69,11 @@ jobs:
matrix:
node-version: [12.x, 14.x, 16.x]
steps:
- uses: actions/checkout@v2
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v2
- uses: {% data reusables.actions.action-checkout %}
- name: Use Node.js {% raw %}${{ matrix.node-version }}{% endraw %}
uses: {% data reusables.actions.action-setup-node %}
with:
node-version: ${{ matrix.node-version }}
node-version: {% raw %}${{ matrix.node-version }}{% endraw %}
cache: 'npm'
- run: npm ci
- run: npm run build --if-present

22
content/rest/overview/api-previews.md
View File

@@ -4,10 +4,8 @@ intro: You can use API previews to try out new features and provide feedback bef
redirect_from:
- /v3/previews
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- API
---
@@ -130,17 +128,6 @@ You can now [require multiple approving reviews](/rest/reference/repos#branches)
{% endif %}
{% ifversion ghes %}
## Anonymous Git access to repositories
When a {% data variables.product.prodname_ghe_server %} instance is in private mode, site and repository administrators can enable anonymous Git access for a public repository.
**Custom media type:** `x-ray-preview`
**Announced:** [2018-07-12](https://blog.github.com/2018-07-12-introducing-enterprise-2-14/)
{% endif %}
{% ifversion ghes < 3.3 %}
## Project card details
@@ -150,15 +137,6 @@ The REST API responses for [issue events](/rest/reference/issues#events) and [is
**Custom media type:** `starfox-preview`
**Announced:** [2018-09-05](https://developer.github.com/changes/2018-09-05-project-card-events)
{% endif %}
{% ifversion fpt or ghec %}
## GitHub App Manifests
GitHub App Manifests allow people to create preconfigured GitHub Apps. See "[Creating GitHub Apps from a manifest](/apps/building-github-apps/creating-github-apps-from-a-manifest/)" for more details.
**Custom media type:** `fury-preview`
{% endif %}
{% ifversion ghes < 3.3 %}

4
content/site-policy/acceptable-use-policies/github-acceptable-use-policies.md
View File

@@ -109,4 +109,6 @@ We will interpret our policies and resolve disputes in favor of protecting users
---
GitHub retains full discretion to [take action](/github/site-policy/github-community-guidelines#what-happens-if-someone-violates-githubs-policies) in response to a violation of these policies, including account suspension, account [termination](/github/site-policy/github-terms-of-service#3-github-may-terminate), or [removal](/github/site-policy/github-terms-of-service#2-github-may-remove-content) of content.
**Enforcement.** GitHub retains full discretion to [take action](/github/site-policy/github-community-guidelines#what-happens-if-someone-violates-githubs-policies) in response to a violation of these policies, including account suspension, account [termination](/github/site-policy/github-terms-of-service#3-github-may-terminate), or [removal](/github/site-policy/github-terms-of-service#2-github-may-remove-content) of content. Please also see our [Community Guidelines](/site-policy/github-terms/github-community-guidelines) for actions you can take if something or someone offends you.
**Reinstatement and appeal.** If your content or account has been disabled or restricted and you seek reinstatement or wish to appeal, please see our [Appeal and Reinstatement page](/site-policy/acceptable-use-policies/github-appeal-and-reinstatement) for information about the process and use our [Appeal and Reinstatement form](https://support.github.com/contact/reinstatement) to submit a request.

Some files were not shown because too many files have changed in this diff Show More