jprdonnelly/docs
1
0
Fork 0
mirror of synced 2026-01-06 06:02:35 -05:00
Code Issues Projects Releases Wiki Activity

Merge branch 'main' into patch-3

Browse Source
This commit is contained in:
mc
2023-01-10 08:39:51 +00:00
committed by GitHub
parent 994a2e26e4 559adc8696
commit c39cc16287
162 changed files with 29423 additions and 8535878 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
.devcontainer/devcontainer.json
View File

@@ -17,7 +17,6 @@
// Install features. Type 'feature' in the VS Code command palette for a full list.
"features": {
"git-lfs": "latest",
"sshd": "latest"
},
@@ -42,7 +41,7 @@
},
// Use 'postCreateCommand' to run commands after the container is created.
"postCreateCommand": "git lfs pull && npm ci",
"postCreateCommand": "npm ci",
// Comment out connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.
"remoteUser": "node"

2
.github/actions-scripts/enterprise-server-issue-templates/release-issue.md vendored
View File

@@ -101,7 +101,7 @@ This file should be automatically updated, but you can also run `script/update-e
### 🚢 🛳️ 🚢 Shipping the release branch
- [ ] The megabranch creator should push the search index LFS objects for the public `github/docs` repo. The LFS objects were already pushed for the internal repo after the `sync-english-index-for-<PLAN@RELEASE>` was added to the megabranch. To push the LFS objects to the public repo:
- [ ] Sync the search indices for the new release:
1. First navigate to the [sync search indices workflow](https://github.com/github/docs-internal/actions/workflows/sync-search-indices.yml).
2. Then, to run the workflow with parameters, click on `Run workflow` button.
3. A modal will pop up where you will set the following inputs:

22
.github/actions/node-npm-setup/action.yml vendored Normal file
View File

@@ -0,0 +1,22 @@
name: Node set up composite
description: Will set up Node and install all packages by caching node_modules
runs:
using: 'composite'
steps:
- name: Cache node_modules
uses: actions/cache@9b0c1fce7a93df8e3bb8926b0d6e9d89e92f20a7
with:
path: node_modules
key: ${{ runner.os }}-node_modules-${{ hashFiles('package*.json') }}
- name: Setup node
uses: actions/setup-node@8c91899e586c5b171469028077307d293428b516
with:
node-version: '16.17.0'
cache: npm
- name: Install dependencies
shell: bash
run: npm install --prefer-offline --no-audit --ignore-scripts

5
.github/workflows/azure-preview-env-deploy.yml vendored
View File

@@ -91,7 +91,6 @@ jobs:
with:
ref: 'main'
persist-credentials: 'false'
lfs: 'true'
- if: ${{ env.IS_INTERNAL_BUILD == 'true' }}
name: Check out PR code
@@ -100,10 +99,6 @@ jobs:
ref: ${{ env.COMMIT_REF }}
# To prevent issues with cloning early access content later
persist-credentials: 'false'
lfs: 'true'
- name: Check out LFS objects
run: git lfs checkout
- name: Get preview app info
env:

16
.github/workflows/azure-prod-build-deploy.yml vendored
View File

@@ -127,22 +127,6 @@ jobs:
token: ${{ secrets.DOCUBOT_REPO_PAT }}
path: translations/ko-kr
# As of Dec 2022, we still have checked in translations into
# the main repo.
# We're going to remove that later.
# For now, just delete the excess directories so they don't add
# unnecessary weight to the container image.
- name: Delete old checked in translation directories (TEMPORARY)
run: |
rm -fr translations/zh-CN
rm -fr translations/ja-JP
rm -fr translations/es-ES
rm -fr translations/pt-BR
rm -fr translations/de-DE
rm -fr translations/fr-FR
rm -fr translations/ru-RU
rm -fr translations/ko-KR
- name: 'Build and push image'
uses: docker/build-push-action@1cb9d22b932e4832bb29793b7777ec860fc1cde0
with:

4
.github/workflows/azure-staging-build-deploy.yml vendored
View File

@@ -65,10 +65,6 @@ jobs:
ref: ${{ env.COMMIT_REF }}
# To prevent issues with cloning early access content later
persist-credentials: 'false'
lfs: 'true'
- name: Check out LFS objects
run: git lfs checkout
- name: 'Set env vars'
run: |

5
.github/workflows/browser-test.yml vendored
View File

@@ -50,11 +50,6 @@ jobs:
- name: Checkout
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
with:
lfs: true
- name: Checkout LFS objects
run: git lfs checkout
- name: Setup Node
uses: actions/setup-node@8c91899e586c5b171469028077307d293428b516

9
.github/workflows/check-broken-links-github-github.yml vendored
View File

@@ -52,17 +52,10 @@ jobs:
path: docs-early-access
ref: main
- name: Setup Node
uses: actions/setup-node@8c91899e586c5b171469028077307d293428b516
with:
node-version: '16.17.0'
cache: npm
- name: Merge docs-early-access repo's folders
run: .github/actions-scripts/merge-early-access.sh
- name: Install Node.js dependencies
run: npm ci
- uses: ./.github/actions/node-npm-setup
- name: Build server
run: npm run build

17
.github/workflows/code-lint.yml vendored
View File

@@ -34,25 +34,12 @@ concurrency:
jobs:
lint:
if: github.repository == 'github/docs-internal' || github.repository == 'github/docs'
runs-on: ubuntu-latest
runs-on: ${{ fromJSON('["ubuntu-latest", "ubuntu-20.04-xl"]')[github.repository == 'github/docs-internal'] }}
steps:
- name: Check out repo
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
- name: Cache node_modules
uses: actions/cache@9b0c1fce7a93df8e3bb8926b0d6e9d89e92f20a7
with:
path: node_modules
key: ${{ runner.os }}-node_modules-${{ hashFiles('package*.json') }}
- name: Setup node
uses: actions/setup-node@8c91899e586c5b171469028077307d293428b516
with:
node-version: '16.17.0'
cache: npm
- name: Install dependencies
run: npm install --prefer-offline --no-audit --ignore-scripts
- uses: ./.github/actions/node-npm-setup
- name: Run linter
run: npm run lint

2
.github/workflows/content-changes-table-comment.yml vendored
View File

@@ -75,7 +75,7 @@ jobs:
run: .github/actions-scripts/content-changes-table-comment.js
- name: Find content directory changes comment
uses: peter-evans/find-comment@1769778a0c5bd330272d749d12c036d65e70d39d
uses: peter-evans/find-comment@f4499a714d59013c74a08789b48abe4b704364a0
id: findComment
with:
issue-number: ${{ github.event.pull_request.number }}

11
.github/workflows/enterprise-dates.yml vendored
View File

@@ -38,14 +38,7 @@ jobs:
- name: Checkout repository code
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
- name: Setup Node
uses: actions/setup-node@8c91899e586c5b171469028077307d293428b516
with:
node-version: '16.17.0'
cache: npm
- name: Install Node.js dependencies
run: npm ci
- uses: ./.github/actions/node-npm-setup
- name: Run script/update-enterprise-dates.js
run: |
@@ -55,7 +48,7 @@ jobs:
- name: Create pull request
id: create-pull-request
uses: peter-evans/create-pull-request@bd72e1b7922d417764d27d30768117ad7da78a0e
uses: peter-evans/create-pull-request@2b011faafdcbc9ceb11414d64d0573f37c774b04
env:
# Disable pre-commit hooks; they don't play nicely here
HUSKY: '0'

15
.github/workflows/keep-caches-warm.yml vendored
View File

@@ -23,20 +23,7 @@ jobs:
- name: Check out repo
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
- name: Cache node_modules
uses: actions/cache@9b0c1fce7a93df8e3bb8926b0d6e9d89e92f20a7
with:
path: node_modules
key: ${{ runner.os }}-node_modules-${{ hashFiles('package*.json') }}
- name: Setup node
uses: actions/setup-node@8c91899e586c5b171469028077307d293428b516
with:
node-version: '16.17.0'
cache: npm
- name: Install dependencies
run: npm install --prefer-offline --no-audit --ignore-scripts
- uses: ./.github/actions/node-npm-setup
- name: Cache nextjs build
uses: actions/cache@9b0c1fce7a93df8e3bb8926b0d6e9d89e92f20a7

8
.github/workflows/link-check-daily.yml vendored
View File

@@ -24,14 +24,8 @@ jobs:
- name: Check out repo's default branch
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
- name: Setup Node
uses: actions/setup-node@8c91899e586c5b171469028077307d293428b516
with:
node-version: '16.17.0'
cache: npm
- name: Install dependencies
run: npm ci
- uses: ./.github/actions/node-npm-setup
- name: Figure out which docs-early-access branch to checkout, if internal repo
if: ${{ github.repository == 'github/docs-internal' }}

15
.github/workflows/link-check-on-pr.yml vendored
View File

@@ -28,20 +28,7 @@ jobs:
- name: Checkout
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
- name: Cache node_modules
uses: actions/cache@9b0c1fce7a93df8e3bb8926b0d6e9d89e92f20a7
with:
path: node_modules
key: ${{ runner.os }}-node_modules-${{ hashFiles('package*.json') }}
- name: Setup node
uses: actions/setup-node@8c91899e586c5b171469028077307d293428b516
with:
node-version: '16.17.0'
cache: npm
- name: Install dependencies
run: npm install --prefer-offline --no-audit --ignore-scripts
- uses: ./.github/actions/node-npm-setup
- name: Figure out which docs-early-access branch to checkout, if internal repo
if: ${{ github.repository == 'github/docs-internal' }}

4
.github/workflows/main-preview-docker-cache.yml vendored
View File

@@ -49,10 +49,6 @@ jobs:
with:
# To prevent issues with cloning early access content later
persist-credentials: 'false'
lfs: 'true'
- name: Check out LFS objects
run: git lfs checkout
- if: ${{ env.ENABLE_EARLY_ACCESS }}
name: Clone docs-early-access

3
.github/workflows/manually-purge-fastly.yml vendored
View File

@@ -18,8 +18,7 @@ jobs:
- name: Check out repo
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
- name: Install dependencies
run: npm ci
- uses: ./.github/actions/node-npm-setup
- name: Soft-purge Fastly cache
env:

9
.github/workflows/open-enterprise-issue.yml vendored
View File

@@ -21,14 +21,7 @@ jobs:
- name: Checkout repository code
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
- name: Setup Node
uses: actions/setup-node@8c91899e586c5b171469028077307d293428b516
with:
node-version: '16.17.0'
cache: npm
- name: Install dependencies
run: npm ci
- uses: ./.github/actions/node-npm-setup
- name: Check for existing release or deprecation issues
id: existingIssue

9
.github/workflows/openapi-decorate.yml vendored
View File

@@ -45,14 +45,7 @@ jobs:
# CI in the PR. (Events from GITHUB_TOKEN don't trigger new workflows.)
token: ${{ secrets.DOCUBOT_REPO_PAT }}
- name: Setup node
uses: actions/setup-node@8c91899e586c5b171469028077307d293428b516
with:
node-version: '16.17.0'
cache: npm
- name: Install dependencies
run: npm ci
- uses: ./.github/actions/node-npm-setup
- name: Decorate the dereferenced OpenAPI schemas
run: script/rest/update-files.js --decorate-only

9
.github/workflows/orphaned-assets-check.yml vendored
View File

@@ -85,14 +85,7 @@ jobs:
token: ${{ secrets.DOCUBOT_READORG_REPO_WORKFLOW_SCOPES }}
path: translations/ko-KR
- name: Setup node
uses: actions/setup-node@8c91899e586c5b171469028077307d293428b516
with:
node-version: '16.17.0'
cache: npm
- name: Install
run: npm ci
- uses: ./.github/actions/node-npm-setup
- name: Check for orphaned assets
env:

9
.github/workflows/purge-fastly.yml vendored
View File

@@ -35,14 +35,7 @@ jobs:
- name: Check out repo
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
- name: Setup node
uses: actions/setup-node@8c91899e586c5b171469028077307d293428b516
with:
node-version: '16.17.0'
cache: npm
- name: Install dependencies
run: npm ci
- uses: ./.github/actions/node-npm-setup
- name: Purge Fastly edge cache independent of language
if: ${{ github.event.inputs.nuke_all }}

5
.github/workflows/repo-sync.yml vendored
View File

@@ -100,7 +100,10 @@ jobs:
- name: Check out repo
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
# Set up npm and run npm ci to run husky to get githooks for LFS
# Set up npm and run npm ci to get custom husky githooks error
# messages if they exist. We could also remove these two steps
# because currently we have no hooks with customer error messages.
# See pull #32064 where they were removed.
- name: Setup node
uses: actions/setup-node@8c91899e586c5b171469028077307d293428b516
with:

9
.github/workflows/sync-search-elasticsearch.yml vendored
View File

@@ -118,14 +118,7 @@ jobs:
token: ${{ secrets.DOCUBOT_READORG_REPO_WORKFLOW_SCOPES }}
path: translation
- name: Setup Node
uses: actions/setup-node@8c91899e586c5b171469028077307d293428b516
with:
node-version: '16.17.0'
cache: npm
- name: Install dependencies
run: npm ci
- uses: ./.github/actions/node-npm-setup
- name: Cache nextjs build
uses: actions/cache@9b0c1fce7a93df8e3bb8926b0d6e9d89e92f20a7

15
.github/workflows/sync-search-pr.yml vendored
View File

@@ -46,20 +46,7 @@ jobs:
- name: Check out repo
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
- name: Cache node_modules
uses: actions/cache@9b0c1fce7a93df8e3bb8926b0d6e9d89e92f20a7
with:
path: node_modules
key: ${{ runner.os }}-node_modules-${{ hashFiles('package*.json') }}
- name: Setup node
uses: actions/setup-node@8c91899e586c5b171469028077307d293428b516
with:
node-version: '16.17.0'
cache: npm
- name: Install dependencies
run: npm install --prefer-offline --no-audit --ignore-scripts
- uses: ./.github/actions/node-npm-setup
- name: Cache nextjs build
uses: actions/cache@9b0c1fce7a93df8e3bb8926b0d6e9d89e92f20a7

23
.github/workflows/test.yml vendored
View File

@@ -66,24 +66,8 @@ jobs:
# Even if if doesn't do anything
- name: Check out repo
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
with:
# Not all test suites need the LFS files. So instead, we opt to
# NOT clone them initially and instead, include them manually
# only for the test groups that we know need the files.
lfs: ${{ matrix.test-group == 'content' }}
# Enables cloning the Early Access repo later with the relevant PAT
# persist-credentials: 'false'
# ->> Do we really need this? actions/checkout doesn't use it for the nested example:
# https://github.com/actions/checkout#checkout-multiple-repos-nested
- name: Setup node
uses: actions/setup-node@8c91899e586c5b171469028077307d293428b516
with:
node-version: '16.17.0'
cache: npm
- name: Install dependencies
run: npm ci
- uses: ./.github/actions/node-npm-setup
- name: Figure out which docs-early-access branch to checkout, if internal repo
if: ${{ github.repository == 'github/docs-internal' }}
@@ -172,11 +156,6 @@ jobs:
token: ${{ secrets.DOCUBOT_REPO_PAT }}
path: translations/ko-kr
# This is necessary when LFS files where cloned but does nothing
# if actions/checkout was run with `lfs:false`.
- name: Checkout LFS objects
run: git lfs checkout
- name: Gather files changed
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

8
.github/workflows/translation-health-report.yml vendored
View File

@@ -72,13 +72,7 @@ jobs:
gitref=$(cd ${{ matrix.language_dir }} && git rev-parse --short HEAD)
echo "gitref=$gitref" >> $GITHUB_ENV
- name: 'Setup node'
uses: actions/setup-node@8c91899e586c5b171469028077307d293428b516
with:
node-version: '16.17.0'
- name: npm ci
run: npm ci
- uses: ./.github/actions/node-npm-setup
- name: Create translation health report
run: |

10
.github/workflows/update-graphql-files.yml vendored
View File

@@ -33,13 +33,7 @@ jobs:
exit 1 # prevents further steps from running
- name: Checkout
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
- name: Setup Node
uses: actions/setup-node@8c91899e586c5b171469028077307d293428b516
with:
node-version: '16.17.0'
cache: npm
- name: Install Node.js dependencies
run: npm ci
- uses: ./.github/actions/node-npm-setup
- name: Run updater scripts
env:
# need to use a token from a user with access to github/github for this step
@@ -48,7 +42,7 @@ jobs:
script/graphql/update-files.js
- name: Create pull request
id: create-pull-request
uses: peter-evans/create-pull-request@bd72e1b7922d417764d27d30768117ad7da78a0e
uses: peter-evans/create-pull-request@2b011faafdcbc9ceb11414d64d0573f37c774b04
env:
# Disable pre-commit hooks; they don't play nicely here
HUSKY: '0'

1
.gitignore vendored
View File

@@ -14,6 +14,7 @@ coverage/
.next
.eslintcache
*.tsbuildinfo
translations/
# blc: broken link checker
blc_output.log

8
CONTRIBUTING.md
View File

@@ -48,9 +48,7 @@ For more information about using a codespace for working on GitHub documentation
#### Make changes locally
1. [Install Git LFS](https://docs.github.com/en/github/managing-large-files/versioning-large-files/installing-git-large-file-storage).
2. Fork the repository.
1. Fork the repository.
- Using GitHub Desktop:
- [Getting started with GitHub Desktop](https://docs.github.com/en/desktop/installing-and-configuring-github-desktop/getting-started-with-github-desktop) will guide you through setting up Desktop.
- Once Desktop is set up, you can use it to [fork the repo](https://docs.github.com/en/desktop/contributing-and-collaborating-using-github-desktop/cloning-and-forking-repositories-from-github-desktop)!
@@ -58,9 +56,9 @@ For more information about using a codespace for working on GitHub documentation
- 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.
3. Install or update to **Node.js v16**. For more information, see [the development guide](contributing/development.md).
2. 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!
3. Create a working branch and start with your changes!
### Commit your update

BIN
assets/images/help/organizations/actions-organization-secrets-tab.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 53 KiB

BIN
assets/images/help/organizations/actions-organization-variables-tab.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 48 KiB

BIN
assets/images/help/repository/actions-secrets-tab.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 51 KiB

BIN
assets/images/help/repository/actions-variables-tab.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 47 KiB

BIN
assets/images/help/security/advanced-code-scanning-setup.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 116 KiB

BIN
assets/images/help/security/default-code-scanning-setup.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 115 KiB

BIN
assets/images/help/security/enable-codeql-default-setup.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 61 KiB

BIN
assets/images/help/settings/actions-required-workflow-locate.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 23 KiB

BIN
assets/images/help/settings/actions-required-workflows-add.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 23 KiB

BIN
assets/images/help/settings/actions-required-workflows-repos.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 33 KiB

BIN
assets/images/help/settings/actions-required-workflows-select-repos.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 27 KiB

BIN
assets/images/help/settings/example-required-workflow.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 62 KiB

BIN
assets/images/help/settings/view-required-workflows.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 12 KiB

4
content/actions/creating-actions/dockerfile-support-for-github-actions.md
View File

@@ -25,7 +25,7 @@ Some Docker instructions interact with GitHub Actions, and an action's metadata
### USER
Docker actions must be run by the default Docker user (root). Do not use the `USER` instruction in your `Dockerfile`, because you won't be able to access the `GITHUB_WORKSPACE`. For more information, see "[Using environment variables](/actions/configuring-and-managing-workflows/using-environment-variables)" and [USER reference](https://docs.docker.com/engine/reference/builder/#user) in the Docker documentation.
Docker actions must be run by the default Docker user (root). Do not use the `USER` instruction in your `Dockerfile`, because you won't be able to access the `GITHUB_WORKSPACE`. For more information, see "[Variables](/actions/learn-github-actions/variables#default-environment-variables)" and [USER reference](https://docs.docker.com/engine/reference/builder/#user) in the Docker documentation.
### FROM
@@ -39,7 +39,7 @@ These are some best practices when setting the `FROM` argument:
### WORKDIR
{% data variables.product.product_name %} sets the working directory path in the `GITHUB_WORKSPACE` environment variable. It's recommended to not use the `WORKDIR` instruction in your `Dockerfile`. Before the action executes, {% data variables.product.product_name %} will mount the `GITHUB_WORKSPACE` directory on top of anything that was at that location in the Docker image and set `GITHUB_WORKSPACE` as the working directory. For more information, see "[Using environment variables](/actions/configuring-and-managing-workflows/using-environment-variables)" and the [WORKDIR reference](https://docs.docker.com/engine/reference/builder/#workdir) in the Docker documentation.
{% data variables.product.product_name %} sets the working directory path in the `GITHUB_WORKSPACE` environment variable. It's recommended to not use the `WORKDIR` instruction in your `Dockerfile`. Before the action executes, {% data variables.product.product_name %} will mount the `GITHUB_WORKSPACE` directory on top of anything that was at that location in the Docker image and set `GITHUB_WORKSPACE` as the working directory. For more information, see "[Variables](/actions/learn-github-actions/variables#default-environment-variables)" and the [WORKDIR reference](https://docs.docker.com/engine/reference/builder/#workdir) in the Docker documentation.
### ENTRYPOINT

2
content/actions/hosting-your-own-runners/running-scripts-before-or-after-a-job.md
View File

@@ -29,7 +29,7 @@ The following scripting languages are supported:
Your custom scripts can use the following features:
- **Environment variables**: Scripts have access to the default environment variables. The full webhook event payload can be found in `GITHUB_EVENT_PATH`. For more information, see "[Environment variables](/actions/learn-github-actions/environment-variables#default-environment-variables)."
- **Variables**: Scripts have access to the default variables. The full webhook event payload can be found in `GITHUB_EVENT_PATH`. For more information, see "[Variables](/actions/learn-github-actions/variables#default-environment-variables)."
- **Workflow commands**: Scripts can use workflow commands. For more information, see ["Workflow commands for {% data variables.product.prodname_actions %}"](/actions/using-workflows/workflow-commands-for-github-actions){% ifversion actions-save-state-set-output-envs %}{% else %}, with the exception of `save-state` and `set-output`, which are not supported by these scripts{% endif %}. Scripts can also use environment files. For more information, see [Environment files](/actions/using-workflows/workflow-commands-for-github-actions#environment-files).
{% note %}

2
content/actions/index.md
View File

@@ -24,7 +24,7 @@ featuredLinks:
- /actions/learn-github-actions/events-that-trigger-workflows
- /actions/learn-github-actions/contexts
- /actions/learn-github-actions/expressions
- /actions/learn-github-actions/environment-variables
- /actions/learn-github-actions/variables
- /actions/security-guides/encrypted-secrets
changelog:
label: actions

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

@@ -21,7 +21,7 @@ miniTocMaxHeadingLevel: 3
## About contexts
Contexts are a way to access information about workflow runs, runner environments, jobs, and steps. Each context is an object that contains properties, which can be strings or other objects.
{% data reusables.actions.actions-contexts-about-description %} Each context is an object that contains properties, which can be strings or other objects.
{% data reusables.actions.context-contents %} For example, the `matrix` context is only populated for jobs in a [matrix](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix).
@@ -36,7 +36,9 @@ You can access contexts using the expression syntax. For more information, see "
| Context name | Type | Description |
|---------------|------|-------------|
| `github` | `object` | Information about the workflow run. For more information, see [`github` context](#github-context). |
| `env` | `object` | Contains environment variables set in a workflow, job, or step. For more information, see [`env` context](#env-context). |
| `env` | `object` | Contains variables set in a workflow, job, or step. For more information, see [`env` context](#env-context). |
{%- ifversion actions-configuration-variables %}
| `vars` | `object` | Contains variables set at the repository, organization, or environment levels. For more information, see [`vars` context](#vars-context). |{% endif %}
| `job` | `object` | Information about the currently running job. For more information, see [`job` context](#job-context). |
{%- ifversion fpt or ghes > 3.3 or ghae > 3.3 or ghec %}
| `jobs` | `object` | For reusable workflows only, contains outputs of jobs from the reusable workflow. For more information, see [`jobs` context](#jobs-context). |{% endif %}
@@ -75,40 +77,40 @@ The following table indicates where each context and special function can be use
| Workflow key | Context | Special functions |
| ---- | ------- | ----------------- |
{%- ifversion actions-run-name %}
| <code>run-name</code> | <code>github, inputs</code> | |
| <code>run-name</code> | <code>github, inputs{% ifversion actions-configuration-variables %}, vars{% endif %}</code> | |
{%- endif %}
| <code>concurrency</code> | <code>github, inputs</code> | |
| <code>env</code> | <code>github, secrets, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.concurrency</code> | <code>github, needs, strategy, matrix, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.container</code> | <code>github, needs, strategy, matrix, env, secrets, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.container.credentials</code> | <code>github, needs, strategy, matrix, env, secrets, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.container.env.&lt;env_id&gt;</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.continue-on-error</code> | <code>github, needs, strategy, matrix, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.defaults.run</code> | <code>github, needs, strategy, matrix, env, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.env</code> | <code>github, needs, strategy, matrix, secrets, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.environment</code> | <code>github, needs, strategy, matrix, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.environment.url</code> | <code>github, needs, strategy, matrix, job, runner, env, steps, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.if</code> | <code>github, needs, inputs</code> | <code>always, cancelled, success, failure</code> |
| <code>jobs.&lt;job_id&gt;.name</code> | <code>github, needs, strategy, matrix, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.outputs.&lt;output_id&gt;</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.runs-on</code> | <code>github, needs, strategy, matrix, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.secrets.&lt;secrets_id&gt;</code> | <code>github, needs,{% ifversion actions-reusable-workflow-matrix %} strategy, matrix,{% endif %} secrets{% ifversion actions-unified-inputs %}, inputs{% endif %}</code> | |
| <code>jobs.&lt;job_id&gt;.services</code> | <code>github, needs, strategy, matrix, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.services.&lt;service_id&gt;.credentials</code> | <code>github, needs, strategy, matrix, env, secrets, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.services.&lt;service_id&gt;.env.&lt;env_id&gt;</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.steps.continue-on-error</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps, inputs</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.env</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps, inputs</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.if</code> | <code>github, needs, strategy, matrix, job, runner, env, steps, inputs</code> | <code>always, cancelled, success, failure, hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.name</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps, inputs</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.run</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps, inputs</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.timeout-minutes</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps, inputs</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.with</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps, inputs</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.working-directory</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps, inputs</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.strategy</code> | <code>github, needs, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.timeout-minutes</code> | <code>github, needs, strategy, matrix, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.with.&lt;with_id&gt;</code> | <code>github, needs{% ifversion actions-reusable-workflow-matrix %}, strategy, matrix{% endif %}{% ifversion actions-unified-inputs %}, inputs{% endif %}</code> | |
| <code>on.workflow_call.inputs.&lt;inputs_id&gt;.default</code> | <code>github{% ifversion actions-unified-inputs %}, inputs{% endif %}</code> | |
| <code>on.workflow_call.outputs.&lt;output_id&gt;.value</code> | <code>github, jobs, inputs</code> | |
| <code>concurrency</code> | <code>github, inputs{% ifversion actions-configuration-variables %}, vars{% endif %}</code> | |
| <code>env</code> | <code>github, secrets, inputs{% ifversion actions-configuration-variables %}, vars{% endif %}</code> | |
| <code>jobs.&lt;job_id&gt;.concurrency</code> | <code>github, needs, strategy, matrix, inputs{% ifversion actions-configuration-variables %}, vars{% endif %}</code> | |
| <code>jobs.&lt;job_id&gt;.container</code> | <code>github, needs, strategy, matrix, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.container.credentials</code> | <code>github, needs, strategy, matrix, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.container.env.&lt;env_id&gt;</code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.continue-on-error</code> | <code>github, needs, strategy, {% ifversion actions-configuration-variables %}vars, {% endif %}matrix, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.defaults.run</code> | <code>github, needs, strategy, matrix, env, {% ifversion actions-configuration-variables %}vars, {% endif %}inputs</code> | |
| <code>jobs.&lt;job_id&gt;.env</code> | <code>github, needs, strategy, matrix, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.environment</code> | <code>github, needs, strategy, matrix, {% ifversion actions-configuration-variables %}vars, {% endif %}inputs</code> | |
| <code>jobs.&lt;job_id&gt;.environment.url</code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}steps, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.if</code> | <code>github, needs, {% ifversion actions-configuration-variables %}vars, {% endif %}inputs</code> | <code>always, cancelled, success, failure</code> |
| <code>jobs.&lt;job_id&gt;.name</code> | <code>github, needs, strategy, matrix, {% ifversion actions-configuration-variables %}vars, {% endif %}inputs</code> | |
| <code>jobs.&lt;job_id&gt;.outputs.&lt;output_id&gt;</code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, steps, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.runs-on</code> | <code>github, needs, strategy, matrix, {% ifversion actions-configuration-variables %}vars, {% endif %}inputs</code> | |
| <code>jobs.&lt;job_id&gt;.secrets.&lt;secrets_id&gt;</code> | <code>github, needs,{% ifversion actions-reusable-workflow-matrix %} strategy, matrix,{% endif %} secrets{% ifversion actions-unified-inputs %}, inputs{% endif %}{% ifversion actions-configuration-variables %}, vars{% endif %}</code> | |
| <code>jobs.&lt;job_id&gt;.services</code> | <code>github, needs, strategy, matrix, {% ifversion actions-configuration-variables %}vars, {% endif %}inputs</code> | |
| <code>jobs.&lt;job_id&gt;.services.&lt;service_id&gt;.credentials</code> | <code>github, needs, strategy, matrix, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.services.&lt;service_id&gt;.env.&lt;env_id&gt;</code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, inputs</code> | |
| <code>jobs.&lt;job_id&gt;.steps.continue-on-error</code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, steps, inputs</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.env</code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, steps, inputs</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.if</code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}steps, inputs</code> | <code>always, cancelled, success, failure, hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.name</code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, steps, inputs</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.run</code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, steps, inputs</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.timeout-minutes</code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, steps, inputs</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.with</code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, steps, inputs</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.working-directory</code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, steps, inputs</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.strategy</code> | <code>github, needs, {% ifversion actions-configuration-variables %}vars, {% endif %}inputs</code> | |
| <code>jobs.&lt;job_id&gt;.timeout-minutes</code> | <code>github, needs, strategy, matrix, {% ifversion actions-configuration-variables %}vars, {% endif %}inputs</code> | |
| <code>jobs.&lt;job_id&gt;.with.&lt;with_id&gt;</code> | <code>github, needs{% ifversion actions-reusable-workflow-matrix %}, strategy, matrix{% endif %}{% ifversion actions-unified-inputs %}, inputs{% endif %}{% ifversion actions-configuration-variables %}, vars{% endif %}</code> | |
| <code>on.workflow_call.inputs.&lt;inputs_id&gt;.default</code> | <code>github{% ifversion actions-unified-inputs %}, inputs{% endif %}{% ifversion actions-configuration-variables %}, vars{% endif %}</code> | |
| <code>on.workflow_call.outputs.&lt;output_id&gt;.value</code> | <code>github, jobs, {% ifversion actions-configuration-variables %}vars, {% endif %}inputs</code> | |
{% else %}
| Path | Context | Special functions |
| ---- | ------- | ----------------- |
@@ -116,28 +118,28 @@ The following table indicates where each context and special function can be use
| <code>env</code> | <code>github, secrets</code> | |
| <code>jobs.&lt;job_id&gt;.concurrency</code> | <code>github, needs, strategy, matrix</code> | |
| <code>jobs.&lt;job_id&gt;.container</code> | <code>github, needs, strategy, matrix</code> | |
| <code>jobs.&lt;job_id&gt;.container.credentials</code> | <code>github, needs, strategy, matrix, env, secrets</code> | |
| <code>jobs.&lt;job_id&gt;.container.env.&lt;env_id&gt;</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets</code> | |
| <code>jobs.&lt;job_id&gt;.container.credentials</code> | <code>github, needs, strategy, matrix, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets</code> | |
| <code>jobs.&lt;job_id&gt;.container.env.&lt;env_id&gt;</code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets</code> | |
| <code>jobs.&lt;job_id&gt;.continue-on-error</code> | <code>github, needs, strategy, matrix</code> | |
| <code>jobs.&lt;job_id&gt;.defaults.run</code> | <code>github, needs, strategy, matrix, env</code> | |
| <code>jobs.&lt;job_id&gt;.defaults.run</code> | <code>github, needs, strategy, matrix, env, {% ifversion actions-configuration-variables %}vars, {% endif %}</code> | |
| <code>jobs.&lt;job_id&gt;.env</code> | <code>github, needs, strategy, matrix, secrets</code> | |
| <code>jobs.&lt;job_id&gt;.environment</code> | <code>github, needs, strategy, matrix</code> | |
| <code>jobs.&lt;job_id&gt;.environment.url</code> | <code>github, needs, strategy, matrix, job, runner, env, steps</code> | |
| <code>jobs.&lt;job_id&gt;.environment.url</code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}steps</code> | |
| <code>jobs.&lt;job_id&gt;.if</code> | <code>github, needs</code> | <code>always, cancelled, success, failure</code> |
| <code>jobs.&lt;job_id&gt;.name</code> | <code>github, needs, strategy, matrix</code> | |
| <code>jobs.&lt;job_id&gt;.outputs.&lt;output_id&gt;</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps</code> | |
| <code>jobs.&lt;job_id&gt;.outputs.&lt;output_id&gt;</code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, steps</code> | |
| <code>jobs.&lt;job_id&gt;.runs-on</code> | <code>github, needs, strategy, matrix</code> | |
| <code>jobs.&lt;job_id&gt;.services</code> | <code>github, needs, strategy, matrix</code> | |
| <code>jobs.&lt;job_id&gt;.services.&lt;service_id&gt;.credentials</code> | <code>github, needs, strategy, matrix, env, secrets</code> | |
| <code>jobs.&lt;job_id&gt;.services.&lt;service_id&gt;.env.&lt;env_id&gt;</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets</code> | |
| <code>jobs.&lt;job_id&gt;.steps.continue-on-error</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.env</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.if</code> | <code>github, needs, strategy, matrix, job, runner, env, steps</code> | <code>always, cancelled, success, failure, hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.name</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.run</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.timeout-minutes</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.with</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.working-directory</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.services.&lt;service_id&gt;.credentials</code> | <code>github, needs, strategy, matrix, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets</code> | |
| <code>jobs.&lt;job_id&gt;.services.&lt;service_id&gt;.env.&lt;env_id&gt;</code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets</code> | |
| <code>jobs.&lt;job_id&gt;.steps.continue-on-error</code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, steps</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.env</code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, steps</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.if</code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}steps</code> | <code>always, cancelled, success, failure, hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.name</code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, steps</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.run</code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, steps</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.timeout-minutes</code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, steps</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.with</code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, steps</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.steps.working-directory</code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, steps</code> | <code>hashFiles</code> |
| <code>jobs.&lt;job_id&gt;.strategy</code> | <code>github, needs</code> | |
| <code>jobs.&lt;job_id&gt;.timeout-minutes</code> | <code>github, needs, strategy, matrix</code> | |
{% endif %}
@@ -295,11 +297,11 @@ jobs:
## `env` context
The `env` context contains environment variables that have been set in a workflow, job, or step. For more information about setting environment variables in your workflow, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#env)."
The `env` context contains variables that have been set in a workflow, job, or step. For more information about setting variables in your workflow, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#env)."
The `env` context syntax allows you to use the value of an environment variable in your workflow file. You can use the `env` context in the value of any key in a step except for the `id` and `uses` keys. For more information on the step syntax, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idsteps)."
The `env` context syntax allows you to use the value of a variable in your workflow file. You can use the `env` context in the value of any key in a step except for the `id` and `uses` keys. For more information on the step syntax, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idsteps)."
If you want to use the value of an environment variable inside a runner, use the runner operating system's normal method for reading environment variables.
If you want to use the value of a variable inside a runner, use the runner operating system's normal method for reading environment variables.
| Property name | Type | Description |
|---------------|------|-------------|
@@ -308,7 +310,7 @@ If you want to use the value of an environment variable inside a runner, use the
### Example contents of the `env` context
The contents of the `env` context is a mapping of environment variable names to their values. The context's contents can change depending on where it is used in the workflow run.
The contents of the `env` context is a mapping of variable names to their values. The context's contents can change depending on where it is used in the workflow run.
```json
{
@@ -348,6 +350,32 @@ jobs:
```
{% endraw %}
{% ifversion actions-configuration-variables %}
## `vars` context
{% data reusables.actions.configuration-variables-beta-note %}
The `vars` context contains custom configuration variables set at the organization, repository, and environment levels. For more information about defining configuration variables for use in multiple workflows, see "[Variables](/actions/learn-github-actions/variables#defining-variables-for-multiple-workflows)".
### Example contents of the `vars` context
The contents of the `vars` context is a mapping of configuration variable names to their values.
```json
{
"mascot": "Mona"
}
```
### Example usage of the `vars` context
This example workflow shows how configuration variables set at the repository, environment, or organization levels are automatically available using the `vars` context.
{% data reusables.actions.actions-vars-context-example-usage %}
{% endif %}
## `job` context
The `job` context contains information about the currently running job.

211
content/actions/learn-github-actions/environment-variables.md
View File

@@ -1,211 +0,0 @@
---
title: Environment variables
intro: '{% data variables.product.prodname_dotcom %} sets default environment variables for each {% data variables.product.prodname_actions %} workflow run. You can also set custom environment variables in your workflow file.'
redirect_from:
- /github/automating-your-workflow-with-github-actions/using-environment-variables
- /actions/automating-your-workflow-with-github-actions/using-environment-variables
- /actions/configuring-and-managing-workflows/using-environment-variables
- /actions/reference/environment-variables
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## About environment variables
You can use environment variables to store information that you want to reference in your workflow. You reference environment variables within a workflow step or an action, and the variables are interpolated on the runner machine that runs your workflow. Commands that run in actions or workflow steps can create, read, and modify environment variables.
You can set your own custom environment variables, you can use the default environment variables that {% data variables.product.prodname_dotcom %} sets automatically, and you can also use any other environment variables that are set in the working environment on the runner. Environment variables are case-sensitive.
To set a custom environment variable, you must define it in the workflow file. The scope of a custom environment variable is limited to the element in which it is defined. You can define environment variables that are scoped for:
* The entire workflow, by using [`env`](/actions/using-workflows/workflow-syntax-for-github-actions#env) at the top level of the workflow file.
* The contents of a job within a workflow, by using [`jobs.<job_id>.env`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idenv).
* A specific step within a job, by using [`jobs.<job_id>.steps[*].env`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsenv).
{% raw %}
```yaml
name: Greeting on variable day
on:
workflow_dispatch
env:
DAY_OF_WEEK: Monday
jobs:
greeting_job:
runs-on: ubuntu-latest
env:
Greeting: Hello
steps:
- name: "Say Hello Mona it's Monday"
run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!"
env:
First_Name: Mona
```
{% endraw %}
The example above shows three custom environment variables being used in an `echo` command: `$DAY_OF_WEEK`, `$Greeting`, and `$First_Name`. The values for these environment variables are set, and scoped, at the workflow, job, and step level respectively.
Because environment variable interpolation is done after a workflow job is sent to a runner machine, you must use the appropriate syntax for the shell that's used on the runner. In this example, the workflow specifies `ubuntu-latest`. By default, Linux runners use the bash shell, so you must use the syntax `$NAME`. If the workflow specified a Windows runner, you would use the syntax for PowerShell, `$env:NAME`. For more information about shells, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepsshell)."
{% note %}
**Note**: You can list the entire set of environment variables that are available to a workflow step by using <span style="white-space: nowrap;">`run: env`</span> in a step and then examining the output for the step.
{% endnote %}
## Using contexts to access environment variable values
In addition to environment variables, {% data variables.product.prodname_actions %} also allows you to set and read values using contexts. Environment variables and contexts are intended for use at different points in the workflow.
Environment variables are always interpolated on the virtual machine runner. However, parts of a workflow are processed by {% data variables.product.prodname_actions %} and are not sent to the runner. You cannot use environment variables in these parts of a workflow file. Instead, you can use contexts. For example, an `if` conditional, which determines whether a job or step is sent to the runner, is always processed by {% data variables.product.prodname_actions %}. You can use a context in an `if` conditional statement to access the value of an environment variable.
{% raw %}
```yaml
env:
DAY_OF_WEEK: Monday
jobs:
greeting_job:
runs-on: ubuntu-latest
env:
Greeting: Hello
steps:
- name: "Say Hello Mona it's Monday"
if: ${{ env.DAY_OF_WEEK == 'Monday' }}
run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!"
env:
First_Name: Mona
```
{% endraw %}
In this modification of the first example, we've introduced an `if` conditional. The workflow step is now only run if `DAYS_OF_WEEK` is set to "Monday". We access this value from the `if` conditional statement by using the [`env` context](/actions/learn-github-actions/contexts#env-context).
{% note %}
**Note**: Contexts are usually denoted using the dollar sign and curly braces, as {% raw %}`${{ context.property }}`{% endraw %}. In an `if` conditional, the {% raw %}`${{` and `}}`{% endraw %} are optional, but if you use them they must enclose the entire comparison statement, as shown above.
{% endnote %}
You will commonly use either the `env` or `github` context to access environment variable values in parts of the workflow that are processed before jobs are sent to runners.
| Context | Use case | Example |
| --- | --- | --- |
| `env` | Reference custom environment variables defined in the workflow. | <span style="white-space: nowrap;">{% raw %}`${{ env.MY_VARIABLE }}`{% endraw %}</span> |
| `github` | Reference information about the workflow run and the event that triggered the run. | <span style="white-space: nowrap;">{% raw %}`${{ github.repository }}`{% endraw %}</span> |
There are many other contexts that you can use for a variety of purposes in your workflows. For more information, see "[Contexts](/actions/learn-github-actions/contexts)." For details of where you can use specific contexts within a workflow, see "[Context availability](/actions/learn-github-actions/contexts#context-availability)."
### Other types of variables
In most places in a workflow, the only types of variables that you can use are either environment variables, such as `$MY_VARIABLE`, or the equivalent context property, such as <span style="white-space: nowrap;">{% raw %}`${{ env.MY_VARIABLE }}`{% endraw %}</span>. Exceptions are:
* Inputs for the `workflow_call` and `workflow_dispatch` events, which allow you to pass values to a workflow. For more information, see [`on.workflow_call.inputs`](/actions/learn-github-actions/workflow-syntax-for-github-actions#onworkflow_callinputs) and [`on.workflow_dispatch.inputs`](/actions/learn-github-actions/workflow-syntax-for-github-actions#onworkflow_dispatchinputs).
* Job outputs, which allow you to pass values between jobs in a workflow. For more information, see [`jobs.<job_id>.outputs`](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idoutputs).
* The variables in a format expression, which allow you to replace parts of a string. For more information, see [`format`](/actions/learn-github-actions/expressions#format).
## Naming conventions for environment variables
When you set a custom environment variable, you cannot use any of the default environment variable names. For a complete list of these, see "[Default environment variables](#default-environment-variables)" below. If you attempt to override the value of one of these default environment variables, the assignment is ignored.
Any new environment variables you set that point to a location on the filesystem should have a `_PATH` suffix. The `GITHUB_ENV` and `GITHUB_WORKSPACE` default environment variables are exceptions to this convention.
## Default environment variables
The default environment variables that {% data variables.product.prodname_dotcom %} sets are available to every step in a workflow.
We strongly recommend that actions use environment variables to access the filesystem rather than using hardcoded file paths. {% data variables.product.prodname_dotcom %} sets environment variables for actions to use in all runner environments.
| Environment variable | Description |
| ---------------------|------------ |
| `CI` | Always set to `true`. |
| `GITHUB_ACTION` | The name of the action currently running, or the [`id`](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepsid) of a step. For example, for an action, `__repo-owner_name-of-action-repo`.<br><br>{% data variables.product.prodname_dotcom %} removes special characters, and uses the name `__run` when the current step runs a script without an `id`. If you use the same script or action more than once in the same job, the name will include a suffix that consists of the sequence number preceded by an underscore. For example, the first script you run will have the name `__run`, and the second script will be named `__run_2`. Similarly, the second invocation of `actions/checkout` will be `actionscheckout2`. |
| `GITHUB_ACTION_PATH` | The path where an action is located. This property is only supported in composite actions. You can use this path to access files located in the same repository as the action. For example, `/home/runner/work/_actions/repo-owner/name-of-action-repo/v1`. |
| `GITHUB_ACTION_REPOSITORY` | For a step executing an action, this is the owner and repository name of the action. For example, `actions/checkout`. |
| `GITHUB_ACTIONS` | Always set to `true` when {% data variables.product.prodname_actions %} is running the workflow. You can use this variable to differentiate when tests are being run locally or by {% data variables.product.prodname_actions %}.
| `GITHUB_ACTOR` | The name of the person or app that initiated the workflow. For example, `octocat`. |
| `GITHUB_API_URL` | Returns the API URL. For example: `{% data variables.product.api_url_code %}`.
| `GITHUB_BASE_REF` | The name of the base ref or target branch of the pull request in a workflow run. This is only set when the event that triggers a workflow run is either `pull_request` or `pull_request_target`. For example, `main`. |
| `GITHUB_ENV` | The path on the runner to the file that sets environment variables from workflow commands. This file is unique to the current step and changes for each step in a job. For example, `/home/runner/work/_temp/_runner_file_commands/set_env_87406d6e-4979-4d42-98e1-3dab1f48b13a`. For more information, see "[Workflow commands for {% data variables.product.prodname_actions %}](/actions/using-workflows/workflow-commands-for-github-actions#setting-an-environment-variable)." |
| `GITHUB_EVENT_NAME` | The name of the event that triggered the workflow. For example, `workflow_dispatch`. |
| `GITHUB_EVENT_PATH` | The path to the file on the runner that contains the full event webhook payload. For example, `/github/workflow/event.json`. |
| `GITHUB_GRAPHQL_URL` | Returns the GraphQL API URL. For example: `{% data variables.product.graphql_url_code %}`.
| `GITHUB_HEAD_REF` | The head ref or source branch of the pull request in a workflow run. This property is only set when the event that triggers a workflow run is either `pull_request` or `pull_request_target`. For example, `feature-branch-1`. |
| `GITHUB_JOB` | The [job_id](/actions/reference/workflow-syntax-for-github-actions#jobsjob_id) of the current job. For example, `greeting_job`. |
| `GITHUB_PATH` | The path on the runner to the file that sets system `PATH` variables from workflow commands. This file is unique to the current step and changes for each step in a job. For example, `/home/runner/work/_temp/_runner_file_commands/add_path_899b9445-ad4a-400c-aa89-249f18632cf5`. For more information, see "[Workflow commands for {% data variables.product.prodname_actions %}](/actions/using-workflows/workflow-commands-for-github-actions#adding-a-system-path)." |
| `GITHUB_REF` | {% data reusables.actions.ref-description %} |
{%- ifversion fpt or ghec or ghes > 3.3 or ghae > 3.3 %}
| `GITHUB_REF_NAME` | {% data reusables.actions.ref_name-description %} |
| `GITHUB_REF_PROTECTED` | {% data reusables.actions.ref_protected-description %} |
| `GITHUB_REF_TYPE` | {% data reusables.actions.ref_type-description %} |
{%- endif %}
| `GITHUB_REPOSITORY` | The owner and repository name. For example, `octocat/Hello-World`. |
| `GITHUB_REPOSITORY_OWNER` | The repository owner's name. For example, `octocat`. |
| `GITHUB_RETENTION_DAYS` | The number of days that workflow run logs and artifacts are kept. For example, `90`. |
| `GITHUB_RUN_ATTEMPT` | A unique number for each attempt of a particular workflow run in a repository. This number begins at 1 for the workflow run's first attempt, and increments with each re-run. For example, `3`. |
| `GITHUB_RUN_ID` | {% data reusables.actions.run_id_description %} For example, `1658821493`. |
| `GITHUB_RUN_NUMBER` | {% data reusables.actions.run_number_description %} For example, `3`. |
| `GITHUB_SERVER_URL`| The URL of the {% data variables.product.product_name %} server. For example: `https://{% data variables.product.product_url %}`.
| `GITHUB_SHA` | {% data reusables.actions.github_sha_description %} |
{%- ifversion actions-job-summaries %}
| `GITHUB_STEP_SUMMARY` | The path on the runner to the file that contains job summaries from workflow commands. This file is unique to the current step and changes for each step in a job. For example, `/home/rob/runner/_layout/_work/_temp/_runner_file_commands/step_summary_1cb22d7f-5663-41a8-9ffc-13472605c76c`. For more information, see "[Workflow commands for {% data variables.product.prodname_actions %}](/actions/using-workflows/workflow-commands-for-github-actions#adding-a-job-summary)." |
{%- endif %}
| `GITHUB_WORKFLOW` | The name of the workflow. For example, `My test workflow`. If the workflow file doesn't specify a `name`, the value of this variable is the full path of the workflow file in the repository. |
| `GITHUB_WORKSPACE` | The default working directory on the runner for steps, and the default location of your repository when using the [`checkout`](https://github.com/actions/checkout) action. For example, `/home/runner/work/my-repo-name/my-repo-name`. |
{%- ifversion actions-runner-arch-envvars %}
| `RUNNER_ARCH` | {% data reusables.actions.runner-arch-description %} |
{%- endif %}
| `RUNNER_DEBUG` | {% data reusables.actions.runner-debug-description %} |
| `RUNNER_NAME` | {% data reusables.actions.runner-name-description %} For example, `Hosted Agent` |
| `RUNNER_OS` | {% data reusables.actions.runner-os-description %} For example, `Windows` |
| `RUNNER_TEMP` | {% data reusables.actions.runner-temp-directory-description %} For example, `D:\a\_temp` |
{%- ifversion not ghae %}
| `RUNNER_TOOL_CACHE` | {% data reusables.actions.runner-tool-cache-description %} For example, `C:\hostedtoolcache\windows` |
{%- endif %}
{% note %}
**Note:**
* If you need to use a workflow run's URL from within a job, you can combine these environment variables: `$GITHUB_SERVER_URL/$GITHUB_REPOSITORY/actions/runs/$GITHUB_RUN_ID`
* Most of the default environment variables have a corresponding, and similarly named, context property. For example, the value of the `GITHUB_REF` environment variable can be read during workflow processing using the {% raw %}`${{ github.ref }}`{% endraw %} context property.
{% endnote %}
## Detecting the operating system
You can write a single workflow file that can be used for different operating systems by using the `RUNNER_OS` default environment variable and the corresponding context property <span style="white-space: nowrap;">{% raw %}`${{ runner.os }}`{% endraw %}</span>. For example, the following workflow could be run successfully if you changed the operating system from `macos-latest` to `windows-latest` without having to alter the syntax of the environment variables, which differs depending on the shell being used by the runner.
{% raw %}
```yaml
jobs:
if-Windows-else:
runs-on: macos-latest
steps:
- name: condition 1
if: runner.os == 'Windows'
run: echo "The operating system on the runner is $env:RUNNER_OS."
- name: condition 2
if: runner.os != 'Windows'
run: echo "The operating system on the runner is not Windows, it's $RUNNER_OS."
```
{% endraw %}
In this example, the two `if` statements check the `os` property of the `runner` context to determine the operating system of the runner. `if` conditionals are processed by {% data variables.product.prodname_actions %}, and only steps where the check resolves as `true` are sent to the runner. Here one of the checks will always be `true` and the other `false`, so only one of these steps is sent to the runner. Once the job is sent to the runner, the step is executed and the environment variable in the `echo` command is interpolated using the appropriate syntax (`$env:NAME` for PowerShell on Windows, and `$NAME` for bash and sh on Linux and MacOS). In this example, the statement `runs-on: macos-latest` means that the second step will be run.
## Passing values between steps and jobs in a workflow
If you generate a value in one step of a job, you can use the value in subsequent steps of the same job by assigning the value to an existing or new environment variable and then writing this to the `GITHUB_ENV` environment file. The environment file can be used directly by an action, or from a shell command in the workflow file by using the `run` keyword. For more information, see "[Workflow commands for {% data variables.product.prodname_actions %}](/actions/reference/workflow-commands-for-github-actions/#setting-an-environment-variable)."
If you want to pass a value from a step in one job in a workflow to a step in another job in the workflow, you can define the value as a job output. You can then reference this job output from a step in another job. For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idoutputs)."

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

@@ -34,7 +34,7 @@ jobs:
POSTGRES_PORT: 5432
```
For more information, see "[Using environment variables](/actions/configuring-and-managing-workflows/using-environment-variables)."
For more information, see "[Variables](/actions/learn-github-actions/variables#default-environment-variables)."
## Adding scripts to your workflow

6
content/actions/learn-github-actions/expressions.md
View File

@@ -169,7 +169,11 @@ Replaces values in the `string`, with the variable `replaceValueN`. Variables in
#### Example
`format('Hello {0} {1} {2}', 'Mona', 'the', 'Octocat')`
{% raw %}
```js
format('Hello {0} {1} {2}', 'Mona', 'the', 'Octocat')
```
{% endraw %}
Returns 'Hello Mona the Octocat'.

2
content/actions/learn-github-actions/index.md
View File

@@ -24,7 +24,7 @@ children:
- /essential-features-of-github-actions
- /expressions
- /contexts
- /environment-variables
- /variables
- /usage-limits-billing-and-administration
---

317
content/actions/learn-github-actions/variables.md Normal file
View File

@@ -0,0 +1,317 @@
---
title: Variables
intro: '{% data variables.product.prodname_dotcom %} sets default variables for each {% data variables.product.prodname_actions %} workflow run. {% ifversion actions-configuration-variables %}You can also set custom variables for use in a single workflow or multiple workflows. {% else %}You can also set custom variables in your workflow file.{% endif %}'
redirect_from:
- /github/automating-your-workflow-with-github-actions/using-environment-variables
- /actions/automating-your-workflow-with-github-actions/using-environment-variables
- /actions/configuring-and-managing-workflows/using-environment-variables
- /actions/reference/environment-variables
- /actions/learn-github-actions/environment-variables
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
miniTocMaxHeadingLevel: 3
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## About variables
{% ifversion actions-configuration-variables %}
Variables provide a way to store and reuse non-sensitive configuration information. You can store any configuration data such as compiler flags, usernames, or server names as variables. Variables are interpolated on the runner machine that runs your workflow. Commands that run in actions or workflow steps can create, read, and modify variables.
You can set your own custom variables or use the default environment variables that {% data variables.product.prodname_dotcom %} sets automatically. For more information, see "[Default environment variables](#default-environment-variables)".
You can set a custom variable in two ways.
- To define an environment variable for use in a single workflow, you can use the `env` key in the workflow file. For more information, see "[Defining environment variables for a single workflow](#defining-environment-variables-for-a-single-workflow)".
- To define a configuration variable across multiple workflows, you can define it at the organization, repository, or environment level. For more information, see "[Defining configuration variables for multiple workflows](#defining-configuration-variables-for-a-multiple-workflows)".
{% warning %}
**Warning:** By default, variables render unmasked in your build outputs. If you need greater security for sensitive information, such as passwords, use encrypted secrets instead. For more information, see "[Encrypted secrets](/actions/security-guides/encrypted-secrets)".
{% endwarning %}
{% else %}
You can use variables to store information that you want to reference in your workflow. You reference variables within a workflow step or an action, and the variables are interpolated on the runner machine that runs your workflow. Commands that run in actions or workflow steps can create, read, and modify variables.
You can set your own custom variables, you can use the default variables that {% data variables.product.prodname_dotcom %} sets automatically, and you can also use any other variables that are set in the working environment on the runner. Variables are case-sensitive.
{% endif %}
## Defining environment variables{% ifversion actions-configuration-variables %} for a single workflow{% endif %}
To set a custom environment variable{% ifversion actions-configuration-variables %} for a single workflow{% endif %}, you can define it using the `env` key in the workflow file. The scope of a custom variable set by this method is limited to the element in which it is defined. You can define variables that are scoped for:
* The entire workflow, by using [`env`](/actions/using-workflows/workflow-syntax-for-github-actions#env) at the top level of the workflow file.
* The contents of a job within a workflow, by using [`jobs.<job_id>.env`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idenv).
* A specific step within a job, by using [`jobs.<job_id>.steps[*].env`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsenv).
{% raw %}
```yaml
name: Greeting on variable day
on:
workflow_dispatch
env:
DAY_OF_WEEK: Monday
jobs:
greeting_job:
runs-on: ubuntu-latest
env:
Greeting: Hello
steps:
- name: "Say Hello Mona it's Monday"
run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!"
env:
First_Name: Mona
```
{% endraw %}
You can access `env` variable values using runner environment variables or using contexts. The above example above shows three custom variables being used as environment variables in an `echo` command: `$DAY_OF_WEEK`, `$Greeting`, and `$First_Name`. The values for these variables are set, and scoped, at the workflow, job, and step level respectively. For more information on accessing variable values using contexts, see "[Using contexts to access variable values](#using-contexts-to-access-variable-values)."
Because runner environment variable interpolation is done after a workflow job is sent to a runner machine, you must use the appropriate syntax for the shell that's used on the runner. In this example, the workflow specifies `ubuntu-latest`. By default, Linux runners use the bash shell, so you must use the syntax `$NAME`. If the workflow specified a Windows runner, you would use the syntax for PowerShell, `$env:NAME`. For more information about shells, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepsshell)."
{% note %}
**Note**: You can list the entire set of environment variables that are available to a workflow step by using <span style="white-space: nowrap;">`run: env`</span> in a step and then examining the output for the step.
{% endnote %}
{% ifversion actions-configuration-variables %}
## Defining configuration variables for multiple workflows
{% data reusables.actions.configuration-variables-beta-note %}
You can create configuration variables for use across multiple workflows, and can define them at either the [organization](#creating-configuration-variables-for-an-organization), [repository](#creating-configuration-variables-for-a-repository), or [environment](#creating-configuration-variables-for-an-environment) level.
For example, you can use configuration variables to set default values for parameters passed to build tools at an organization level, but then allow repository owners to override these parameters on a case-by-case basis.
When you define configuration variables, they are automatically available in the `vars` context. For more information, see "[Using the `vars `context to access configuration variable values](#using-the-vars-context-to-access-configuration-variable-values)".
### Configuration variable precedence
If a variable with the same name exists at multiple levels, the variable at the lowest level takes precedence. For example, if an organization-level variable has the same name as a repository-level variable, then the repository-level variable takes precedence. Similarly, if an organization, repository, and environment all have a variable with the same name, the environment-level variable takes precedence.
If a repository contains reusable workflows, its configuration variables are automatically made available to the caller workflows with the `vars` context. However, if the same variable name is used in the caller and the called workflow repositories, the variable from the caller workflow repository is be used.
### Naming conventions for configuration variables
When you set a custom variable, you cannot use any of the default environment variable names. For a complete list of default environment variables, see "[Default environment variables](#default-environment-variables)" below. If you attempt to override the value of one of these default variables, the assignment is ignored.
Any new variables you set that point to a location on the filesystem should have a `_PATH` suffix. The `GITHUB_ENV` and `GITHUB_WORKSPACE` default variables are exceptions to this convention.
The following rules apply to configuration variable names:
{% data reusables.actions.actions-secrets-and-variables-naming %}
### Creating configuration variables for a repository
{% data reusables.actions.permissions-statement-secrets-variables-repository %}
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-settings %}
{% data reusables.actions.sidebar-secrets-and-variables %}
{% data reusables.actions.actions-variables-tab %}
![Repository variables tab](/assets/images/help/repository/actions-variables-tab.png)
1. Click **New repository variable**.
{% data reusables.actions.variable-fields %}
1. Click **Add variable**.
### Creating configuration variables for an environment
{% data reusables.actions.permissions-statement-secrets-environment %}
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-settings %}
{% data reusables.actions.sidebar-environment %}
1. Click on the environment that you want to add a variable to.
1. Under **Environment variables**, click **Add variable**.
{% data reusables.actions.variable-fields %}
1. Click **Add variable**.
### Creating configuration variables for an organization
{% data reusables.actions.actions-secrets-variables-repository-access %}
{% data reusables.actions.permissions-statement-secrets-and-variables-organization %}
{% data reusables.organizations.navigate-to-org %}
{% data reusables.organizations.org_settings %}
{% data reusables.actions.sidebar-secrets-and-variables %}
{% data reusables.actions.actions-variables-tab %}
![Organization variables tab](/assets/images/help/organizations/actions-organization-variables-tab.png)
1. Click **New organization variable**.
{% data reusables.actions.variable-fields %}
1. From the **Repository access** dropdown list, choose an access policy.
1. Click **Add variable**.
### Limits for configuration variables
You can store up to 1,000 organization variables, 100 repository variables, and 100 environment variables.
A workflow created in a repository can access the following number of variables:
* All 100 repository variables.
* If the repository is assigned access to more than 100 organization variables, the workflow can only use the first 100 organization variables (sorted alphabetically by variable name).
* All 100 environment variables.
Variables are limited to 64 KB in size.
{% endif %}
## Using contexts to access variable values
{% data reusables.actions.actions-contexts-about-description %} For more information, see "[Contexts](/actions/learn-github-actions/contexts)". There are many other contexts that you can use for a variety of purposes in your workflows. For details of where you can use specific contexts within a workflow, see "[Context availability](/actions/learn-github-actions/contexts#context-availability)."
You can access environment variable values using the `env` context{% ifversion actions-configuration-variables %} and configuration variable values using the `vars` context{% endif %}.
### Using the `env` context to access environment variable values
In addition to runner environment variables, {% data variables.product.prodname_actions %} allows you to set and read `env` key values using contexts. Environment variables and contexts are intended for use at different points in the workflow.
Runner environment variables are always interpolated on the runner machine. However, parts of a workflow are processed by {% data variables.product.prodname_actions %} and are not sent to the runner. You cannot use environment variables in these parts of a workflow file. Instead, you can use contexts. For example, an `if` conditional, which determines whether a job or step is sent to the runner, is always processed by {% data variables.product.prodname_actions %}. You can use a context in an `if` conditional statement to access the value of an variable.
{% raw %}
```yaml
env:
DAY_OF_WEEK: Monday
jobs:
greeting_job:
runs-on: ubuntu-latest
env:
Greeting: Hello
steps:
- name: "Say Hello Mona it's Monday"
if: ${{ env.DAY_OF_WEEK == 'Monday' }}
run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!"
env:
First_Name: Mona
```
{% endraw %}
In this modification of the earlier example, we've introduced an `if` conditional. The workflow step is now only run if `DAYS_OF_WEEK` is set to "Monday". We access this value from the `if` conditional statement by using the [`env` context](/actions/learn-github-actions/contexts#env-context).
{% note %}
**Note**: Contexts are usually denoted using the dollar sign and curly braces, as {% raw %}`${{ context.property }}`{% endraw %}. In an `if` conditional, the {% raw %}`${{` and `}}`{% endraw %} are optional, but if you use them they must enclose the entire comparison statement, as shown above.
{% endnote %}
You will commonly use either the `env` or `github` context to access variable values in parts of the workflow that are processed before jobs are sent to runners.
| Context | Use case | Example |
| --- | --- | --- |
| `env` | Reference custom variables defined in the workflow. | <span style="white-space: nowrap;">{% raw %}`${{ env.MY_VARIABLE }}`{% endraw %}</span> |
| `github` | Reference information about the workflow run and the event that triggered the run. | <span style="white-space: nowrap;">{% raw %}`${{ github.repository }}`{% endraw %}</span> |
{% ifversion actions-configuration-variables %}
### Using the `vars` context to access configuration variable values
Configuration variables can be accessed across the workflow using `vars` context. For more information, see "[Contexts](/actions/learn-github-actions/contexts#vars-context)".
{% data reusables.actions.actions-vars-context-example-usage %}
{% endif %}
## Default environment variables
The default environment variables that {% data variables.product.prodname_dotcom %} sets are available to every step in a workflow.
We strongly recommend that actions use variables to access the filesystem rather than using hardcoded file paths. {% data variables.product.prodname_dotcom %} sets variables for actions to use in all runner environments.
| Variable | Description |
| ---------|------------ |
| `CI` | Always set to `true`. |
| `GITHUB_ACTION` | The name of the action currently running, or the [`id`](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepsid) of a step. For example, for an action, `__repo-owner_name-of-action-repo`.<br><br>{% data variables.product.prodname_dotcom %} removes special characters, and uses the name `__run` when the current step runs a script without an `id`. If you use the same script or action more than once in the same job, the name will include a suffix that consists of the sequence number preceded by an underscore. For example, the first script you run will have the name `__run`, and the second script will be named `__run_2`. Similarly, the second invocation of `actions/checkout` will be `actionscheckout2`. |
| `GITHUB_ACTION_PATH` | The path where an action is located. This property is only supported in composite actions. You can use this path to access files located in the same repository as the action. For example, `/home/runner/work/_actions/repo-owner/name-of-action-repo/v1`. |
| `GITHUB_ACTION_REPOSITORY` | For a step executing an action, this is the owner and repository name of the action. For example, `actions/checkout`. |
| `GITHUB_ACTIONS` | Always set to `true` when {% data variables.product.prodname_actions %} is running the workflow. You can use this variable to differentiate when tests are being run locally or by {% data variables.product.prodname_actions %}.
| `GITHUB_ACTOR` | The name of the person or app that initiated the workflow. For example, `octocat`. |
| `GITHUB_API_URL` | Returns the API URL. For example: `{% data variables.product.api_url_code %}`.
| `GITHUB_BASE_REF` | The name of the base ref or target branch of the pull request in a workflow run. This is only set when the event that triggers a workflow run is either `pull_request` or `pull_request_target`. For example, `main`. |
| `GITHUB_ENV` | The path on the runner to the file that sets variables from workflow commands. This file is unique to the current step and changes for each step in a job. For example, `/home/runner/work/_temp/_runner_file_commands/set_env_87406d6e-4979-4d42-98e1-3dab1f48b13a`. For more information, see "[Workflow commands for {% data variables.product.prodname_actions %}](/actions/using-workflows/workflow-commands-for-github-actions#setting-an-environment-variable)." |
| `GITHUB_EVENT_NAME` | The name of the event that triggered the workflow. For example, `workflow_dispatch`. |
| `GITHUB_EVENT_PATH` | The path to the file on the runner that contains the full event webhook payload. For example, `/github/workflow/event.json`. |
| `GITHUB_GRAPHQL_URL` | Returns the GraphQL API URL. For example: `{% data variables.product.graphql_url_code %}`.
| `GITHUB_HEAD_REF` | The head ref or source branch of the pull request in a workflow run. This property is only set when the event that triggers a workflow run is either `pull_request` or `pull_request_target`. For example, `feature-branch-1`. |
| `GITHUB_JOB` | The [job_id](/actions/reference/workflow-syntax-for-github-actions#jobsjob_id) of the current job. For example, `greeting_job`. |
| `GITHUB_PATH` | The path on the runner to the file that sets system `PATH` variables from workflow commands. This file is unique to the current step and changes for each step in a job. For example, `/home/runner/work/_temp/_runner_file_commands/add_path_899b9445-ad4a-400c-aa89-249f18632cf5`. For more information, see "[Workflow commands for {% data variables.product.prodname_actions %}](/actions/using-workflows/workflow-commands-for-github-actions#adding-a-system-path)." |
| `GITHUB_REF` | {% data reusables.actions.ref-description %} |
{%- ifversion fpt or ghec or ghes > 3.3 or ghae > 3.3 %}
| `GITHUB_REF_NAME` | {% data reusables.actions.ref_name-description %} |
| `GITHUB_REF_PROTECTED` | {% data reusables.actions.ref_protected-description %} |
| `GITHUB_REF_TYPE` | {% data reusables.actions.ref_type-description %} |
{%- endif %}
| `GITHUB_REPOSITORY` | The owner and repository name. For example, `octocat/Hello-World`. |
| `GITHUB_REPOSITORY_OWNER` | The repository owner's name. For example, `octocat`. |
| `GITHUB_RETENTION_DAYS` | The number of days that workflow run logs and artifacts are kept. For example, `90`. |
| `GITHUB_RUN_ATTEMPT` | A unique number for each attempt of a particular workflow run in a repository. This number begins at 1 for the workflow run's first attempt, and increments with each re-run. For example, `3`. |
| `GITHUB_RUN_ID` | {% data reusables.actions.run_id_description %} For example, `1658821493`. |
| `GITHUB_RUN_NUMBER` | {% data reusables.actions.run_number_description %} For example, `3`. |
| `GITHUB_SERVER_URL`| The URL of the {% data variables.product.product_name %} server. For example: `https://{% data variables.product.product_url %}`.
| `GITHUB_SHA` | {% data reusables.actions.github_sha_description %} |
{%- ifversion actions-job-summaries %}
| `GITHUB_STEP_SUMMARY` | The path on the runner to the file that contains job summaries from workflow commands. This file is unique to the current step and changes for each step in a job. For example, `/home/rob/runner/_layout/_work/_temp/_runner_file_commands/step_summary_1cb22d7f-5663-41a8-9ffc-13472605c76c`. For more information, see "[Workflow commands for {% data variables.product.prodname_actions %}](/actions/using-workflows/workflow-commands-for-github-actions#adding-a-job-summary)." |
{%- endif %}
| `GITHUB_WORKFLOW` | The name of the workflow. For example, `My test workflow`. If the workflow file doesn't specify a `name`, the value of this variable is the full path of the workflow file in the repository. |
| `GITHUB_WORKSPACE` | The default working directory on the runner for steps, and the default location of your repository when using the [`checkout`](https://github.com/actions/checkout) action. For example, `/home/runner/work/my-repo-name/my-repo-name`. |
{%- ifversion actions-runner-arch-envvars %}
| `RUNNER_ARCH` | {% data reusables.actions.runner-arch-description %} |
{%- endif %}
| `RUNNER_DEBUG` | {% data reusables.actions.runner-debug-description %} |
| `RUNNER_NAME` | {% data reusables.actions.runner-name-description %} For example, `Hosted Agent` |
| `RUNNER_OS` | {% data reusables.actions.runner-os-description %} For example, `Windows` |
| `RUNNER_TEMP` | {% data reusables.actions.runner-temp-directory-description %} For example, `D:\a\_temp` |
{%- ifversion not ghae %}
| `RUNNER_TOOL_CACHE` | {% data reusables.actions.runner-tool-cache-description %} For example, `C:\hostedtoolcache\windows` |
{%- endif %}
{% note %}
**Note:**
* If you need to use a workflow run's URL from within a job, you can combine these variables: `$GITHUB_SERVER_URL/$GITHUB_REPOSITORY/actions/runs/$GITHUB_RUN_ID`
* Most of the default variables have a corresponding, and similarly named, context property. For example, the value of the `GITHUB_REF` variable can be read during workflow processing using the {% raw %}`${{ github.ref }}`{% endraw %} context property.
{% endnote %}
## Detecting the operating system
You can write a single workflow file that can be used for different operating systems by using the `RUNNER_OS` default environment variable and the corresponding context property <span style="white-space: nowrap;">{% raw %}`${{ runner.os }}`{% endraw %}</span>. For example, the following workflow could be run successfully if you changed the operating system from `macos-latest` to `windows-latest` without having to alter the syntax of the environment variables, which differs depending on the shell being used by the runner.
{% raw %}
```yaml
jobs:
if-Windows-else:
runs-on: macos-latest
steps:
- name: condition 1
if: runner.os == 'Windows'
run: echo "The operating system on the runner is $env:RUNNER_OS."
- name: condition 2
if: runner.os != 'Windows'
run: echo "The operating system on the runner is not Windows, it's $RUNNER_OS."
```
{% endraw %}
In this example, the two `if` statements check the `os` property of the `runner` context to determine the operating system of the runner. `if` conditionals are processed by {% data variables.product.prodname_actions %}, and only steps where the check resolves as `true` are sent to the runner. Here one of the checks will always be `true` and the other `false`, so only one of these steps is sent to the runner. Once the job is sent to the runner, the step is executed and the environment variable in the `echo` command is interpolated using the appropriate syntax (`$env:NAME` for PowerShell on Windows, and `$NAME` for bash and sh on Linux and MacOS). In this example, the statement `runs-on: macos-latest` means that the second step will be run.
## Passing values between steps and jobs in a workflow
If you generate a value in one step of a job, you can use the value in subsequent steps of the same job by assigning the value to an existing or new environment variable and then writing this to the `GITHUB_ENV` environment file. The environment file can be used directly by an action, or from a shell command in the workflow file by using the `run` keyword. For more information, see "[Workflow commands for {% data variables.product.prodname_actions %}](/actions/reference/workflow-commands-for-github-actions/#setting-an-environment-variable)."
If you want to pass a value from a step in one job in a workflow to a step in another job in the workflow, you can define the value as a job output. You can then reference this job output from a step in another job. For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idoutputs)."

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

@@ -73,9 +73,9 @@ For more information about the tools and packages available on {% data variables
## Using variables and secrets
CircleCI and {% data variables.product.prodname_actions %} support setting environment variables in the configuration file and creating secrets using the CircleCI or {% data variables.product.product_name %} UI.
CircleCI and {% data variables.product.prodname_actions %} support setting variables in the configuration file and creating secrets using the CircleCI or {% data variables.product.product_name %} UI.
For more information, see "[Using environment variables](/actions/configuring-and-managing-workflows/using-environment-variables)" and "[Creating and using encrypted secrets](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)."
For more information, see "[Variables](/actions/learn-github-actions/variables#default-environment-variables)" and "[Creating and using encrypted secrets](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)."
## Caching

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

@@ -301,9 +301,9 @@ For more information, see "[Events that trigger workflows](/actions/reference/ev
## Variables and secrets
GitLab CI/CD and {% data variables.product.prodname_actions %} support setting environment variables in the pipeline or workflow configuration file, and creating secrets using the GitLab or {% data variables.product.product_name %} UI.
GitLab CI/CD and {% data variables.product.prodname_actions %} support setting variables in the pipeline or workflow configuration file, and creating secrets using the GitLab or {% data variables.product.product_name %} UI.
For more information, see "[Environment variables](/actions/reference/environment-variables)" and "[Encrypted secrets](/actions/reference/encrypted-secrets)."
For more information, see "[Variables](/actions/learn-github-actions/variables)" and "[Encrypted secrets](/actions/reference/encrypted-secrets)."
## Caching

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

@@ -43,13 +43,13 @@ To give you control over when CI tasks are executed, a {% data variables.product
Travis CI and {% data variables.product.prodname_actions %} both use YAML to create jobs and workflows, and these files are stored in the code's repository. For more information on how {% data variables.product.prodname_actions %} uses YAML, see ["Creating a workflow file](/actions/learn-github-actions/introduction-to-github-actions#create-an-example-workflow)."
### Custom environment variables
### Custom variables
Travis CI lets you set environment variables and share them between stages. Similarly, {% data variables.product.prodname_actions %} lets you define environment variables for a step, job, or workflow. For more information, see ["Environment variables](/actions/reference/environment-variables)."
Travis CI lets you set variables and share them between stages. Similarly, {% data variables.product.prodname_actions %} lets you define variables for a workflows. For more information, see "[Variables](/actions/learn-github-actions/variables)."
### Default environment variables
### Default variables
Travis CI and {% data variables.product.prodname_actions %} both include default environment variables that you can use in your YAML files. For {% data variables.product.prodname_actions %}, you can see these listed in "[Default environment variables](/actions/reference/environment-variables#default-environment-variables)."
Travis CI and {% data variables.product.prodname_actions %} both include default environment variables that you can use in your YAML files. For {% data variables.product.prodname_actions %}, you can see these listed in "[Default environment variables](/actions/learn-github-actions/variables#default-environment-variables)."
### Parallel job processing
@@ -178,7 +178,7 @@ git:
### Using environment variables in a matrix
Travis CI and {% data variables.product.prodname_actions %} can both add custom environment variables to a test matrix, which allows you to refer to the variable in a later step.
Travis CI and {% data variables.product.prodname_actions %} can both add custom variables to a test matrix, which allows you to refer to the variable in a later step.
In {% data variables.product.prodname_actions %}, you can use the `include` key to add custom environment variables to a matrix. {% data reusables.actions.matrix-variable-example %}

4
content/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging.md
View File

@@ -16,9 +16,9 @@ versions:
These extra logs are enabled by setting secrets in the repository containing the workflow, so the same permissions requirements will apply:
- {% data reusables.actions.permissions-statement-secrets-repository %}
- {% data reusables.actions.permissions-statement-secrets-variables-repository %}
- {% data reusables.actions.permissions-statement-secrets-environment %}
- {% data reusables.actions.permissions-statement-secrets-organization %}
- {% data reusables.actions.permissions-statement-secrets-and-variables-organization %}
- {% data reusables.actions.permissions-statement-secrets-api %}
For more information on setting secrets, see "[Creating and using encrypted secrets](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."

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

@@ -47,7 +47,7 @@ This guide assumes that you have a complete definition for a Docker image stored
{% ifversion fpt or ghec or ghes > 3.4 %}
{% data reusables.package_registry.about-docker-labels %} For more information, see "[Working with the {% data variables.product.prodname_container_registry %}](/packages/working-with-a-github-packages-registry/working-with-the-container-registry#labelling-container-images)."
{% data reusables.package_registry.about-annotation-keys %} For more information, see "[Working with the {% data variables.product.prodname_container_registry %}](/packages/working-with-a-github-packages-registry/working-with-the-container-registry#labelling-container-images)."
{% endif %}

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

@@ -34,7 +34,7 @@ For more information about creating a CI workflow for your Java project with Gra
You may also find it helpful to have a basic understanding of the following:
- "[Working with the npm registry](/packages/working-with-a-github-packages-registry/working-with-the-npm-registry)"
- "[Environment variables](/actions/reference/environment-variables)"
- "[Variables](/actions/learn-github-actions/variables)"
- "[Encrypted secrets](/actions/reference/encrypted-secrets)"
- "[Authentication in a workflow](/actions/reference/authentication-in-a-workflow)"
@@ -160,10 +160,10 @@ on:
types: [created]
jobs:
publish:
runs-on: ubuntu-latest
permissions:
runs-on: ubuntu-latest
permissions:
contents: read
packages: write
packages: write
steps:
- uses: {% data reusables.actions.action-checkout %}
- uses: {% data reusables.actions.action-setup-java %}
@@ -241,10 +241,10 @@ on:
types: [created]
jobs:
publish:
runs-on: ubuntu-latest
permissions:
runs-on: ubuntu-latest
permissions:
contents: read
packages: write
packages: write
steps:
- uses: {% data reusables.actions.action-checkout %}
- name: Set up Java

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

@@ -34,7 +34,7 @@ For more information about creating a CI workflow for your Java project with Mav
You may also find it helpful to have a basic understanding of the following:
- "[Working with the npm registry](/packages/working-with-a-github-packages-registry/working-with-the-npm-registry)"
- "[Environment variables](/actions/reference/environment-variables)"
- "[Variables](/actions/learn-github-actions/variables)"
- "[Encrypted secrets](/actions/reference/encrypted-secrets)"
- "[Authentication in a workflow](/actions/reference/authentication-in-a-workflow)"
@@ -142,10 +142,10 @@ on:
types: [created]
jobs:
publish:
runs-on: ubuntu-latest
permissions:
runs-on: ubuntu-latest
permissions:
contents: read
packages: write
packages: write
steps:
- uses: {% data reusables.actions.action-checkout %}
- uses: {% data reusables.actions.action-setup-java %}
@@ -179,10 +179,10 @@ on:
types: [created]
jobs:
publish:
runs-on: ubuntu-latest
permissions:
runs-on: ubuntu-latest
permissions:
contents: read
packages: write
packages: write
steps:
- uses: {% data reusables.actions.action-checkout %}
- name: Set up Java for publishing to Maven Central Repository

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

@@ -35,7 +35,7 @@ For more information about creating a CI workflow for your Node.js project, see
You may also find it helpful to have a basic understanding of the following:
- "[Working with the npm registry](/packages/working-with-a-github-packages-registry/working-with-the-npm-registry)"
- "[Environment variables](/actions/reference/environment-variables)"
- "[Variables](/actions/learn-github-actions/variables)"
- "[Encrypted secrets](/actions/reference/encrypted-secrets)"
- "[Authentication in a workflow](/actions/reference/authentication-in-a-workflow)"
@@ -128,10 +128,10 @@ on:
types: [created]
jobs:
build:
runs-on: ubuntu-latest
permissions:
runs-on: ubuntu-latest
permissions:
contents: read
packages: write
packages: write
steps:
- uses: {% data reusables.actions.action-checkout %}
# Setup .npmrc file to publish to GitHub Packages

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

@@ -8,7 +8,7 @@ redirect_from:
- /actions/configuring-and-managing-workflows/using-variables-and-secrets-in-a-workflow
- /actions/reference/encrypted-secrets
- /actions/managing-workflows/storing-secrets
miniTocMaxHeadingLevel: 3
versions:
fpt: '*'
@@ -22,7 +22,7 @@ versions:
## About encrypted secrets
Secrets are encrypted environment variables that you create in an organization, repository, or repository environment. The secrets that you create are available to use in {% data variables.product.prodname_actions %} workflows. {% data variables.product.prodname_dotcom %} uses a [libsodium sealed box](https://libsodium.gitbook.io/doc/public-key_cryptography/sealed_boxes) to help ensure that secrets are encrypted before they reach {% data variables.product.prodname_dotcom %} and remain encrypted until you use them in a workflow.
Secrets are encrypted variables that you create in an organization, repository, or repository environment. The secrets that you create are available to use in {% data variables.product.prodname_actions %} workflows. {% data variables.product.prodname_dotcom %} uses a [libsodium sealed box](https://libsodium.gitbook.io/doc/public-key_cryptography/sealed_boxes) to help ensure that secrets are encrypted before they reach {% data variables.product.prodname_dotcom %} and remain encrypted until you use them in a workflow.
{% data reusables.actions.secrets-org-level-overview %}
@@ -40,7 +40,9 @@ For secrets stored at the environment level, you can enable required reviewers t
### Naming your secrets
{% data reusables.codespaces.secrets-naming %}
The following rules apply to secret names:
{% data reusables.actions.actions-secrets-and-variables-naming %}
For example, a secret created at the environment level must have a unique name in that environment, a secret created at the repository level must have a unique name in that repository, and a secret created at the organization level must have a unique name at that level.
@@ -72,13 +74,16 @@ When generating credentials, we recommend that you grant the minimum permissions
## Creating encrypted secrets for a repository
{% data reusables.actions.permissions-statement-secrets-repository %}
{% data reusables.actions.permissions-statement-secrets-variables-repository %}
{% webui %}
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-settings %}
{% data reusables.actions.sidebar-secret %}
{% data reusables.actions.sidebar-secrets-and-variables %}
{%- ifversion actions-configuration-variables %}
{% data reusables.actions.actions-secrets-tab %}
![Repository secrets tab](/assets/images/help/repository/actions-secrets-tab.png){% endif %}
1. Click **New repository secret**.
1. Type a name for your secret in the **Name** input box.
1. Enter the value for your secret.
@@ -143,15 +148,18 @@ gh secret list --env ENV_NAME
## Creating encrypted secrets for an organization
When creating a secret in an organization, you can use a policy to limit which repositories can access that secret. For example, you can grant access to all repositories, or limit access to only private repositories or a specified list of repositories.
{% data reusables.actions.actions-secrets-variables-repository-access %}
{% data reusables.actions.permissions-statement-secrets-organization %}
{% data reusables.actions.permissions-statement-secrets-and-variables-organization %}
{% webui %}
{% data reusables.organizations.navigate-to-org %}
{% data reusables.organizations.org_settings %}
{% data reusables.actions.sidebar-secret %}
{% data reusables.actions.sidebar-secrets-and-variables %}
{%- ifversion actions-configuration-variables %}
{% data reusables.actions.actions-secrets-tab %}
![Organization secrets tab](/assets/images/help/organizations/actions-organization-secrets-tab.png){% endif %}
1. Click **New organization secret**.
1. Type a name for your secret in the **Name** input box.
1. Enter the **Value** for your secret.
@@ -204,9 +212,9 @@ You can check which access policies are being applied to a secret in your organi
{% data reusables.organizations.navigate-to-org %}
{% data reusables.organizations.org_settings %}
{% data reusables.actions.sidebar-secret %}
{% data reusables.actions.sidebar-secrets-and-variables %}
1. The list of secrets includes any configured permissions and policies. For example:
![Secrets list](/assets/images/help/settings/actions-org-secrets-list.png)
![Secrets list](/assets/images/help/settings/actions-org-secrets-list.png)
1. For more details on the configured permissions for each secret, click **Update**.
## Using encrypted secrets in a workflow
@@ -356,9 +364,9 @@ To use secrets that are larger than 64 KB, you can use a workaround to store enc
```yaml
name: Workflows with large secrets
on: push
jobs:
my-job:
name: My Job
@@ -399,7 +407,7 @@ You can use Base64 encoding to store small binary blobs as secrets. You can then
✓ Set secret CERTIFICATE_BASE64 for octocat/octorepo
```
1. To access the Base64 string from your runner, pipe the secret to `base64 --decode`. For example:
1. To access the Base64 string from your runner, pipe the secret to `base64 --decode`. For example:
```yaml
name: Retrieve Base64 secret

10
content/actions/security-guides/security-hardening-for-github-actions.md
View File

@@ -151,7 +151,7 @@ With this approach, the value of the {% raw %}`${{ github.event.issue.title }}`{
{% data reusables.advanced-security.starter-workflows-beta %}
{% data variables.product.prodname_code_scanning_capc %} allows you to find security vulnerabilities before they reach production. {% data variables.product.product_name %} provides starter workflows for {% data variables.product.prodname_code_scanning %}. You can use these suggested workflows to construct your {% data variables.product.prodname_code_scanning %} workflows, instead of starting from scratch. {% data variables.product.company_short%}'s workflow, the {% data variables.code-scanning.codeql_workflow %}, is powered by {% data variables.product.prodname_codeql %}. There are also third-party starter workflows available.
For more information, see "[About {% data variables.product.prodname_code_scanning %}](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning)" and "[Setting up {% data variables.product.prodname_code_scanning %} using starter workflows](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository#setting-up-code-scanning-using-starter-workflows)."
For more information, see "[About {% data variables.product.prodname_code_scanning %}](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning)" and "[Setting up {% data variables.product.prodname_code_scanning %} for a repository](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository#setting-up-code-scanning-using-starter-workflows)."
{% endif %}
@@ -193,6 +193,14 @@ You can help mitigate this risk by following these good practices:
The same principles described above for using third-party actions also apply to using third-party workflows. You can help mitigate the risks associated with reusing workflows by following the same good practices outlined above. For more information, see "[Reusing workflows](/actions/learn-github-actions/reusing-workflows)."
{% endif %}
{% ifversion required-workflows %}
## Required workflows
Required workflows allow you to specify workflows to run on selected repositories or all repositories in your organization, providing the ability to enforce organization-wide security policies while only maintaining a single workflow. Required workflows appear as required status checks on pull requests and the checks must succeed before the pull request can be merged. For more information, see "[Required workflows](/actions/using-workflows/required-workflows)."
{% endif %}
{% ifversion internal-actions %}
## Allowing workflows to access internal {% ifversion private-actions %}and private {% endif %}repositories

2
content/actions/using-github-hosted-runners/about-github-hosted-runners.md
View File

@@ -194,7 +194,7 @@ The list of {% data variables.product.prodname_actions %} IP addresses returned
| `workspace` | `GITHUB_WORKSPACE` | Actions and shell commands execute in this directory. An action can modify the contents of this directory, which subsequent actions can access. |
| `workflow/event.json` | `GITHUB_EVENT_PATH` | The `POST` payload of the webhook event that triggered the workflow. {% data variables.product.prodname_dotcom %} rewrites this each time an action executes to isolate file content between actions.
For a list of the environment variables {% data variables.product.prodname_dotcom %} creates for each workflow, see "[Using environment variables](/github/automating-your-workflow-with-github-actions/using-environment-variables)."
For a list of the environment variables {% data variables.product.prodname_dotcom %} creates for each workflow, see "[Variables](/actions/learn-github-actions/variables#default-environment-variables)."
### Docker container filesystem

1
content/actions/using-workflows/index.md
View File

@@ -27,6 +27,7 @@ children:
- /workflow-syntax-for-github-actions
- /workflow-commands-for-github-actions
- /reusing-workflows
- /required-workflows
- /caching-dependencies-to-speed-up-workflows
- /storing-workflow-data-as-artifacts
- /creating-starter-workflows-for-your-organization

55
content/actions/using-workflows/required-workflows.md Normal file
View File

@@ -0,0 +1,55 @@
---
title: Required workflows
shortTitle: Required workflows
intro: "You can specify which workflows will run as required status checks in all repositories or selected repositories in your organization."
miniTocMaxHeadingLevel: 3
versions:
feature: 'required-workflows'
type: how_to
topics:
- Workflows
---
{% data reusables.actions.workflows.required-workflow-beta %}
## Overview
You can configure a workflow that must run in repositories in an organization for all pull requests opened against the default branch. Required workflows allow you to implement organization-wide CI/CD policies that apply to current and future repositories. A required workflow is triggered by pull request events and appears as a required status check, which blocks the ability to merge the pull request until the required workflow succeeds.
![Screenshot showing the controls for locating the required workflow](/assets/images/help/settings/example-required-workflow.png)
Required workflows are not the same as reusable workflows. Reusable workflows can be called by another workflow. Required workflows are enforced on repositories by an organization owner.
## Prerequisites
Before configuring a required workflow, note the following prerequisites:
{% data reusables.actions.workflows.required-workflow-prerequisites %}
## Restrictions and behaviors for the source repository
Note the following restrictions and behaviors for the source repository and workflow:
{% data reusables.actions.workflows.required-workflow-source-notes %}
## Restrictions and behaviors for the target repository
Note the following restrictions and behaviors for the target repositories:
{% data reusables.actions.workflows.required-workflow-target-notes %}
## Viewing workflow runs for required workflows
After a required workflow has run at least once in a repository, you can view its workflow runs in that repository's "Actions" tab. To make changes to what workflows are configured as required in an organization, you must contact an organization owner. To make changes to a required workflow itself, anyone with write permissions for the repository that contains the required workflow can make changes to it.
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.actions-tab %}
1. In the left sidebar, you can view workflow runs for required workflows under "Required workflows."
![Screenshot showing required workflows](/assets/images/help/settings/view-required-workflows.png)
## Adding a required workflow to an organization
Organization owners can configure required workflows in their organization. For more information, see "[Disabling or limiting GitHub Actions for your organization](/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#adding-a-required-workflow-to-an-organization)."

5
content/actions/using-workflows/reusing-workflows.md
View File

@@ -87,8 +87,9 @@ Called workflows that are owned by the same user or organization{% ifversion ghe
* You can call a maximum of 20 reusable workflows from a single workflow file.
{% endif %}
{% ifversion private-actions %}{% else %}* Reusable workflows stored within a private repository can only be used by workflows within the same repository.{% endif %}
* Any environment variables set in an `env` context defined at the workflow level in the caller workflow are not propagated to the called workflow. For more information about the `env` context, see "[Context and expression syntax for GitHub Actions](/actions/reference/context-and-expression-syntax-for-github-actions#env-context)."{% ifversion actions-reusable-workflow-matrix %}{% else %}
* The `strategy` property is not supported in any job that calls a reusable workflow.{% endif %}
{% ifversion actions-reusable-workflow-matrix %}{% else %}* The `strategy` property is not supported in any job that calls a reusable workflow.{% endif %}
* Any environment variables set in an `env` context defined at the workflow level in the caller workflow are not propagated to the called workflow. For more information, see "[Variables](/actions/learn-github-actions/variables)" and "[Contexts](/actions/learn-github-actions/contexts#env-context)."
* To reuse variables in multiple workflows, set them at the organization, repository, or environment levels and reference them using the `vars` context. For more information see "[Variables](/actions/learn-github-actions/variables)" and "[Contexts](/actions/learn-github-actions/contexts#vars-context)."
## Creating a reusable workflow

18
content/actions/using-workflows/sharing-workflows-secrets-and-runners-with-your-organization.md
View File

@@ -1,7 +1,7 @@
---
title: 'Sharing workflows, secrets, and runners with your organization'
shortTitle: Share workflows with your organization
intro: 'Learn how you can use organization features to collaborate with your team, by sharing starter workflows, secrets, and self-hosted runners.'
intro: 'Learn how you can use organization features to collaborate with your team, by sharing starter workflows, secrets,{% ifversion actions-configuration-variables %} variables,{% endif %} and self-hosted runners.'
redirect_from:
- /actions/learn-github-actions/sharing-workflows-with-your-organization
- /actions/learn-github-actions/sharing-workflows-secrets-and-runners-with-your-organization
@@ -44,22 +44,28 @@ Your organization can share workflows by reusing the workflows exactly or by cre
{% data reusables.actions.workflow-organization-templates %} For more information, see "[Creating starter workflows for your organization](/actions/using-workflows/creating-starter-workflows-for-your-organization)."
## Sharing secrets within an organization
## Sharing secrets{% ifversion actions-configuration-variables %} and variables{% endif %} within an organization
You can centrally manage your secrets within an organization, and then make them available to selected repositories. This also means that you can update a secret in one location, and have the change apply to all repository workflows that use the secret.
You can centrally manage your secrets {% ifversion actions-configuration-variables %} and variables{% endif %} within an organization, and then make them available to selected repositories. This also means that you can update a secret {% ifversion actions-configuration-variables %} or variable{% endif %} in one location, and have the change apply to all repository workflows that use the it.
When creating a secret in an organization, you can use a policy to limit which repositories can access that secret. For example, you can grant access to all repositories, or limit access to only private repositories or a specified list of repositories.
When creating a secret {% ifversion actions-configuration-variables %} or variable{% endif %} in an organization, you can use a policy to limit which repositories can access it. For example, you can grant access to all repositories, or limit access to only private repositories or a specified list of repositories.
{% data reusables.actions.permissions-statement-secrets-organization %}
{% data reusables.actions.permissions-statement-secrets-and-variables-organization %}
{% data reusables.organizations.navigate-to-org %}
{% data reusables.organizations.org_settings %}
{% data reusables.actions.sidebar-secret %}
{% data reusables.actions.sidebar-secrets-and-variables %}
{%- ifversion actions-configuration-variables %}
1. Click the **Secrets** or **Variables** tab, and create the secret or variable with your desired values and options.
For more information, see "[Creating encrypted secrets for an organization](/actions/security-guides/encrypted-secrets#creating-encrypted-secrets-for-an-organization)" or "[Creating configuration variables for an organization](/actions/learn-github-actions/variables#creating-configuration-variables-for-an-organization)."
{%- else %}
1. Click **New secret**.
1. Type a name for your secret in the **Name** input box.
1. Enter the **Value** for your secret.
1. From the **Repository access** dropdown list, choose an access policy.
1. Click **Add secret**.
{%- endif %}
## Share self-hosted runners within an organization

2
content/actions/using-workflows/triggering-a-workflow.md
View File

@@ -30,7 +30,7 @@ The following steps occur to trigger a workflow run:
1. {% data variables.product.product_name %} searches the `.github/workflows` directory in your repository for workflow files that are present in the associated commit SHA or Git ref of the event.
1. A workflow run is triggered for any workflows that have `on:` values that match the triggering event. Some events also require the workflow file to be present on the default branch of the repository in order to run.
Each workflow run will use the version of the workflow that is present in the associated commit SHA or Git ref of the event. When a workflow runs, {% data variables.product.product_name %} sets the `GITHUB_SHA` (commit SHA) and `GITHUB_REF` (Git ref) environment variables in the runner environment. For more information, see "[Using environment variables](/actions/automating-your-workflow-with-github-actions/using-environment-variables)."
Each workflow run will use the version of the workflow that is present in the associated commit SHA or Git ref of the event. When a workflow runs, {% data variables.product.product_name %} sets the `GITHUB_SHA` (commit SHA) and `GITHUB_REF` (Git ref) environment variables in the runner environment. For more information, see "[Variables](/actions/learn-github-actions/variables)."
### Triggering a workflow from a workflow

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

@@ -209,7 +209,7 @@ A boolean specifying whether the secret must be supplied.
## `env`
A `map` of environment variables that are available to the steps of all jobs in the workflow. You can also set environment variables that are only available to the steps of a single job or to a single step. For more information, see [`jobs.<job_id>.env`](#jobsjob_idenv) and [`jobs.<job_id>.steps[*].env`](#jobsjob_idstepsenv).
A `map` of variables that are available to the steps of all jobs in the workflow. You can also set variables that are only available to the steps of a single job or to a single step. For more information, see [`jobs.<job_id>.env`](#jobsjob_idenv) and [`jobs.<job_id>.steps[*].env`](#jobsjob_idstepsenv).
Variables in the `env` map cannot be defined in terms of other variables in the map.
@@ -276,7 +276,7 @@ env:
## `jobs.<job_id>.env`
A `map` of environment variables that are available to all steps in the job. You can also set environment variables for the entire workflow or an individual step. For more information, see [`env`](#env) and [`jobs.<job_id>.steps[*].env`](#jobsjob_idstepsenv).
A `map` of variables that are available to all steps in the job. You can set variables for the entire workflow or an individual step. For more information, see [`env`](#env) and [`jobs.<job_id>.steps[*].env`](#jobsjob_idstepsenv).
{% data reusables.repositories.actions-env-var-note %}
@@ -724,11 +724,11 @@ The `entrypoint` keyword is meant to be used with Docker container actions, but
### `jobs.<job_id>.steps[*].env`
Sets environment variables for steps to use in the runner environment. You can also set environment variables for the entire workflow or a job. For more information, see [`env`](#env) and [`jobs.<job_id>.env`](#jobsjob_idenv).
Sets variables for steps to use in the runner environment. You can also set variables for the entire workflow or a job. For more information, see [`env`](#env) and [`jobs.<job_id>.env`](#jobsjob_idenv).
{% data reusables.repositories.actions-env-var-note %}
Public actions may specify expected environment variables in the README file. If you are setting a secret in an environment variable, you must set secrets using the `secrets` context. For more information, see "[Using environment variables](/actions/automating-your-workflow-with-github-actions/using-environment-variables)" and "[Contexts](/actions/learn-github-actions/contexts)."
Public actions may specify expected variables in the README file. If you are setting a secret or sensitive value, such as a password or token, you must set secrets using the `secrets` context. For more information, see "[Contexts](/actions/learn-github-actions/contexts)."
#### Example

22
content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning-with-codeql.md
View File

@@ -24,10 +24,22 @@ topics:
{% data reusables.code-scanning.about-codeql-analysis %}
{% ifversion code-scanning-without-workflow %}
There are three main ways to use {% data variables.product.prodname_codeql %} analysis for {% data variables.product.prodname_code_scanning %}:
- Use default setup to automatically configure {% data variables.product.prodname_codeql %} analysis for {% data variables.product.prodname_code_scanning %} on your repository. The default setup chooses the languages to analyze, query suites to run, and events that trigger scans, then displays a summary of the analysis settings. After you enable {% data variables.product.prodname_codeql %}, {% data variables.product.prodname_actions %} will execute workflow runs to scan your code. For more information, see "[Setting up {% data variables.product.prodname_code_scanning %} for a repository](/code-security/secure-coding/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository#setting-up-code-scanning-automatically)."
- Use advanced setup to add the {% data variables.product.prodname_codeql %} workflow to your repository. This generates a customizable workflow file which uses the [github/codeql-action](https://github.com/github/codeql-action/) to run the {% data variables.product.prodname_codeql_cli %}. For more information, see "[Setting up {% data variables.product.prodname_code_scanning %} for a repository](/code-security/secure-coding/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository#creating-an-advanced-setup)."
{% else %}
There are two main ways to use {% data variables.product.prodname_codeql %} analysis for {% data variables.product.prodname_code_scanning %}:
- Add the {% data variables.product.prodname_codeql %} workflow to your repository. This uses the [github/codeql-action](https://github.com/github/codeql-action/) to run the {% data variables.product.prodname_codeql_cli %}. For more information, see "[Setting up {% data variables.product.prodname_code_scanning %} for a repository](/code-security/secure-coding/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository#setting-up-code-scanning-using-actions)."
- Run the {% data variables.product.prodname_codeql %} CLI directly in an external CI system and upload the results to {% data variables.product.prodname_dotcom %}. For more information, see "[About {% data variables.product.prodname_codeql %} code scanning in your CI system ](/code-security/secure-coding/using-codeql-code-scanning-with-your-existing-ci-system/about-codeql-code-scanning-in-your-ci-system)."
- Add the {% data variables.product.prodname_codeql %} workflow to your repository. This uses the [github/codeql-action](https://github.com/github/codeql-action/) to run the {% data variables.product.prodname_codeql_cli %}. For more information, see "[Setting up {% data variables.product.prodname_code_scanning %} for a repository](/code-security/secure-coding/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository#setting-up-code-scanning-manually)."
{% endif -%}
- Run the {% data variables.product.prodname_codeql %} CLI directly in an external CI system and upload the results to {% data variables.product.prodname_dotcom %}. For more information, see "[About {% data variables.product.prodname_codeql %} {% data variables.product.prodname_code_scanning %} in your CI system ](/code-security/secure-coding/using-codeql-code-scanning-with-your-existing-ci-system/about-codeql-code-scanning-in-your-ci-system)."
{% ifversion ghes or ghae %}
@@ -43,8 +55,8 @@ On {% data variables.product.product_name %} {% ifversion ghes %}{{ allVersions[
{% data variables.product.prodname_codeql %} treats code like data, allowing you to find potential vulnerabilities in your code with greater confidence than traditional static analyzers.
1. You generate a {% data variables.product.prodname_codeql %} database to represent your codebase.
2. Then you run {% data variables.product.prodname_codeql %} queries on that database to identify problems in the codebase.
3. The query results are shown as {% data variables.product.prodname_code_scanning %} alerts in {% data variables.product.product_name %} when you use {% data variables.product.prodname_codeql %} with {% data variables.product.prodname_code_scanning %}.
1. Then you run {% data variables.product.prodname_codeql %} queries on that database to identify problems in the codebase.
1. The query results are shown as {% data variables.product.prodname_code_scanning %} alerts in {% data variables.product.product_name %} when you use {% data variables.product.prodname_codeql %} with {% data variables.product.prodname_code_scanning %}.
{% data variables.product.prodname_codeql %} supports both compiled and interpreted languages, and can find vulnerabilities and errors in code that's written in the supported languages.
@@ -54,7 +66,7 @@ On {% data variables.product.product_name %} {% ifversion ghes %}{{ allVersions[
{% data variables.product.company_short %} experts, security researchers, and community contributors write and maintain the default {% data variables.product.prodname_codeql %} queries used for {% data variables.product.prodname_code_scanning %}. The queries are regularly updated to improve analysis and reduce any false positive results. The queries are open source, so you can view and contribute to the queries in the [`github/codeql`](https://github.com/github/codeql) repository. For more information, see [{% data variables.product.prodname_codeql %}](https://codeql.github.com/) on the {% data variables.product.prodname_codeql %} website. You can also write your own queries. For more information, see "[About {% data variables.product.prodname_codeql %} queries](https://codeql.github.com/docs/writing-codeql-queries/about-codeql-queries/)" in the {% data variables.product.prodname_codeql %} documentation.
You can run additional queries as part of your code scanning analysis.
If you are scanning your code with the advanced setup or an external CI system, you can run additional queries as part of your analysis.
{%- ifversion codeql-packs %}
These queries must belong to a published {% data variables.product.prodname_codeql %} query pack (beta) or a {% data variables.product.prodname_codeql %} pack in a repository. {% data variables.product.prodname_codeql %} packs (beta) provide the following benefits over traditional {% data variables.product.prodname_ql %} packs:

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

@@ -41,12 +41,20 @@ shortTitle: Configure code scanning
You can run {% data variables.product.prodname_code_scanning %} on {% data variables.product.product_name %}, using {% data variables.product.prodname_actions %}, or from your continuous integration (CI) system. For more information, see "[About {% data variables.product.prodname_actions %}](/actions/getting-started-with-github-actions/about-github-actions)" or "[About {% data variables.product.prodname_codeql %} {% data variables.product.prodname_code_scanning %} in your CI system](/code-security/secure-coding/about-codeql-code-scanning-in-your-ci-system)."
This article is about running {% data variables.product.prodname_code_scanning %} on {% data variables.product.product_name %} using actions.
{% ifversion code-scanning-without-workflow %}Both the default and advanced setups for {% data variables.product.prodname_code_scanning %} run on {% data variables.product.prodname_actions %}. The default setup automatically detects the best {% data variables.product.prodname_code_scanning %} configuration for your repository, while you can use the advanced setup to customize a {% data variables.product.prodname_code_scanning %} workflow. For more information, see "[Setting up {% data variables.product.prodname_code_scanning %} for a repository](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository#options-for-setting-up-code-scanning)."{% endif %} This article is about {% ifversion code-scanning-without-workflow %}configuring your advanced setup for {% data variables.product.prodname_code_scanning %}.{% else %}running {% data variables.product.prodname_code_scanning %} on {% data variables.product.product_name %} using actions.{% endif %}
Before you can configure {% data variables.product.prodname_code_scanning %} for a repository, you must set up {% data variables.product.prodname_code_scanning %} by adding a {% data variables.product.prodname_actions %} workflow to the repository. 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)."
{% ifversion code-scanning-without-workflow %}{% else %}Before you can configure {% data variables.product.prodname_code_scanning %} for a repository, you must set up {% data variables.product.prodname_code_scanning %} by adding a {% data variables.product.prodname_actions %} workflow to the repository. 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)."{% endif %}
{% ifversion code-scanning-without-workflow %}
With the advanced setup, you can edit workflows like {% data variables.product.prodname_dotcom %}'s {% data variables.code-scanning.codeql_workflow %} to specify the frequency of scans, the languages or directories to scan, and what {% data variables.product.prodname_code_scanning %} looks for in your code. You might also need to edit the workflow if you use a specific set of commands to compile your code.
{% else %}
{% data reusables.code-scanning.edit-workflow %}
{% endif %}
{% data variables.product.prodname_codeql %} analysis is just one type of {% data variables.product.prodname_code_scanning %} you can do in {% data variables.product.prodname_dotcom %}. {% data variables.product.prodname_marketplace %}{% ifversion ghes %} on {% data variables.product.prodname_dotcom_the_website %}{% endif %} contains other {% data variables.product.prodname_code_scanning %} workflows you can use. {% ifversion fpt or ghec %}You can find a selection of these on the "Get started with {% data variables.product.prodname_code_scanning %}" page, which you can access from the **{% octicon "shield" aria-label="The shield symbol" %} Security** tab.{% endif %} The specific examples given in this article relate to the {% data variables.code-scanning.codeql_workflow %} file.
## Editing a {% data variables.product.prodname_code_scanning %} workflow

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

@@ -35,14 +35,22 @@ topics:
## About the {% data variables.code-scanning.codeql_workflow %} and compiled languages
{% ifversion code-scanning-without-workflow %}
For {% data variables.product.prodname_codeql %} {% data variables.product.prodname_code_scanning %}, you can use the default setup, which analyzes your code and automatically configures your {% data variables.product.prodname_code_scanning %}, or the advanced setup, which generates a workflow file you can edit. Currently, the default setup does not support any compiled languages, so you must use the advanced setup. 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#creating-an-advanced-setup)."
{% else %}
You set up {% data variables.product.prodname_dotcom %} to run {% data variables.product.prodname_code_scanning %} for your repository by adding a {% data variables.product.prodname_actions %} workflow to the repository. For {% data variables.product.prodname_codeql %} {% data variables.product.prodname_code_scanning %}, you add the {% data variables.code-scanning.codeql_workflow %}. 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)."
{% data reusables.code-scanning.edit-workflow %}
{% endif %}
{% data reusables.code-scanning.edit-workflow %}
For general information about configuring {% data variables.product.prodname_code_scanning %} and editing workflow files, see "[Configuring {% data variables.product.prodname_code_scanning %}](/code-security/secure-coding/configuring-code-scanning)" and "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)."
## About autobuild for {% data variables.product.prodname_codeql %}
{% data variables.product.prodname_code_scanning_capc %} works by running queries against one or more databases. Each database contains a representation of all of the code in a single language in your repository.
{% data variables.product.prodname_code_scanning_capc %} works by running queries against one or more databases. Each database contains a representation of all of the code in a single language in your repository.
For the compiled languages C/C++, C#,{% ifversion codeql-go-autobuild %} Go,{% endif %}{% ifversion codeql-kotlin-beta %} Kotlin, {% endif %} and Java, the process of populating this database involves building the code and extracting data. {% data reusables.code-scanning.analyze-go %}
{% data reusables.code-scanning.autobuild-compiled-languages %}
@@ -70,13 +78,13 @@ The behavior of the `autobuild` step varies according to the operating system th
1. Invoke `MSBuild.exe` on the solution (`.sln`) or project (`.vcxproj`) file closest to the root.
If `autobuild` detects multiple solution or project files at the same (shortest) depth from the top level directory, it will attempt to build all of them.
2. Invoke a script that looks like a build script—_build.bat_, _build.cmd_, _and build.exe_ (in that order).
1. Invoke a script that looks like a build script—_build.bat_, _build.cmd_, _and build.exe_ (in that order).
On Linux and macOS, the `autobuild` step reviews the files present in the repository to determine the build system used:
1. Look for a build system in the root directory.
2. If none are found, search subdirectories for a unique directory with a build system for C/C++.
3. Run an appropriate command to configure the system.
1. If none are found, search subdirectories for a unique directory with a build system for C/C++.
1. Run an appropriate command to configure the system.
### C#
@@ -88,9 +96,9 @@ On Linux and macOS, the `autobuild` step reviews the files present in the reposi
The `autobuild` process attempts to autodetect a suitable build method for C# using the following approach:
1. Invoke `dotnet build` on the solution (`.sln`) or project (`.csproj`) file closest to the root.
2. Invoke `MSbuild` (Linux) or `MSBuild.exe` (Windows) on the solution or project file closest to the root.
1. Invoke `MSbuild` (Linux) or `MSBuild.exe` (Windows) on the solution or project file closest to the root.
If `autobuild` detects multiple solution or project files at the same (shortest) depth from the top level directory, it will attempt to build all of them.
3. Invoke a script that looks like a build script—_build_ and _build.sh_ (in that order, for Linux) or _build.bat_, _build.cmd_, _and build.exe_ (in that order, for Windows).
1. Invoke a script that looks like a build script—_build_ and _build.sh_ (in that order, for Linux) or _build.bat_, _build.cmd_, _and build.exe_ (in that order, for Windows).
{% ifversion codeql-go-autobuild %}
@@ -104,9 +112,9 @@ If `autobuild` detects multiple solution or project files at the same (shortest)
The `autobuild` process attempts to autodetect a suitable way to install the dependencies needed by a Go repository before extracting all `.go` files:
1. Invoke `make`, `ninja`, `./build` or `./build.sh` (in that order) until one of these commands succeeds and a subsequent `go list ./...` also succeeds, indicating that the needed dependencies have been installed.
2. If none of those commands succeeded, look for `go.mod`, `Gopkg.toml` or `glide.yaml`, and run `go get` (unless vendoring is in use), `dep ensure -v` or `glide install` respectively to try to install dependencies.
3. Finally, if configurations files for these dependency managers are not found, rearrange the repository directory structure suitable for addition to `GOPATH`, and use `go get` to install dependencies. The directory structure reverts to normal after extraction completes.
4. Extract all Go code in the repository, similar to running `go build ./...`.
1. If none of those commands succeeded, look for `go.mod`, `Gopkg.toml` or `glide.yaml`, and run `go get` (unless vendoring is in use), `dep ensure -v` or `glide install` respectively to try to install dependencies.
1. Finally, if configurations files for these dependency managers are not found, rearrange the repository directory structure suitable for addition to `GOPATH`, and use `go get` to install dependencies. The directory structure reverts to normal after extraction completes.
1. Extract all Go code in the repository, similar to running `go build ./...`.
{% endif %}
@@ -120,8 +128,8 @@ The `autobuild` process attempts to autodetect a suitable way to install the dep
The `autobuild` process tries to determine the build system for Java codebases by applying this strategy:
1. Search for a build file in the root directory. Check for Gradle then Maven then Ant build files.
2. Run the first build file found. If both Gradle and Maven files are present, the Gradle file is used.
3. Otherwise, search for build files in direct subdirectories of the root directory. If only one subdirectory contains build files, run the first file identified in that subdirectory (using the same preference as for 1). If more than one subdirectory contains build files, report an error.
1. Run the first build file found. If both Gradle and Maven files are present, the Gradle file is used.
1. Otherwise, search for build files in direct subdirectories of the root directory. If only one subdirectory contains build files, run the first file identified in that subdirectory (using the same preference as for 1). If more than one subdirectory contains build files, report an error.
## Adding build steps for a compiled language
@@ -140,11 +148,11 @@ For more information about the `run` keyword, see "[Workflow syntax for {% data
If your repository contains multiple compiled languages, you can specify language-specific build commands. For example, if your repository contains C/C++, C# and Java, and `autobuild` correctly builds C/C++ and C# but fails to build Java, you could use the following configuration in your workflow, after the `init` step. This specifies build steps for Java while still using `autobuild` for C/C++ and C#:
```yaml
- if: matrix.language == 'cpp' || matrix.language == 'csharp'
- if: matrix.language == 'cpp' || matrix.language == 'csharp'
name: Autobuild
uses: {% data reusables.actions.action-codeql-action-autobuild %}
- if: matrix.language == 'java'
- if: matrix.language == 'java'
name: Build Java
run: |
make bootstrap

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

@@ -25,8 +25,8 @@ children:
- /about-code-scanning-with-codeql
- /recommended-hardware-resources-for-running-codeql
- /configuring-the-codeql-workflow-for-compiled-languages
- /troubleshooting-your-default-setup-for-codeql
- /troubleshooting-the-codeql-workflow
- /running-codeql-code-scanning-in-a-container
- /viewing-code-scanning-logs
---

111
content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository.md
View File

@@ -1,7 +1,7 @@
---
title: Setting up code scanning for a repository
shortTitle: Set up code scanning
intro: 'You can set up {% data variables.product.prodname_code_scanning %} by adding a workflow to your repository.'
intro: 'You can set up {% data variables.product.prodname_code_scanning %} for a repository to find security vulnerabilities in your code.'
product: '{% data reusables.gated-features.code-scanning %}'
permissions: 'If you have write permissions to a repository, you can set up or configure {% data variables.product.prodname_code_scanning %} for that repository.'
redirect_from:
@@ -40,7 +40,7 @@ You decide how to generate {% data variables.product.prodname_code_scanning %} a
{% ifversion ghes or ghae %}
{% note %}
**Note:** If you want to use the CodeQL analysis, note that this article describes the features available with the version of the CodeQL action and associated CodeQL CLI bundle included in the initial release of this version of {% data variables.product.product_name %}. If your enterprise uses a more recent version of the CodeQL action, see the [{% data variables.product.prodname_ghe_cloud %} article](/enterprise-cloud@latest/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository) for information on the latest features. {% ifversion not ghae %} For information on using the latest version, see "[Configuring code scanning for your appliance](/admin/advanced-security/configuring-code-scanning-for-your-appliance#configuring-codeql-analysis-on-a-server-without-internet-access)."{% endif %}
**Note:** If you want to use the {% data variables.product.prodname_codeql %} analysis, note that this article describes the features available with the version of the {% data variables.product.prodname_codeql %} action and associated {% data variables.product.prodname_codeql_cli %} bundle included in the initial release of this version of {% data variables.product.product_name %}. If your enterprise uses a more recent version of the {% data variables.product.prodname_codeql %} action, see the [{% data variables.product.prodname_ghe_cloud %} article](/enterprise-cloud@latest/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository) for information on the latest features. {% ifversion not ghae %} For information on using the latest version, see "[Configuring code scanning for your appliance](/admin/advanced-security/configuring-code-scanning-for-your-appliance#configuring-codeql-analysis-on-a-server-without-internet-access)."{% endif %}
{% endnote %}
{% endif %}
@@ -53,15 +53,51 @@ Before setting up {% data variables.product.prodname_code_scanning %} for a repo
Enterprise owners, organization and repository administrators can add self-hosted runners. For more information, see "[About self-hosted runners](/actions/hosting-your-own-runners/about-self-hosted-runners)" and "[Adding self-hosted runners](/actions/hosting-your-own-runners/adding-self-hosted-runners)."
{% endif %}
{% ifversion code-scanning-without-workflow %}
## Setting up {% data variables.product.prodname_code_scanning %} automatically
The default setup for {% data variables.product.prodname_code_scanning %} will automatically configure {% data variables.product.prodname_code_scanning %} with the best settings for your repository. Your repository is eligible for default setup if it uses {% data variables.product.prodname_actions %} and contains only the following {% data variables.product.prodname_codeql %}-supported languages: JavaScript/TypeScript, Python, or Ruby. While you can use default setup if your repository includes languages that aren't supported by CodeQL, such as R, you must use the advanced setup if you include {% data variables.product.prodname_codeql %}-supported languages other than those previously listed. For more information on {% data variables.product.prodname_codeql %}-supported languages, see "[About {% data variables.product.prodname_code_scanning %} with {% data variables.product.prodname_codeql %}](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning-with-codeql#about-codeql)."
Enabling default setup is the quickest way to set up {% data variables.product.prodname_code_scanning %} for your repository. Additionally, default setup requires none of the maintenance necessary with a {% data variables.product.prodname_codeql %} workflow file. Before you enable default setup, you'll see the languages it will analyze, the query suites it will run, and the events that will trigger a new scan.
Try default setup if you don't need to run extra queries, change the scan schedule, or scan a language that is currently unsupported by default setup.
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-settings %}
{% data reusables.user-settings.security-analysis %}
1. In the "{% data variables.product.prodname_code_scanning_capc %}" section, select **Set up** {% octicon "triangle-down" aria-label="The downwards-facing triangle icon" %}, then click **Default**.
![Screenshot of the "{% data variables.product.prodname_code_scanning_capc %}" section with emphasis on the "Default" setup option](/assets/images/help/security/default-code-scanning-setup.png)
1. In the {% data variables.product.prodname_codeql %} default configuration window that is displayed, review the settings for your repository, then click **Enable {% data variables.product.prodname_codeql %}**.
![Screenshot of the "{% data variables.product.prodname_codeql %} default configuration" pop-up window with emphasis on the "Enable {% data variables.product.prodname_codeql %}" button](/assets/images/help/security/enable-codeql-default-setup.png)
{% note %}
**Notes:**
- The {% data variables.product.prodname_codeql %} default configuration window displays the details of the default setup, including the languages to analyze, the query suites to run, and the events that trigger a new scan. If you would like to change which query suites will run, what events will trigger a new scan, or other {% data variables.product.prodname_code_scanning %} features, you need to use the advanced setup. For more information, see "[Creating an advanced setup](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository#creating-an-advanced-setup)."
- If you are switching to the default setup from the advanced setup, you will see a warning informing you that the default setup will override existing configurations. Once you have enabled {% data variables.product.prodname_codeql %}, be sure to delete or disable your existing workflow file. Otherwise, the workflow will continue to run regularly without uploading any {% data variables.product.prodname_code_scanning %} results, using your {% data variables.product.prodname_actions %} minutes.
- If you would like to see your default {% data variables.product.prodname_codeql %} configuration after setup, select {% octicon "kebab-horizontal" aria-label="The horizontal kebab icon" %}, then click {% octicon "gear" aria-label="The gear icon" %} **View {% data variables.product.prodname_codeql %} configuration**.
{% endnote %}
{% endif %}
{% ifversion code-scanning-without-workflow %}
## Creating an advanced setup
The advanced setup for {% data variables.product.prodname_code_scanning %} is helpful when you need to customize your {% data variables.product.prodname_code_scanning %}. By creating and editing a workflow file, you can choose which queries to run, change the scan schedule, scan any {% data variables.product.prodname_codeql %}-supported language, use a matrix build, and more.
{% ifversion fpt or ghec %}
## Setting up {% data variables.product.prodname_code_scanning %} using starter workflows
### Setting up {% data variables.product.prodname_code_scanning %} using starter workflows
{% data reusables.advanced-security.starter-workflows-beta %}
{% ifversion ghes or ghae %}
{% note %}
**Note:** This article describes the features available with the version of the CodeQL action and associated CodeQL CLI bundle included in the initial release of this version of {% data variables.product.product_name %}. If your enterprise uses a more recent version of the CodeQL action, see the [{% data variables.product.prodname_ghe_cloud %} article](/enterprise-cloud@latest/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository) for information on the latest features. {% ifversion not ghae %} For information on using the latest version, see "[Configuring code scanning for your appliance](/admin/advanced-security/configuring-code-scanning-for-your-appliance#configuring-codeql-analysis-on-a-server-without-internet-access)."{% endif %}
**Note:** This article describes the features available with the version of the {% data variables.product.prodname_codeql %} action and associated {% data variables.product.prodname_codeql_cli %} bundle included in the initial release of this version of {% data variables.product.product_name %}. If your enterprise uses a more recent version of the {% data variables.product.prodname_codeql %} action, see the [{% data variables.product.prodname_ghe_cloud %} article](/enterprise-cloud@latest/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository) for information on the latest features. {% ifversion not ghae %} For information on using the latest version, see "[Configuring code scanning for your appliance](/admin/advanced-security/configuring-code-scanning-for-your-appliance#configuring-codeql-analysis-on-a-server-without-internet-access)."{% endif %}
{% endnote %}
{% endif %}
@@ -82,35 +118,74 @@ Enterprise owners, organization and repository administrators can add self-hoste
{% endif %}
## Setting up {% data variables.product.prodname_code_scanning %} manually
### Setting up {% data variables.product.prodname_code_scanning %} manually
{% ifversion fpt %}
You can set up {% data variables.product.prodname_code_scanning %} in any public repository where you have write access.
{% endif %}
You can customize your {% data variables.product.prodname_code_scanning %} by creating and editing a workflow file. The advanced setup generates a basic workflow file for you to customize.
{% data reusables.code-scanning.billing %}
{% ifversion fpt %}
{% note %}
**Note:** You can set up {% data variables.product.prodname_code_scanning %} in any public repository where you have write access.
{% endnote %}
{% endif %}
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-settings %}
{% data reusables.user-settings.security-analysis %}
1. In the "{% data variables.product.prodname_code_scanning_capc %}" section, select **Set up** {% octicon "triangle-down" aria-label="The downwards-facing triangle icon" %}, then click **Advanced**.
{% note %}
**Note:** If you are switching to the advanced {% data variables.product.prodname_code_scanning %} setup from the default setup, in the "{% data variables.product.prodname_code_scanning_capc %}" section, select {% octicon "kebab-horizontal" aria-label="The horizontal kebab icon" %}, then click {% octicon "workflow" aria-label="The workflow icon" %} **Switch to advanced**. In the pop-up window that appears, click **Disable {% data variables.product.prodname_codeql %}**.
{% endnote %}
![Screenshot of the "{% data variables.product.prodname_code_scanning_capc %}" section with emphasis on the "Advanced" setup option](/assets/images/help/security/advanced-code-scanning-setup.png)
1. To customize how {% data variables.product.prodname_code_scanning %} scans your code, edit the workflow.
Generally, you can commit the {% data variables.code-scanning.codeql_workflow %} without making any changes to it. However, many of the third-party workflows require additional configuration, so read the comments in the workflow before committing.
For more information, see "[Configuring {% data variables.product.prodname_code_scanning %}](/code-security/secure-coding/configuring-code-scanning)."
1. Use the **Start commit** drop-down, and type a commit message.
![Start commit](/assets/images/help/repository/start-commit-commit-new-file.png)
1. Choose whether you'd like to commit directly to the default branch, or create a new branch and start a pull request.
![Choose where to commit](/assets/images/help/repository/start-commit-choose-where-to-commit.png)
1. Click **Commit new file** or **Propose new file**.
In the suggested {% data variables.code-scanning.codeql_workflow %}, {% data variables.product.prodname_code_scanning %} is configured to analyze your code each time you either push a change to the default branch or any protected branches, or raise a pull request against the default branch. As a result, {% data variables.product.prodname_code_scanning %} will now commence.
The `on:pull_request` and `on:push` triggers for code scanning are each useful for different purposes. For more information, see "[Scanning pull requests](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#scanning-pull-requests)" and "[Scanning on push](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#scanning-on-push)."
{% else %}
## Setting up {% data variables.product.prodname_code_scanning %} manually
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-security %}
1. To the right of "{% data variables.product.prodname_code_scanning_capc %} alerts", click **Set up {% data variables.product.prodname_code_scanning %}**.{% ifversion ghec or ghes or ghae %} If {% data variables.product.prodname_code_scanning %} is missing, you need to ask an organization owner or repository administrator to enable {% data variables.product.prodname_GH_advanced_security %}.{% endif %} For more information, see "[Managing security and analysis settings for your organization](/organizations/keeping-your-organization-secure/managing-security-and-analysis-settings-for-your-organization)" or "[Managing security and analysis settings for your repository](/github/administering-a-repository/managing-security-and-analysis-settings-for-your-repository)."
!["Set up {% data variables.product.prodname_code_scanning %}" button to the right of "{% data variables.product.prodname_code_scanning_capc %}" in the Security Overview](/assets/images/help/security/overview-set-up-code-scanning.png)
4. Under "Get started with {% data variables.product.prodname_code_scanning %}", click **Set up this workflow** on the {% data variables.code-scanning.codeql_workflow %} or on a third-party workflow.
1. Under "Get started with {% data variables.product.prodname_code_scanning %}", click **Set up this workflow** on the {% data variables.code-scanning.codeql_workflow %} or on a third-party workflow.
!["Set up this workflow" button under "Get started with {% data variables.product.prodname_code_scanning %}" heading](/assets/images/help/repository/code-scanning-set-up-this-workflow.png)Workflows are only displayed if they are relevant for the programming languages detected in the repository. The {% data variables.code-scanning.codeql_workflow %} is always displayed, but the "Set up this workflow" button is only enabled if {% data variables.product.prodname_codeql %} analysis supports the languages present in the repository.
5. To customize how {% data variables.product.prodname_code_scanning %} scans your code, edit the workflow.
1. To customize how {% data variables.product.prodname_code_scanning %} scans your code, edit the workflow.
Generally you can commit the {% data variables.code-scanning.codeql_workflow %} without making any changes to it. However, many of the third-party workflows require additional configuration, so read the comments in the workflow before committing.
Generally, you can commit the {% data variables.code-scanning.codeql_workflow %} without making any changes to it. However, many of the third-party workflows require additional configuration, so read the comments in the workflow before committing.
For more information, see "[Configuring {% data variables.product.prodname_code_scanning %}](/code-security/secure-coding/configuring-code-scanning)."
6. Use the **Start commit** drop-down, and type a commit message.
1. Use the **Start commit** drop-down, and type a commit message.
![Start commit](/assets/images/help/repository/start-commit-commit-new-file.png)
7. Choose whether you'd like to commit directly to the default branch, or create a new branch and start a pull request.
1. Choose whether you'd like to commit directly to the default branch, or create a new branch and start a pull request.
![Choose where to commit](/assets/images/help/repository/start-commit-choose-where-to-commit.png)
8. Click **Commit new file** or **Propose new file**.
1. Click **Commit new file** or **Propose new file**.
In the default {% data variables.code-scanning.codeql_workflow %}, {% data variables.product.prodname_code_scanning %} is configured to analyze your code each time you either push a change to the default branch or any protected branches, or raise a pull request against the default branch. As a result, {% data variables.product.prodname_code_scanning %} will now commence.
In the suggested {% data variables.code-scanning.codeql_workflow %}, {% data variables.product.prodname_code_scanning %} is configured to analyze your code each time you either push a change to the default branch or any protected branches, or raise a pull request against the default branch. As a result, {% data variables.product.prodname_code_scanning %} will now commence.
The `on:pull_request` and `on:push` triggers for code scanning are each useful for different purposes. For more information, see "[Scanning pull requests](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#scanning-pull-requests)" and "[Scanning on push](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#scanning-on-push)."
{% endif %}
## Bulk set up of {% data variables.product.prodname_code_scanning %}
You can set up {% data variables.product.prodname_code_scanning %} in many repositories at once using a script. If you'd like to use a script to raise pull requests that add a {% data variables.product.prodname_actions %} workflow to multiple repositories, see the [`jhutchings1/Create-ActionsPRs`](https://github.com/jhutchings1/Create-ActionsPRs) repository for an example using PowerShell, or [`nickliffen/ghas-enablement`](https://github.com/NickLiffen/ghas-enablement) for teams who do not have PowerShell and instead would like to use NodeJS.
@@ -137,7 +212,7 @@ After setting up {% data variables.product.prodname_code_scanning %} for your re
{% note %}
**Note:** If you raised a pull request to add the {% data variables.product.prodname_code_scanning %} workflow to the repository, alerts from that pull request aren't displayed directly on the {% data variables.product.prodname_code_scanning_capc %} page until the pull request is merged. If any alerts were found you can view these, before the pull request is merged, by clicking the **_n_ alerts found** link in the banner on the {% data variables.product.prodname_code_scanning_capc %} page.
**Note:** If you raised a pull request to add the {% data variables.product.prodname_code_scanning %} workflow to the repository, alerts from that pull request aren't displayed directly on the {% data variables.product.prodname_code_scanning_capc %} page until the pull request is merged. If any alerts were found you can view these, before the pull request is merged, by clicking the **NUMBER alerts found** link in the banner on the {% data variables.product.prodname_code_scanning_capc %} page.
![Click the "n alerts found" link](/assets/images/help/repository/code-scanning-alerts-found-link.png)

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

@@ -1,7 +1,7 @@
---
title: Troubleshooting the CodeQL workflow
shortTitle: Troubleshoot CodeQL workflow
intro: 'If you''re having problems with {% data variables.product.prodname_code_scanning %}, you can troubleshoot by using these tips for resolving issues.'
title: Troubleshooting {% ifversion code-scanning-without-workflow %}your advanced setup for CodeQL{% else %}the CodeQL workflow{% endif %}
shortTitle: Troubleshoot {% ifversion code-scanning-without-workflow %}advanced setup{% else %}CodeQL workflow{% endif %}
intro: 'If you''re having problems with {% ifversion code-scanning-without-workflow %}advanced setup for {% data variables.product.prodname_code_scanning %}{% else %}{% data variables.product.prodname_code_scanning %} setup{% endif %}, you can troubleshoot by using these tips for resolving issues.'
product: '{% data reusables.gated-features.code-scanning %}'
miniTocMaxHeadingLevel: 3
redirect_from:
@@ -9,6 +9,7 @@ redirect_from:
- /github/finding-security-vulnerabilities-and-errors-in-your-code/troubleshooting-the-codeql-workflow
- /code-security/secure-coding/troubleshooting-the-codeql-workflow
- /code-security/secure-coding/automatically-scanning-your-code-for-vulnerabilities-and-errors/troubleshooting-the-codeql-workflow
- /code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/troubleshooting-your-advanced-setup-for-codeql
versions:
fpt: '*'
ghes: '*'
@@ -26,6 +27,7 @@ topics:
- C/C++
- C#
- Java
allowTitleToDifferFromFilename: true
---
@@ -35,7 +37,7 @@ topics:
{% ifversion ghes or ghae %}
{% note %}
**Note:** This article describes the features available with the version of the CodeQL action and associated CodeQL CLI bundle included in the initial release of this version of {% data variables.product.product_name %}. If your enterprise uses a more recent version of the CodeQL action, see the [{% data variables.product.prodname_ghe_cloud %} article](/enterprise-cloud@latest/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/troubleshooting-the-codeql-workflow) for information on the latest features. {% ifversion not ghae %} For information on using the latest version, see "[Configuring code scanning for your appliance](/admin/advanced-security/configuring-code-scanning-for-your-appliance#configuring-codeql-analysis-on-a-server-without-internet-access)."{% endif %}
**Note:** This article describes the features available with the version of the {% data variables.product.prodname_codeql %} action and associated {% data variables.product.prodname_codeql_cli %} bundle included in the initial release of this version of {% data variables.product.product_name %}. If your enterprise uses a more recent version of the {% data variables.product.prodname_codeql %} action, see the [{% data variables.product.prodname_ghe_cloud %} article](/enterprise-cloud@latest/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/troubleshooting-your-advanced-setup-for-codeql) for information on the latest features. {% ifversion not ghae %} For information on using the latest version, see "[Configuring {% data variables.product.prodname_code_scanning %} for your appliance](/admin/advanced-security/configuring-code-scanning-for-your-appliance#configuring-codeql-analysis-on-a-server-without-internet-access)."{% endif %}
{% endnote %}
{% endif %}
@@ -80,13 +82,23 @@ You can create {% data variables.product.prodname_codeql %} debugging artifacts
{% endif %}
{% ifversion code-scanning-without-workflow %}
## Results are different than expected
If your {% data variables.product.prodname_code_scanning %} results are different than you expected, your repository may have both default and advanced {% data variables.product.prodname_code_scanning %} setups. When you enable default setup, this blocks any {% data variables.product.prodname_codeql %} workflow files in the repository from uploading results.
To check if default setup is enabled, navigate to the main page of the repository, then click {% octicon "gear" aria-label="The gear icon" %} **Settings**. In the "Security" section of the sidebar, click {% octicon "codescan" aria-label="The {% data variables.product.prodname_code_scanning %} icon" %} **Code security and analysis**. In the "{% data variables.product.prodname_code_scanning_capc %}" section of the page, next to "{% data variables.product.prodname_codeql %} analysis," click {% octicon "kebab-horizontal" aria-label="The horizontal kebab icon" %}. If there is a {% octicon "workflow" aria-label="The workflow icon" %} **Switch to advanced** option, you are currently using the default setup. To switch to the advanced setup and get {% data variables.product.prodname_code_scanning %} results from your custom workflow file, click {% octicon "stop" aria-label="The stop icon" %} **Disable {% data variables.product.prodname_codeql %}**. This option will only disable default setup, and your pre-existing workflow will start uploading results again. For more information, see "[Setting up {% data variables.product.prodname_code_scanning %} for a repository](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository#creating-an-advanced-setup)."
{% endif %}
## Automatic build for a compiled language fails
If an automatic build of code for a compiled language within your project fails, try the following troubleshooting steps.
- Remove the `autobuild` step from your {% data variables.product.prodname_code_scanning %} workflow and add specific build steps. For information about editing the workflow, see "[Configuring {% data variables.product.prodname_code_scanning %}](/code-security/secure-coding/configuring-code-scanning#editing-a-code-scanning-workflow)." For more information about replacing the `autobuild` step, see "[Configuring the {% data variables.product.prodname_codeql %} workflow for compiled languages](/code-security/secure-coding/configuring-the-codeql-workflow-for-compiled-languages#adding-build-steps-for-a-compiled-language)."
- If your workflow doesn't explicitly specify the languages to analyze, {% data variables.product.prodname_codeql %} implicitly detects the supported languages in your code base. In this configuration, out of the compiled languages C/C++, C#,{% ifversion codeql-go-autobuild %} Go,{% endif %} and Java, {% data variables.product.prodname_codeql %} only analyzes the language with the most source files. Edit the workflow and add a matrix specifying the languages you want to analyze. The default CodeQL analysis workflow uses such a matrix.
- If your workflow doesn't explicitly specify the languages to analyze, {% data variables.product.prodname_codeql %} implicitly detects the supported languages in your code base. In this configuration, out of the compiled languages C/C++, C#,{% ifversion codeql-go-autobuild %} Go,{% endif %} and Java, {% data variables.product.prodname_codeql %} only analyzes the language with the most source files. Edit the workflow and add a matrix specifying the languages you want to analyze. The default {% data variables.product.prodname_codeql %} analysis workflow uses such a matrix.
The following extracts from a workflow show how you can use a matrix within the job strategy to specify languages, and then reference each language within the "Initialize {% data variables.product.prodname_codeql %}" step:
@@ -110,13 +122,13 @@ If an automatic build of code for a compiled language within your project fails,
languages: {% raw %}${{ matrix.language }}{% endraw %}
```
For more information about editing the workflow, see "[Configuring code scanning](/code-security/secure-coding/configuring-code-scanning)."
For more information about editing the workflow, see "[Configuring {% data variables.product.prodname_code_scanning %}](/code-security/secure-coding/configuring-code-scanning)."
## No code found during the build
If your workflow fails with an error `No source code was seen during the build` or `The process '/opt/hostedtoolcache/CodeQL/0.0.0-20200630/x64/codeql/codeql' failed with exit code 32`, this indicates that {% data variables.product.prodname_codeql %} was unable to monitor your code. Several reasons can explain such a failure:
1. The repository may not contain source code that is written in languages supported by {% data variables.product.prodname_codeql %}. Check the list of supported languages and, if this is the case, remove the {% data variables.product.prodname_codeql %} workflow. For more information, see "[About code scanning with CodeQL](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning-with-codeql#about-codeql)
1. The repository may not contain source code that is written in languages supported by {% data variables.product.prodname_codeql %}. Check the list of supported languages and, if this is the case, remove the {% data variables.product.prodname_codeql %} workflow. For more information, see "[About {% data variables.product.prodname_code_scanning %} with CodeQL](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning-with-codeql#about-codeql)
1. Automatic language detection identified a supported language, but there is no analyzable code of that language in the repository. A typical example is when our language detection service finds a file associated with a particular programming language like a `.h`, or `.gyp` file, but no corresponding executable code is present in the repository. To solve the problem, you can manually define the languages you want to analyze by updating the list of languages in the `language` matrix. For example, the following configuration will analyze only Go, and JavaScript.
@@ -136,12 +148,12 @@ If your workflow fails with an error `No source code was seen during the build`
1. Your workflow is analyzing a compiled language (C, C++, C#,{% ifversion codeql-go-autobuild %} Go,{% endif %} or Java), but compilation does not occur between the `init` and `analyze` steps in the workflow. {% data variables.product.prodname_codeql %} requires that your build happens in between these two steps in order to observe the activity of the compiler and perform analysis.
1. Your compiled code (in C, C++, C#,{% ifversion codeql-go-autobuild %} Go,{% endif %} or Java) was compiled successfully, but {% data variables.product.prodname_codeql %} was unable to detect the compiler invocations. The most common causes are:
- Running your build process in a separate container to {% data variables.product.prodname_codeql %}. For more information, see "[Running CodeQL code scanning in a container](/code-security/secure-coding/running-codeql-code-scanning-in-a-container)."
- Running your build process in a separate container to {% data variables.product.prodname_codeql %}. For more information, see "[Running {% data variables.product.prodname_codeql %} {% data variables.product.prodname_code_scanning %} in a container](/code-security/secure-coding/running-codeql-code-scanning-in-a-container)."
- Building using a distributed build system external to GitHub Actions, using a daemon process.
- {% data variables.product.prodname_codeql %} isn't aware of the specific compiler you are using.
For .NET Framework projects, and for C# projects using either `dotnet build` or `msbuild`, you should specify `/p:UseSharedCompilation=false` in your workflow's `run` step, when you build your code.
For example, the following configuration for C# will pass the flag during the first build step.
``` yaml
@@ -228,14 +240,14 @@ If your analysis is still too slow to be run during `push` or `pull_request` eve
### Check which query suites the workflow runs
By default, there are three main query suites available for each language. If you have optimized the CodeQL database build and the process is still too long, you could reduce the number of queries you run. The default query suite is run automatically; it contains the fastest security queries with the lowest rates of false positive results.
By default, there are three main query suites available for each language. If you have optimized the {% data variables.product.prodname_codeql %} database build and the process is still too long, you could reduce the number of queries you run. The default query suite is run automatically; it contains the fastest security queries with the lowest rates of false positive results.
You may be running extra queries or query suites in addition to the default queries. Check whether the workflow defines an additional query suite or additional queries to run using the `queries` element. You can experiment with disabling the additional query suite or queries. For more information, see "[Configuring {% data variables.product.prodname_code_scanning %}](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#using-queries-in-ql-packs)."
{% ifversion codeql-ml-queries %}
{% note %}
**Note:** If you run the `security-extended` or `security-and-quality` query suite for JavaScript, then some queries use experimental technology. For more information, see "[About code scanning alerts](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning-alerts#about-experimental-alerts)."
**Note:** If you run the `security-extended` or `security-and-quality` query suite for JavaScript, then some queries use experimental technology. For more information, see "[About {% data variables.product.prodname_code_scanning %} alerts](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning-alerts#about-experimental-alerts)."
{% endnote %}
{% endif %}
@@ -299,7 +311,7 @@ This type of merge commit is authored by {% data variables.product.prodname_depe
## Error: "is not a .ql file, .qls file, a directory, or a query pack specification"
You will see this error if CodeQL is unable to find the named query, query suite, or query pack at the location requested in the workflow. There are two common reasons for this error.
You will see this error if {% data variables.product.prodname_codeql %} is unable to find the named query, query suite, or query pack at the location requested in the workflow. There are two common reasons for this error.
- There is a typo in the workflow.
- A resource the workflow refers to by path was renamed, deleted, or moved to a new location.
@@ -311,8 +323,8 @@ After verifying the location of the resource, you can update the workflow to spe
If you're using an old {% data variables.product.prodname_codeql %} workflow you may get the following warning in the output from the "Initialize {% data variables.product.prodname_codeql %}" action:
```
Warning: 1 issue was detected with this workflow: git checkout HEAD^2 is no longer
necessary. Please remove this step as Code Scanning recommends analyzing the merge
Warning: 1 issue was detected with this workflow: git checkout HEAD^2 is no longer
necessary. Please remove this step as Code Scanning recommends analyzing the merge
commit for best results.
```

34
content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/troubleshooting-your-default-setup-for-codeql.md Normal file
View File

@@ -0,0 +1,34 @@
---
title: Troubleshooting your default setup for CodeQL
shortTitle: Troubleshoot default setup
intro: 'If you''re having problems with the default {% data variables.product.prodname_code_scanning %} setup, you can troubleshoot by using these tips for resolving issues.'
product: '{% data reusables.gated-features.code-scanning %}'
miniTocMaxHeadingLevel: 3
versions:
feature: code-scanning-without-workflow
type: how_to
topics:
- Advanced Security
- Code scanning
- CodeQL
- Actions
- Troubleshooting
---
## Disabling a pre-existing {% data variables.product.prodname_codeql %} workflow
If you see two workflows named **{% data variables.product.prodname_codeql %}**, you need to disable the workflow triggered by your pre-existing {% data variables.product.prodname_codeql %} workflow file. Navigate to the main page of your repository, then click {% octicon "play" aria-label="The play icon" %} **Actions**. In the sidebar, find the two workflows named **{% data variables.product.prodname_codeql %}**, then open both workflows. Following the workflow title, look for a link to the workflow file. This file will likely be named `codeql.yml` or `codeql-analysis.yml`. Once you have found the {% data variables.product.prodname_codeql %} workflow with an associated workflow file, select {% octicon "kebab-horizontal" aria-label="The horizontal kebab icon" %} on the workflow summary page, then click **Disable workflow**. For more information about disabling workflows, see "[Disabling and enabling a workflow](/actions/managing-workflow-runs/disabling-and-enabling-a-workflow#disabling-a-workflow)."
## Using more {% data variables.product.prodname_actions %} minutes than expected
If a repository uses more {% data variables.product.prodname_actions %} minutes than expected, and you previously scanned the repository using the advanced setup for {% data variables.product.prodname_codeql %}, your pre-existing workflow file may be running in addition to the default {% data variables.product.prodname_codeql %} setup. For more information on disabling your pre-existing workflow file, see "[Disabling a pre-existing {% data variables.product.prodname_codeql %} workflow](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/troubleshooting-your-default-setup-for-codeql#disabling-a-pre-existing-codeql-workflow)."
Optionally, if you are certain you no longer need the pre-existing workflow file, you can instead delete the file from your repository. For more information, see "[Deleting files in a repository](/repositories/working-with-files/managing-files/deleting-files-in-a-repository)."
## Enabling the default setup takes too long
If enabling your default setup is taking too long, try canceling the workflow run and restarting the setup. To restart your setup, navigate to the main page of your repository, then click {% octicon "play" aria-label="The play icon" %} **Actions**. Click the **{% data variables.product.prodname_codeql %}** workflow run that's in progress, then click **Cancel workflow**. Once {% octicon "stop" aria-label="The stop icon" %} appears beside the workflow run name, navigate back to the **Code security and analysis** settings and re-enable the default setup. If the default setup continues to stall, please contact {% data variables.contact.contact_support %} or try enabling the advanced setup. For more information, see "[Setting up {% data variables.product.prodname_code_scanning %} for a repository](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository#creating-an-advanced-setup)."
## Unclear what triggered a workflow run
If you don't know what triggered an analysis, look at the log for the last scan. For more information on viewing your last scan's log, see "[Viewing {% data variables.product.prodname_code_scanning %} logs](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/viewing-code-scanning-logs#viewing-the-logging-output-from-code-scanning)."

24
content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/viewing-code-scanning-logs.md
View File

@@ -19,7 +19,7 @@ shortTitle: View code scanning logs
{% data reusables.code-scanning.beta %}
{% data reusables.code-scanning.enterprise-enable-code-scanning-actions %}
## About your {% data variables.product.prodname_code_scanning %} setup
## About your {% data variables.product.prodname_code_scanning %} setup
You can use a variety of tools to set up {% data variables.product.prodname_code_scanning %} in your repository. For more information, see "[Setting up {% data variables.product.prodname_code_scanning %} for a repository](/code-security/secure-coding/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository#options-for-setting-up-code-scanning)."
@@ -27,9 +27,9 @@ The log and diagnostic information available to you depends on the method you us
## About analysis and diagnostic information
You can see analysis and diagnostic information for {% data variables.product.prodname_code_scanning %} run using {% data variables.product.prodname_codeql %} analysis on {% data variables.product.prodname_dotcom %}.
You can see analysis and diagnostic information for {% data variables.product.prodname_code_scanning %} run using {% data variables.product.prodname_codeql %} analysis on {% data variables.product.prodname_dotcom %}.
**Analysis** information is shown for the most recent analysis in a header at the top of the list of alerts. For more information, see "[Managing code scanning alerts for your repository](/code-security/secure-coding/automatically-scanning-your-code-for-vulnerabilities-and-errors/managing-code-scanning-alerts-for-your-repository#viewing-the-alerts-for-a-repository)."
**Analysis** information is shown for the most recent analysis in a header at the top of the list of alerts. For more information, see "[Managing {% data variables.product.prodname_code_scanning %} alerts for your repository](/code-security/secure-coding/automatically-scanning-your-code-for-vulnerabilities-and-errors/managing-code-scanning-alerts-for-your-repository#viewing-the-alerts-for-a-repository)."
**Diagnostic** information is displayed in the Action workflow logs and consists of summary metrics and extractor diagnostics. For information about accessing {% data variables.product.prodname_code_scanning %} logs on {% data variables.product.prodname_dotcom %}, see "[Viewing the logging output from {% data variables.product.prodname_code_scanning %}](#viewing-the-logging-output-from-code-scanning)" below.
@@ -47,7 +47,7 @@ For information about the {% data variables.product.prodname_codeql_cli %}, see
{% ifversion codeql-action-debug-logging %}
You can see more detailed information about {% data variables.product.prodname_codeql %} extractor errors and warnings that occurred during database creation by enabling debug logging. For more information, see "[Troubleshooting the CodeQL workflow](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/troubleshooting-the-codeql-workflow#creating-codeql-debugging-artifacts-by-re-running-jobs-with-debug-logging-enabled)."
You can see more detailed information about {% data variables.product.prodname_codeql %} extractor errors and warnings that occurred during database creation by enabling debug logging. For more information, see "[Troubleshooting the {% data variables.product.prodname_codeql %} workflow](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/troubleshooting-your-advanced-setup-for-codeql#creating-codeql-debugging-artifacts-by-re-running-jobs-with-debug-logging-enabled)."
{% endif %}
@@ -65,18 +65,28 @@ After setting up {% data variables.product.prodname_code_scanning %} for your re
1. Click the entry for the {% data variables.product.prodname_code_scanning %} workflow.
2. Click the job name on the left. For example, **Analyze (LANGUAGE)**.
{%- ifversion code-scanning-without-workflow %}
{% note %}
**Note:** If you are looking for the {% data variables.product.prodname_codeql %} workflow run triggered by enabling default setup, the text of the entry is "{% data variables.product.prodname_codeql %}."
{% endnote %}
{% endif -%}
1. Click the job name on the left. For example, **Analyze (LANGUAGE)**.
![Log output from the {% data variables.product.prodname_code_scanning %} workflow](/assets/images/help/repository/code-scanning-logging-analyze-action.png)
1. Review the logging output from the actions in this workflow as they run.
1. Optionally, to see more detail about the commit that triggered the workflow run, click {% octicon "git-commit" aria-label="The commit icon" %} **SHORT COMMIT HASH**. This short commit hash is 7 lowercase characters immediately following the commit author's username.
1. Once all jobs are complete, you can view the details of any {% data variables.product.prodname_code_scanning %} alerts that were identified. For more information, see "[Managing {% data variables.product.prodname_code_scanning %} alerts for your repository](/code-security/secure-coding/managing-code-scanning-alerts-for-your-repository#viewing-the-alerts-for-a-repository)."
{% note %}
**Note:** If you raised a pull request to add the {% data variables.product.prodname_code_scanning %} workflow to the repository, alerts from that pull request aren't displayed directly on the {% data variables.product.prodname_code_scanning_capc %} page until the pull request is merged. If any alerts were found you can view these, before the pull request is merged, by clicking the **_n_ alerts found** link in the banner on the {% data variables.product.prodname_code_scanning_capc %} page.
**Note:** If you raised a pull request to add the {% data variables.product.prodname_code_scanning %} workflow to the repository, alerts from that pull request aren't displayed directly on the {% data variables.product.prodname_code_scanning_capc %} page until the pull request is merged. If any alerts were found you can view these, before the pull request is merged, by clicking the **NUMBER alerts found** link in the banner on the {% data variables.product.prodname_code_scanning_capc %} page.
![Click the "n alerts found" link](/assets/images/help/repository/code-scanning-alerts-found-link.png)
![Click the "NUMBER alerts found" link](/assets/images/help/repository/code-scanning-alerts-found-link.png)
{% endnote %}

10
content/code-security/dependabot/working-with-dependabot/managing-encrypted-secrets-for-dependabot.md
View File

@@ -26,7 +26,7 @@ shortTitle: Manage encrypted secrets
{% data variables.product.prodname_dependabot %} secrets are encrypted credentials that you create at either the organization level or the repository level.
When you add a secret at the organization level, you can specify which repositories can access the secret. You can use secrets to allow {% data variables.product.prodname_dependabot %} to update dependencies located in private package registries. When you add a secret it's encrypted before it reaches {% data variables.product.prodname_dotcom %} and it remains encrypted until it's used by {% data variables.product.prodname_dependabot %} to access a private package registry.
After you add a {% data variables.product.prodname_dependabot %} secret, you can reference it in the _dependabot.yml_ configuration file like this: {% raw %}`${{secrets.NAME}}`{% endraw %}, where "NAME" is the name you chose for the secret. For example:
After you add a {% data variables.product.prodname_dependabot %} secret, you can reference it in the _dependabot.yml_ configuration file like this: {% raw %}`${{secrets.NAME}}`{% endraw %}, where "NAME" is the name you chose for the secret. For example:
{% raw %}
```yaml
@@ -45,7 +45,7 @@ The name of a {% data variables.product.prodname_dependabot %} secret:
## Adding a repository secret for {% data variables.product.prodname_dependabot %}
{% data reusables.actions.permissions-statement-secrets-repository %}
{% data reusables.repositories.permissions-statement-secrets-repository %}
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-settings %}
@@ -63,7 +63,7 @@ The name of a {% data variables.product.prodname_dependabot %} secret:
When creating a secret in an organization, you can use a policy to limit which repositories can access that secret. For example, you can grant access to all repositories, or limit access to only private repositories or a specified list of repositories.
{% data reusables.actions.permissions-statement-secrets-organization %}
{% data reusables.organizations.secrets-permissions-statement %}
{% data reusables.organizations.navigate-to-org %}
{% data reusables.organizations.org_settings %}
@@ -75,7 +75,7 @@ When creating a secret in an organization, you can use a policy to limit which r
1. If you chose **Selected repositories**:
* Click {% octicon "gear" aria-label="The Gear icon" %}.
* Choose the repositories that can access this secret.
* Choose the repositories that can access this secret.
![Select repositories for this secret](/assets/images/help/dependabot/secret-repository-access.png)
* Click **Update selection**.
@@ -84,7 +84,7 @@ When creating a secret in an organization, you can use a policy to limit which r
The name of the secret is listed on the Dependabot secrets page. You can click **Update** to change the secret value or its access policy. You can click **Remove** to delete the secret.
![Update or remove an organization secret](/assets/images/help/dependabot/update-remove-org-secret.png)
## Adding {% data variables.product.prodname_dependabot %} to your registries IP allow list
If your private registry is configured with an IP allow list, you can find the IP addresses {% data variables.product.prodname_dependabot %} uses to access the registry in the meta API endpoint, under the `dependabot` key. For more information, see "[Meta](/rest/reference/meta)."

53
content/code-security/getting-started/securing-your-repository.md
View File

@@ -30,7 +30,7 @@ Your security needs are unique to your repository, so you may not need to enable
The first step to securing a repository is to set up who can see and modify your code. For more information, see "[Managing repository settings](/github/administering-a-repository/managing-repository-settings)."
From the main page of your repository, click **{% octicon "gear" aria-label="The Settings gear" %}Settings**, then scroll down to the "Danger Zone."
From the main page of your repository, click **{% octicon "gear" aria-label="The Settings gear" %} Settings**, then scroll down to the "Danger Zone."
- To change who can view your repository, click **Change visibility**. For more information, see "[Setting repository visibility](/github/administering-a-repository/setting-repository-visibility)."{% ifversion fpt or ghec or ghes > 3.3 or ghae > 3.3 %}
- To change who can access your repository and adjust permissions, click **Manage access**. For more information, see"[Managing teams and people with access to your repository](/github/administering-a-repository/managing-teams-and-people-with-access-to-your-repository)."{% endif %}
@@ -38,9 +38,9 @@ From the main page of your repository, click **{% octicon "gear" aria-label="The
## Setting a security policy
1. From the main page of your repository, click **{% octicon "shield" aria-label="The shield symbol" %} Security**.
2. Click **Security policy**.
3. Click **Start setup**.
4. Add information about supported versions of your project and how to report vulnerabilities.
1. Click **Security policy**.
1. Click **Start setup**.
1. Add information about supported versions of your project and how to report vulnerabilities.
For more information, see "[Adding a security policy to your repository](/code-security/getting-started/adding-a-security-policy-to-your-repository)."
@@ -50,8 +50,8 @@ For more information, see "[Adding a security policy to your repository](/code-s
The dependency graph is automatically generated for all public repositories, and you can choose to enable it for private repositories. It interprets manifest and lock files in a repository to identify dependencies.
1. From the main page of your repository, click **{% octicon "gear" aria-label="The Settings gear" %} Settings**.
2. Click **Security & analysis**.
3. Next to Dependency graph, click **Enable** or **Disable**.
1. Click **Security & analysis**.
1. Next to Dependency graph, click **Enable** or **Disable**.
{% endif %}
{% data reusables.dependabot.dependabot-alerts-dependency-graph-enterprise %}
@@ -64,8 +64,8 @@ For more information, see "[Exploring the dependencies of a repository](/code-se
{% ifversion fpt or ghec %}
1. Click your profile photo, then click **Settings**.
2. Click **Security & analysis**.
3. Click **Enable all** next to {% data variables.product.prodname_dependabot_alerts %}.
1. Click **Security & analysis**.
1. Click **Enable all** next to {% data variables.product.prodname_dependabot_alerts %}.
{% endif %}
{% data reusables.dependabot.dependabot-alerts-beta %}
@@ -77,12 +77,12 @@ For more information, see "[About {% data variables.product.prodname_dependabot_
Dependency review lets you visualize dependency changes in pull requests before they are merged into your repositories. For more information, see "[About dependency review](/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review)."
Dependency review is a {% data variables.product.prodname_GH_advanced_security %} feature. {% ifversion fpt or ghec %}Dependency review is already enabled for all public repositories. {% ifversion fpt %}Organizations that use {% data variables.product.prodname_ghe_cloud %} with {% data variables.product.prodname_advanced_security %} can additionally enable dependency review for private and internal repositories. For more information, see the [{% data variables.product.prodname_ghe_cloud %} documentation](/enterprise-cloud@latest/code-security/getting-started/securing-your-repository#managing-dependency-review). {% endif %}{% endif %}{% ifversion ghec or ghes or ghae %}To enable dependency review for a {% ifversion ghec %}private or internal {% endif %}repository, ensure that the dependency graph is enabled and enable {% data variables.product.prodname_GH_advanced_security %}.
Dependency review is a {% data variables.product.prodname_GH_advanced_security %} feature. {% ifversion fpt or ghec %}Dependency review is already enabled for all public repositories. {% ifversion fpt %}Organizations that use {% data variables.product.prodname_ghe_cloud %} with {% data variables.product.prodname_advanced_security %} can additionally enable dependency review for private and internal repositories. For more information, see the [{% data variables.product.prodname_ghe_cloud %} documentation](/enterprise-cloud@latest/code-security/getting-started/securing-your-repository#managing-dependency-review). {% endif %}{% endif %}{% ifversion ghec or ghes or ghae %}To enable dependency review for a {% ifversion ghec %}private or internal {% endif %}repository, ensure that the dependency graph is enabled and enable {% data variables.product.prodname_GH_advanced_security %}.
1. From the main page of your repository, click **{% octicon "gear" aria-label="The Settings gear" %}Settings**.
2. Click **Security & analysis**.
3. {% ifversion ghec %}If dependency graph is not already enabled, click **Enable**.{% elsif ghes or ghae %}Check that dependency graph is configured for your enterprise.{% endif %}
4. If {% data variables.product.prodname_GH_advanced_security %} is not already enabled, click **Enable**.
1. Click **Security & analysis**.
1. {% ifversion ghec %}If dependency graph is not already enabled, click **Enable**.{% elsif ghes or ghae %}Check that dependency graph is configured for your enterprise.{% endif %}
1. If {% data variables.product.prodname_GH_advanced_security %} is not already enabled, click **Enable**.
{% endif %}
@@ -93,8 +93,8 @@ Dependency review is a {% data variables.product.prodname_GH_advanced_security %
For any repository that uses {% data variables.product.prodname_dependabot_alerts %}, you can enable {% data variables.product.prodname_dependabot_security_updates %} to raise pull requests with security updates when vulnerabilities are detected.
1. From the main page of your repository, click **{% octicon "gear" aria-label="The Settings gear" %}Settings**.
2. Click **Security & analysis**.
3. Next to {% data variables.product.prodname_dependabot_security_updates %}, click **Enable**.
1. Click **Security & analysis**.
1. Next to {% data variables.product.prodname_dependabot_security_updates %}, click **Enable**.
For more information, see "[About {% data variables.product.prodname_dependabot_security_updates %}](/code-security/supply-chain-security/about-dependabot-security-updates)" and "[Configuring {% data variables.product.prodname_dependabot_security_updates %}](/code-security/supply-chain-security/configuring-dependabot-security-updates)."
@@ -104,9 +104,9 @@ You can enable {% data variables.product.prodname_dependabot %} to automatically
{% ifversion dependabot-settings-update-37 %}
1. From the main page of your repository, click **{% octicon "gear" aria-label="The Settings gear" %} Settings**.
2. Click **Security & analysis**.
3. Next to {% data variables.product.prodname_dependabot_version_updates %}, click **Enable** to create a basic *dependabot.yml* configuration file.
4. Specify the dependencies to update and commit the file to the repository. For more information, see "[Configuring Dependabot version updates](/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates#enabling-dependabot-version-updates)."
1. Click **Security & analysis**.
1. Next to {% data variables.product.prodname_dependabot_version_updates %}, click **Enable** to create a basic *dependabot.yml* configuration file.
1. Specify the dependencies to update and commit the file to the repository. For more information, see "[Configuring Dependabot version updates](/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates#enabling-dependabot-version-updates)."
{% else %}
To enable {% data variables.product.prodname_dependabot_version_updates %}, you must create a *dependabot.yml* configuration file. For more information, see "[Configuring {% data variables.product.prodname_dependabot %} version updates](/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/enabling-and-disabling-dependabot-version-updates)."
@@ -116,7 +116,18 @@ To enable {% data variables.product.prodname_dependabot_version_updates %}, you
## Configuring {% data variables.product.prodname_code_scanning %}
You can set up {% data variables.product.prodname_code_scanning %} to automatically identify vulnerabilities and errors in the code stored in your repository by using a {% data variables.code-scanning.codeql_workflow %} or third-party tool. 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)."
You can set up {% data variables.product.prodname_code_scanning %} to automatically identify vulnerabilities and errors in the code stored in your repository by using a {% data variables.code-scanning.codeql_workflow %} or third-party tool.{% ifversion code-scanning-without-workflow %} Depending on the programming languages in your repository, you can configure {% data variables.product.prodname_code_scanning %} with {% data variables.product.prodname_codeql %} using the default setup, in which {% data variables.product.prodname_dotcom %} automatically determines the languages to scan, query suites to run, and events that will trigger a new scan.{% else %} 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)."{% endif %}
{% ifversion code-scanning-without-workflow %}
1. From the main page of your repository, click {% octicon "gear" aria-label="The gear icon" %} **Settings**.
1. In the "Security" section of the sidebar, click **{% octicon "shield-lock" aria-label="The shield-lock icon" %} Code security and analysis**.
1. In the "{% data variables.product.prodname_code_scanning_capc %}" section, select **Set up** {% octicon "triangle-down" aria-label="The downwards-facing triangle icon" %}, then click **Default**.
1. In the pop-up window that appears, review the default configuration settings for your repository, then click **Enable {% data variables.product.prodname_codeql %}**.
Alternatively, you can use the advanced setup, which generates a workflow file you can edit to customize your {% data variables.product.prodname_code_scanning %} with {% data variables.product.prodname_codeql %}. 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#creating-an-advanced-setup)."
{% endif %}
{% data variables.product.prodname_code_scanning_capc %} is available {% ifversion fpt or ghec %}for all public repositories, and for private repositories owned by organizations that are part of an enterprise with a license for {% else %}for organization-owned repositories if your enterprise uses {% endif %}{% data variables.product.prodname_GH_advanced_security %}.
@@ -130,9 +141,9 @@ You can set up {% data variables.product.prodname_code_scanning %} to automatica
{% data variables.product.prodname_secret_scanning_caps %} is {% ifversion ghec %}enabled for all public repositories and is available for private repositories owned by organizations that are part of an enterprise with a license for {% else %}available for organization-owned repositories if your enterprise uses {% endif %}{% data variables.product.prodname_GH_advanced_security %}. {% ifversion fpt %}For more information, see the [{% data variables.product.prodname_ghe_cloud %} documentation](/enterprise-cloud@latest/code-security/getting-started/securing-your-repository#configuring-secret-scanning).{% else %}{% data variables.product.prodname_secret_scanning_caps %} may already be enabled for your repository, depending upon your organization's settings.
1. From the main page of your repository, click **{% octicon "gear" aria-label="The Settings gear" %}Settings**.
2. Click **Security & analysis**.
3. If {% data variables.product.prodname_GH_advanced_security %} is not already enabled, click **Enable**.
4. Next to {% data variables.product.prodname_secret_scanning_caps %}, click **Enable**.
1. Click **Security & analysis**.
1. If {% data variables.product.prodname_GH_advanced_security %} is not already enabled, click **Enable**.
1. Next to {% data variables.product.prodname_secret_scanning_caps %}, click **Enable**.
{% endif %}
{% endif %}

6
content/codespaces/managing-codespaces-for-your-organization/managing-encrypted-secrets-for-your-repository-and-organization-for-github-codespaces.md
View File

@@ -14,13 +14,13 @@ redirect_from:
- /codespaces/managing-codespaces-for-your-organization/managing-encrypted-secrets-for-your-repository-and-organization-for-codespaces
---
## About secrets
Secrets are encrypted environment variables that you create in an organization or repository. The secrets that you create are available to use in {% data variables.product.prodname_github_codespaces %}. GitHub uses a [libsodium sealed box](https://libsodium.gitbook.io/doc/public-key_cryptography/sealed_boxes) to encrypt secrets before they reach GitHub and only decrypts them when you use them in a codespace.
Organization-level secrets let you share secrets between multiple repositories, which reduces the need to create duplicate secrets. You can use access policies to control which repositories can use organization secrets.
Organization-level secrets let you share secrets between multiple repositories, which reduces the need to create duplicate secrets. You can use access policies to control which repositories can use organization secrets.
{% data reusables.codespaces.secrets-on-start %}
@@ -53,7 +53,7 @@ To create secrets for an organization repository, you must have administrator ac
When creating a secret in an organization, you can use a policy to limit which repositories can access that secret. For example, you can grant access to all repositories, or limit access to only private repositories or a specified list of repositories.
{% data reusables.actions.permissions-statement-secrets-organization %}
{% data reusables.organizations.secrets-permissions-statement %}
{% data reusables.organizations.navigate-to-org %}
{% data reusables.organizations.org_settings %}

2
content/codespaces/managing-your-codespaces/managing-encrypted-secrets-for-your-codespaces.md
View File

@@ -16,7 +16,7 @@ topics:
shortTitle: Encrypted secrets
---
## About encrypted secrets for {% data variables.product.prodname_github_codespaces %}

2
content/get-started/learning-about-github/about-github-advanced-security.md
View File

@@ -88,7 +88,7 @@ If you have an enterprise account, license use for the entire enterprise is show
{% data reusables.advanced-security.starter-workflows-beta %}
{% data reusables.advanced-security.starter-workflow-overview %}
For more information on starter workflows, see "[Setting up {% data variables.product.prodname_code_scanning %} using starter workflows](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository#setting-up-code-scanning-using-starter-workflows)" and "[Using starter workflows](/actions/using-workflows/using-starter-workflows)."
For more information on starter workflows, see "[Setting up {% data variables.product.prodname_code_scanning %} for a repository](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository#setting-up-code-scanning-using-starter-workflows)" and "[Using starter workflows](/actions/using-workflows/using-starter-workflows)."
{% endif %}

5
content/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/reviewing-the-audit-log-for-your-organization.md
View File

@@ -499,6 +499,11 @@ For more information, see "[Managing the publication of {% data variables.produc
| `remove_self_hosted_runner` | Triggered when a self-hosted runner is removed. For more information, see "[Removing a runner from an organization](/actions/hosting-your-own-runners/removing-self-hosted-runners#removing-a-runner-from-an-organization)." {% ifversion ghec %}
| `revoke_external_identity` | Triggered when an organization owner revokes a member's linked identity. For more information, see "[Viewing and managing a member's SAML access to your organization](/organizations/granting-access-to-your-organization-with-saml-single-sign-on/viewing-and-managing-a-members-saml-access-to-your-organization#viewing-and-revoking-a-linked-identity)."
| `revoke_sso_session` | Triggered when an organization owner revokes a member's SAML session. For more information, see "[Viewing and managing a member's SAML access to your organization](/organizations/granting-access-to-your-organization-with-saml-single-sign-on/viewing-and-managing-a-members-saml-access-to-your-organization#viewing-and-revoking-a-linked-identity)." {% endif %}
{%- ifversion required-workflows %}
| `required_workflow_create` | Triggered when a required workflow is created. For more information, see "[Required workflows](/actions/using-workflows/required-workflows)."
| `required_workflow_update` | Triggered when a required workflow is updated. For more information, see "[Required workflows](/actions/using-workflows/required-workflows)."
| `required_workflow_delete` | Triggered when a required workflow is deleted. For more information, see "[Required workflows](/actions/using-workflows/required-workflows)."
{%- endif %}
| `runner_group_created` | Triggered when a self-hosted runner group is created. For more information, see "[Creating a self-hosted runner group for an organization](/actions/hosting-your-own-runners/managing-access-to-self-hosted-runners-using-groups#creating-a-self-hosted-runner-group-for-an-organization)."
| `runner_group_removed` | Triggered when a self-hosted runner group is removed. For more information, see "[Removing a self-hosted runner group](/actions/hosting-your-own-runners/managing-access-to-self-hosted-runners-using-groups#removing-a-self-hosted-runner-group)."
| `runner_group_updated` | Triggered when the configuration of a self-hosted runner group is changed. For more information, see "[Changing the access policy of a self-hosted runner group](/actions/hosting-your-own-runners/managing-access-to-self-hosted-runners-using-groups#changing-the-access-policy-of-a-self-hosted-runner-group)."

51
content/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization.md
View File

@@ -81,6 +81,57 @@ You can configure this behavior for an organization using the procedure below. M
{% data reusables.actions.workflow-run-approve-link %}
{% endif %}
{% ifversion required-workflows %}
## Adding a required workflow to an organization
{% data reusables.actions.workflows.required-workflow-beta %}
You can configure required workflows to run in all or selected repositories in an organization where you are an owner. Required workflows are triggered by pull requests and must pass before a pull request can be merged. For more information, see "[Required workflows](/actions/using-workflows/required-workflows)."
#### Prerequisites
Before configuring a required workflow, note the following prerequisites:
{% data reusables.actions.workflows.required-workflow-prerequisites %}
#### Restrictions and behaviors for the source repository
Note the following restrictions and behaviors for the source repository and workflow:
{% data reusables.actions.workflows.required-workflow-source-notes %}
#### Restrictions and behaviors for the target repository
Note the following restrictions and behaviors for the target repositories:
{% data reusables.actions.workflows.required-workflow-target-notes %}
#### Configuring a required workflow for your organization
{% data reusables.profile.access_org %}
{% data reusables.profile.org_settings %}
{% data reusables.organizations.settings-sidebar-actions-general %}
1. Next to "Required Workflows", click **Add workflow**.
![Screenshot showing the 'Add workflow' button](/assets/images/help/settings/actions-required-workflows-add.png)
1. Select the repository that contains the workflow and enter the path to the workflow.
![Screenshot showing the controls for locating the required workflow](/assets/images/help/settings/actions-required-workflow-locate.png)
1. Under "Apply to repositories...", select **All repositories** to apply the required workflow to all repositories in your organization, or **Selected repositories** to choose which repositories it will apply to.
![Screenshot showing the controls for locating the required workflow](/assets/images/help/settings/actions-required-workflows-repos.png)
1. Optionally, if you chose "Selected repositories", click {% octicon "gear" aria-label="The Gear icon" %} to open the repository selection modal, then select the repositories, and click **Apply selection**. You can use filters to narrow down your search.
![Screenshot showing the controls for locating the required workflow](/assets/images/help/settings/actions-required-workflows-select-repos.png)
1. To add the required workflow, click **Add workflow**.
{% endif %}
{% ifversion fpt or ghes or ghec %}
## Enabling workflows for private repository forks

42
content/packages/working-with-a-github-packages-registry/working-with-the-container-registry.md
View File

@@ -139,17 +139,21 @@ This example builds the `hello_docker` image:
## Labelling container images
{% data reusables.package_registry.about-docker-labels %} For more information on Docker labels, see [LABEL](https://docs.docker.com/engine/reference/builder/#label) in the official Docker documentation and [Pre-Defined Annotation Keys](https://github.com/opencontainers/image-spec/blob/master/annotations.md#pre-defined-annotation-keys) in the `opencontainers/image-spec` repository.
{% data reusables.package_registry.about-annotation-keys %} Values for supported keys will appear on the package page for the image.
The following labels are supported in the {% data variables.product.prodname_container_registry %}. Supported labels will appear on the package page for the image.
For most images, you can use Docker labels to add the annotation keys to an image. For more information, see [LABEL](https://docs.docker.com/engine/reference/builder/#label) in the official Docker documentation and [Pre-Defined Annotation Keys](https://github.com/opencontainers/image-spec/blob/master/annotations.md#pre-defined-annotation-keys) in the `opencontainers/image-spec` repository.
Label | Description
For multi-arch images, you can add a description to the image by adding the appropriate annotation key to the `annotations` field in the image's manifest. For more information, see "[Adding a description to multi-arch images](#adding-a-description-to-multi-arch-images)."
The following annotation keys are supported in the {% data variables.product.prodname_container_registry %}.
Key | Description
------|------------
| `org.opencontainers.image.source` | The URL of the repository associated with the package. For more information, see "[Connecting a repository to a package](/packages/learn-github-packages/connecting-a-repository-to-a-package#connecting-a-repository-to-a-container-image-using-the-command-line)."
| `org.opencontainers.image.description` | A text-only description limited to 512 characters. This description will appear on the package page, below the name of the package.
| `org.opencontainers.image.licenses` | An SPDX license identifier such as "MIT," limited to 256 characters. The license will appear on the package page, in the "Details" sidebar. For more information, see [SPDX License List](https://spdx.org/licenses/).
To add labels to an image, we recommend using the `LABEL` instruction in your `Dockerfile`. For example, if you're the user `monalisa` and you own `my-repo`, and your image is distributed under the terms of the MIT license, you would add the following lines to your `Dockerfile`:
To add a key as a Docker label, we recommend using the `LABEL` instruction in your `Dockerfile`. For example, if you're the user `monalisa` and you own `my-repo`, and your image is distributed under the terms of the MIT license, you would add the following lines to your `Dockerfile`:
```dockerfile
LABEL org.opencontainers.image.source=https://{% ifversion fpt or ghec %}github.com{% else %}HOSTNAME{% endif %}/monalisa/my-repo
@@ -164,3 +168,33 @@ $ docker build \
--label "org.opencontainers.image.source=https://{% ifversion fpt or ghec %}github.com{% else %}HOSTNAME{% endif %}/monalisa/my-repo" \
--label "org.opencontainers.image.description=My container image" \
--label "org.opencontainers.image.licenses=MIT"
```
### Adding a description to multi-arch images
A multi-arch image is an image that supports multiple architectures. It works by referencing a list of images, each supporting a different architecture, within a single manifest.
The description that appears on the package page for a multi-arch image is obtained from the `annotations` field in the image's manifest. Like Docker labels, annotations provide a way to associate metadata with an image, and support pre-defined annotation keys. For more information, see [Annotations](https://github.com/opencontainers/image-spec/blob/main/annotations.md) in the `opencontainers/image-spec` repository.
To provide a description for a multi-arch image, set a value for the `org.opencontainers.image.description` key in the `annotations` field of the manifest, as follows.
```json
"annotations": {
"org.opencontainers.image.description": "My multi-arch image"
}
```
For example, the following {% data variables.product.prodname_actions %} workflow step builds and pushes a multi-arch image. The `outputs` parameter sets the description for the image.
```yaml
{% data reusables.actions.actions-not-certified-by-github-comment %}
- name: Build and push Docker image
uses: docker/build-push-action@ad44023a93711e3deb337508980b4b5e9bcdc5dc
with:
context: .
file: ./Dockerfile
platforms: {% raw %}${{ matrix.platforms }}{% endraw %}
push: true
outputs: type=image,name=target,annotation-index.org.opencontainers.image.description=My multi-arch image
```

2
content/rest/actions/index.md
View File

@@ -17,7 +17,9 @@ children:
- /cache
- /oidc
- /permissions
- /required-workflows
- /secrets
- /variables
- /self-hosted-runner-groups
- /self-hosted-runners
- /workflow-jobs

12
content/rest/actions/required-workflows.md Normal file
View File

@@ -0,0 +1,12 @@
---
title: GitHub Actions Required Workflows
allowTitleToDifferFromFilename: true
shortTitle: Required Workflows
intro: 'Use the REST API to access and configure required workflows in an organization in {% data variables.product.prodname_actions %}.'
topics:
- API
versions:
fpt: '*'
ghec: '*'
ghes: '>=3.8'
---

18
content/rest/actions/variables.md Normal file
View File

@@ -0,0 +1,18 @@
---
title: GitHub Actions Variables
allowTitleToDifferFromFilename: true
shortTitle: Variables
intro: 'Use the REST API to interact with variables in {% data variables.product.prodname_actions %}.'
topics:
- API
versions:
fpt: '*'
ghes: '>=3.8'
ghec: '*'
---
## About variables in {% data variables.product.prodname_actions %}
You can use the REST API to create, update, delete, and retrieve information about variables that can be used in workflows in {% data variables.product.prodname_actions %}. {% data reusables.actions.about-variables %}
{% data reusables.actions.actions-authentication %} {% data variables.product.prodname_github_apps %} must have the `actions_variables/environments/organization_actions_variables` permission to use these endpoints. Authenticated users must have collaborator access to a repository to create, update, or read variables.

36
content/rest/overview/permissions-required-for-github-apps.md
View File

@@ -58,6 +58,29 @@ shortTitle: GitHub App permissions
- [`POST /repos/{owner}/{repo}/actions/workflows/{workflow_id}/dispatches`](/rest/reference/actions#create-a-workflow-dispatch-event) (write)
- [`PUT /repos/{owner}/{repo}/actions/workflows/{workflow_id}/enable`](/rest/reference/actions#enable-a-workflow) (write)
{% ifversion fpt or ghec or ghae %}- [`GET /repos/{owner}/{repo}/actions/workflows/{workflow_id}/timing`](/rest/reference/actions#get-workflow-usage) (read){% endif %}
{% ifversion fpt or ghec or ghes > 3.7 %}- [`GET /repos/{owner}/{repo}/actions/required_workflows/{required_workflow_id_for_repo}/runs`](/rest/actions/workflow-runs#list-workflow-runs-for-a-required-workflow) (read){% endif %}
{% ifversion fpt or ghec or ghes > 3.7 %}- [`GET /repos/{org}/{repo}/actions/required_workflows/{required_workflow_id_for_repo}/timing`](/rest/actions/required-workflows#get-required-workflow-usage) (read){% endif %}
{%- ifversion fpt or ghec or ghes > 3.8 %}
- [`GET /repos/{owner}/{repo}/actions/variables`](/rest/reference/actions#list-repository-variables) (read)
- [`GET /repos/{owner}/{repo}/actions/variables/{variable_name}`](/rest/reference/actions#get-a-repository-variable) (read)
- [`POST /repos/{owner}/{repo}/actions/variables/{variable_name}`](/rest/reference/actions#create-a-repository-variable) (write)
- [`PATCH /repos/{owner}/{repo}/actions/variables/{variable_name}`](/rest/reference/actions#update-a-repository-variable) (write)
- [`DELETE /repos/{owner}/{repo}/actions/variables/{variable_name}`](/rest/reference/actions#delete-a-repository-variable) (write)
- [`GET /repositories/{repository_id}/environments/{environment_name}/variables`](/rest/reference/actions#list-environment-variables) (read)
- [`GET /repositories/{repository_id}/environments/{environment_name}/variables/{variable_name}`](/rest/reference/actions#get-an-environment-variable) (read)
- [`POST /repositories/{repository_id}/environments/{environment_name}/variables/{variable_name}`](/rest/reference/actions#create-an-environment-variable) (write)
- [`PATCH /repositories/{repository_id}/environments/{environment_name}/variables/{variable_name}`](/rest/reference/actions#update-an-environment-variable) (write)
- [`DELETE /repositories/{repository_id}/environments/{environment_name}/variables/{variable_name}`](/rest/reference/actions#delete-an-environment-variable) (write)
- [`GET /orgs/{org}/actions/variables`](/rest/reference/actions#list-organization-variables) (read)
- [`GET /orgs/{org}/actions/variables/{variable_name}`](/rest/reference/actions#get-an-organization-variable) (read)
- [`POST /orgs/{org}/actions/variables/{variable_name}`](/rest/reference/actions#create-an-organization-variable) (write)
- [`PATCH /orgs/{org}/actions/variables/{variable_name}`](/rest/reference/actions#update-an-organization-variable) (write)
- [`DELETE /orgs/{org}/actions/variables/{variable_name}`](/rest/reference/actions#delete-an-organization-variable) (write)
- [`GET /orgs/{org}/actions/variables/{variable_name}/repositories`](/rest/reference/actions#list-selected-repositories-for-an-organization-variable) (read)
- [`PUT /orgs/{org}/actions/variables/{variable_name}/repositories`](/rest/reference/actions#set-selected-repositories-for-an-organization-variable) (write)
- [`PUT /orgs/{org}/actions/variables/{variable_name}/repositories/{repository_id}`](/rest/reference/actions#add-selected-repository-to-an-organization-variable) (write)
- [`DELETE /orgs/{org}/actions/variables/{variable_name}/repositories/{repository_id}`](/rest/reference/actions#remove-selected-repository-from-an-organization-variable) (write)
{%- endif %}
## Administration
@@ -477,6 +500,10 @@ shortTitle: GitHub App permissions
- [`GET /repos/{owner}/{repo}/stats/punch_card`](/rest/metrics/statistics#get-the-hourly-commit-count-for-each-day) (read)
- [`GET /search/labels`](/rest/reference/search#search-labels) (read)
- [`GET /repos/{owner}/{repo}/topics`](/rest/reference/repos#get-all-repository-topics) (read)
{% ifversion fpt or ghec or ghes > 3.7 %}- [`GET orgs/{org}/actions/required_workflows/{required_workflow_id}/repositories`](/rest/reference/actions#list-selected-repositories-required-workflows) (read){% endif %}
{% ifversion fpt or ghec or ghes > 3.7 %}- [`PUT /orgs/{org}/actions/required_workflows/{required_workflow_id}/repositories/{repository_id`}](/rest/reference/actions#add-a-repository-to-selected-repositories-list-for-a-required-workflow') (read){% endif %}
{% ifversion fpt or ghec or ghes > 3.7 %}- [`DELETE /orgs/{org}/actions/required_workflows/{required_workflow_id}/repositories/{repository_id}`](/rest/reference/actions#remove-a-repository-from-selected-repositories-list-for-a-required-workflow) (read){% endif %}
{% ifversion fpt or ghec or ghes > 3.7 %}- [`PUT /orgs/{org}/actions/required_workflows/{required_workflow_id}/repositories`](/rest/reference/actions#set-selected-repositories-for-a-required-workflow) (read){% endif %}
## Notifications
@@ -508,6 +535,15 @@ shortTitle: GitHub App permissions
{% ifversion fpt or ghec or ghes > 3.6 %}- [`DELETE /orgs/{org}/security-managers/teams/{team_slug}`](/rest/reference/orgs#remove-a-security-manager-team) (write){% endif %}
- [`PATCH /orgs/{org}`](/rest/reference/orgs/#update-an-organization) (write)
- [`GET /orgs/{org}/installations`](/rest/reference/orgs#list-app-installations-for-an-organization) (read)
{% ifversion fpt or ghec or ghes > 3.7 %}- [`GET /orgs/{org}/actions/required_workflows`](/rest/reference/actions#list-required-workflows) (read){% endif %}
{% ifversion fpt or ghec or ghes > 3.7 %}- [`GET /orgs/{org}/actions/required_workflows/{required_workflow_id}`](/rest/reference/actions#get-a-required-workflow) (read){% endif %}
{% ifversion fpt or ghec or ghes > 3.7 %}- [`GET orgs/{org}/actions/required_workflows/{required_workflow_id}/repositories`](/rest/reference/actions#list-selected-repositories-required-workflows) (read){% endif %}
{% ifversion fpt or ghec or ghes > 3.7 %}- [`POST /orgs/{org}/actions/required_workflows`](/rest/reference/actions#create-a-required-workflow) (write){% endif %}
{% ifversion fpt or ghec or ghes > 3.7 %}- [`DELETE /orgs/{org}/actions/required_workflows/{required_workflow_id}`](/rest/reference/actions#delete-a-required-workflow) (write){% endif %}
{% ifversion fpt or ghec or ghes > 3.7 %}- [`PATCH /orgs/{org}/actions/required_workflows/{required_workflow_id}`](/rest/reference/actions#update-a-required-workflow) (write){% endif %}
{% ifversion fpt or ghec or ghes > 3.7 %}- [`PUT /orgs/{org}/actions/required_workflows/{required_workflow_id}/repositories/{repository_id`}](/rest/reference/actions#add-a-repository-to-selected-repositories-list-for-a-required-workflow') (write){% endif %}
{% ifversion fpt or ghec or ghes > 3.7 %}- [`DELETE /orgs/{org}/actions/required_workflows/{required_workflow_id}/repositories/{repository_id}`](/rest/reference/actions#remove-a-repository-from-selected-repositories-list-for-a-required-workflow) (write){% endif %}
{% ifversion fpt or ghec or ghes > 3.7 %}- [`PUT /orgs/{org}/actions/required_workflows/{required_workflow_id}/repositories`](/rest/reference/actions#set-selected-repositories-for-a-required-workflow) (write){% endif %}
{% ifversion fpt or ghec %}

8
content/rest/webhooks/index.md
View File

@@ -52,10 +52,10 @@ The default format is what [existing post-receive hooks should expect](/post-rec
#### Callback URLs
Callback URLs can use the `http://` protocol.
Callback URLs can use the HTTP protocol.
# Send updates to postbin.org
http://postbin.org/123
# Send updates to a PostBin bin
https://www.toptal.com/developers/postbin/123
#### Subscribing
@@ -66,7 +66,7 @@ curl -u "user" -i \
{% data variables.product.api_url_pre %}/hub \
-F "hub.mode=subscribe" \
-F "hub.topic=https://github.com/{owner}/{repo}/events/push" \
-F "hub.callback=http://postbin.org/123"
-F "hub.callback=https://www.toptal.com/developers/postbin/123"
```
PubSubHubbub requests can be sent multiple times. If the hook already exists, it will be modified according to the request.

6
contributing/content-style-guide.md
View File

@@ -612,6 +612,12 @@ When referencing text in the user interface, reproduce the text exactly. Use quo
Microsoft Style Guide:
- [Formatting text in instructions](https://docs.microsoft.com/style-guide/procedures-instructions/formatting-text-in-instructions)
## Videos
You may add videos to reinforce text-based information but videos should never replace written content. Videos are inaccessible to some users and are also difficult to find by searching.
Videos on the GitHub Docs website must be well-produced and accessible, and conform to our content model for videos. For more information, see "[Using videos in GitHub Docs content](./videos.md)."
## Voice and tone
Use clear, simple language that’s approachable and accessible for a wide range of readers. To learn more about writing approachable content, see “[Microsoft's brand voice: Above all, simple and human](https://docs.microsoft.com/style-guide/brand-voice-above-all-simple-human) and “[Top 10 tips for Microsoft style and voice](https://docs.microsoft.com/style-guide/top-10-tips-style-voice).”

4
contributing/development.md
View File

@@ -10,9 +10,7 @@ It runs on macOS, Windows, and Linux environments.
You'll need Node.js version 16 to run the site. To install Node.js, [download the "LTS" installer from nodejs.org](https://nodejs.org). If you're using [`nodenv`](https://github.com/nodenv/nodenv), read the [`nodenv` docs](https://github.com/nodenv/nodenv#readme) for instructions on switching Node.js versions.
You'll want to [install Git LFS](https://docs.github.com/en/github/managing-large-files/versioning-large-files/installing-git-large-file-storage).
Once you've installed Node.js (which includes the popular `npm` package manager) and Git LFS, open Terminal and run the following:
Once you've installed Node.js (which includes the popular `npm` package manager), open Terminal and run the following:
```sh
git clone https://github.com/github/docs

95
contributing/videos.md Normal file
View File

@@ -0,0 +1,95 @@
# Using videos in GitHub Docs content
Videos are used in conjunction with written text to help users understand content in the GitHub docs.
Use these guidelines to determine if a video is appropriate to include in an article or on a landing page in the GitHub docs. If you have questions about whether or not a video would be a good addition to the docs, contact the Docs Content Strategy team.
The Docs team does not create or maintain video content. Videos are purely supplemental to help communicate significant or complex topics, and should be used sparingly because they aren't a content type owned by the Docs team.
## Video checklist
Use this checklist to quickly determine if a video might be appropriate to add to an article or landing page.
- [ ] Does GitHub own the video?
- [ ] Is the video well produced? (See the [Best practices](#best-practices) below for more information)
- [ ] Is the video accessible? (See the [Accessibility requirements](#accessibility-requirements))
- [ ] Is the video less than five minutes long?
- [ ] Does the video have a specific audience and purpose in the docs? If it is only relevant to a particular product or feature, you must use [versioning](#versioning)
If you answer "no" to any of these items, the video is not suitable for adding to the GitHub docs.
### Maintenance
Does the video have a maintenance schedule or a team directly responsible for auditing and updating the content if it becomes out of date?
If yes, you can include the video without any additional steps.
If no, create an issue with an appropriate target date to review or remove the video.
## Best practices
Good videos introduce an instructional agenda that includes steps and goals so that someone watching quickly knows what they will learn. Videos are demonstrative, both showing and explaining the relevant steps that are performed. Videos should be engaging and encouraging. Videos must be well produced to be included in the GitHub docs. A well produced video meets accessibility requirements, has professional narration (if it is a narrated video), has clear visuals, and comes from a reputable source such as GitHub or Microsoft.
Videos are broadly grouped into three categories: product overviews, feature videos, and tutorials. These descriptions are generalizations of each video type. Some videos might not fit perfectly in one category, but can still be useful without meeting the exact guidelines.
### Product overviews
- **Purpose**: Briefly explain what the product is, showcase the main functionality, and get people interested
- **Length**: Less than a minute
- **Possible audiences**: People who want to know if a feature is useful for their goals, people who are new to GitHub and trying to understand what the products do
- **Possible locations in the docs**: Landing pages and guides
- **Example**: "[GitHub Discussions in 60 seconds](https://www.youtube.com/watch?time_continue=28&v=IpBw2SJkFyk&feature=emb_title)" on the [Discussions landing page](https://docs.github.com/en/discussions)
### Feature videos
- **Purpose**: Supplement conceptual or procedural content
- **Length**: As short as possible, without exceeding five minutes. Break longer content into multiple shorter, focused videos
- **Possible audiences**: People who are learning about or how to use a feature
- **Possible locations in the docs**: Guides, conceptual articles, procedural articles
- **Example:** "[Pull Requests • GitHub & Git Foundations](https://www.youtube.com/watch?v=d5wpJ5VimSU&list=PLg7s6cbtAD15G8lNyoaYDuKZSKyJrgwB-&index=20)" in "[Git and GitHub learning resources](https://docs.github.com/en/get-started/quickstart/git-and-github-learning-resources#tune-in)"
### Tutorials
- **Purpose**: Help novice users get going with a product, drive adoption, or explain complex functionalities
- **Length**: Individual videos should be five minutes or less. Complex topics can have a series of shorter videos spread across an article. Total length should be a maximum of 15 minutes
- **Possible audiences**: New users of features or products
- **Possible locations**: Guides
- **Example:** "[Setting up your GitHub Enterprise licenses with Visual Studio subscriptions](https://www.youtube.com/watch?v=P_zBgp_BE_I)" in "[Setting up Visual Studio subscriptions with GitHub Enterprise](https://docs.github.com/en/enterprise-cloud@latest/billing/managing-licenses-for-visual-studio-subscriptions-with-github-enterprise/setting-up-visual-studio-subscriptions-with-github-enterprise#about-setup-of-visual-studio-subscriptions-with-github-enterprise)"
## When to use videos
We might use videos instead of other visuals such as screenshots or diagrams when it is important to show movement or changes in state, like when someone navigates from one screen to another or demos a feature that involves progressing through multiple menus.
Videos can also be helpful to introduce features or products where a 30 second video can supplement information that requires multiple paragraphs to write.
Use videos that explain the value of the procedure or concept that they are showing.
## When to not use videos
Do not use videos for features that change quickly and may make videos out of date. Do not use videos that contradict the written content or violate any parts of the [content style guide](./content-style-guide.md). Do not use videos that just show a task without explaining or elaborating on the procedure.
## Accessibility requirements
These are the minimum accessibility requirements for a video to be included in the GitHub docs. If a video violates any of these requirements, it cannot be added to the docs. Videos must meet the MAS-C standards for accessibility.
- No flashing or strobe effects
- Must have closed captions
- No graphics overlap with where captions appear
- Typography must be legible
- Any overlays must meet [WCAG contrast standards](https://webaim.org/articles/contrast/)
- Any text must be on the screen long enough to be read (the text should appear onscreen for longer than it takes to read it out loud twice)
- Must have proofread [audio and visual transcripts](https://webaim.org/techniques/captions/) for what happens scene-by-scene
- Videos do not autoplay
## Titles for videos
Titles should be descriptive and follow the guidelines for titles in the [content model](./content-model.md#titles).
## Versioning
If a video is only relevant for specific GitHub products (Free, Pro and Team; GitHub Enterprise Server; GitHub AE; and GitHub Enterprise Cloud), the video must be versioned for those products. Use [Liquid](liquid-helpers.md) conditional statements to version the videos appropriately. The Liquid conditional versioning may need to be added when the content is initially created, or may need to be added when the content is updated for a feature update or Enterprise release.
## Video hosting
Videos must be hosted somewhere that GitHub owns and can grant the Docs team access to. Videos should not track users or use cookies.
## Resources
- https://webaim.org
- https://www.w3.org/TR/WCAG22/#time-based-media

6
data/features/actions-configuration-variables.yml Normal file
View File

@@ -0,0 +1,6 @@
# Reference: #8528
# General versioning for Actions configuration variables
versions:
fpt: '*'
ghec: '*'
ghes: '>=3.8'

5
data/features/code-scanning-without-workflow.yml Normal file
View File

@@ -0,0 +1,5 @@
versions:
fpt: '*'
ghec: '*'
ghes: '>3.8'
ghae: '>3.8'

6
data/features/required-workflows.yml Normal file
View File

@@ -0,0 +1,6 @@
# Issue 8526
# Required workflows
versions:
fpt: '*'
ghec: '*'
ghes: '>=3.8'

11
data/release-notes/enterprise-server/3-3/16.yml
View File

@@ -4,12 +4,13 @@ sections:
- "**MEDIUM**: Updated [CommonMarker](https://github.com/gjtorikian/commonmarker) to address a scenario where parallel requests to the Markdown REST API could result in unbounded resource exhaustion. This vulnerability has been assigned [CVE-2022-39209](https://nvd.nist.gov/vuln/detail/CVE-2022-39209)."
- "**MEDIUM**: Scoped user-to-server tokens from GitHub Apps could bypass authorization checks in GraphQL API requests when accessing non-repository resources. This vulnerability was reported via the [GitHub Bug Bounty Program](https://bounty.github.com/)."
- "**MEDIUM**: Pull request preview links did not properly sanitize URLs, allowing a malicious user to embed dangerous links in the instances web UI. This vulnerability was reported via the [GitHub Bug Bounty program](https://bounty.github.com)."
- The [Create or update file contents API](/rest/repos/contents#create-or-update-file-contents) correctly enforces workflow scope. This vulnerability was reported via the [GitHub Bug Bounty program](https://bounty.github.com).
- |
**MEDIUM**: An incorrect authorization vulnerability was identified in GitHub Enterprise Server that allowed a repository-scoped token with read/write access to modify GitHub Actions workflow files without a workflow scope. The "[Create or Update file contents API](/rest/repos/contents#create-or-update-file-contents)" should enforce workflow scope. This vulnerability was reported via the [GitHub Bug Bounty program](https://bounty.github.com) and has been assigned [CVE-2022-46258](https://www.cve.org/CVERecord?id=CVE-2022-46258).
bugs:
- Setting the maintenance mode with an IP Exception List would not persist across upgrades.
- After configuration of Dependabot and alert digest emails, the instance would send digest emails to suspended users.
- If a user configured a pre-receive hook for multiple repositories, the instances **Hooks** page would not always display the correct status for the hook.
- Zombie processes no longer accumulate in the `gitrpcd` container.
- Setting the maintenance mode with an IP Exception List would not persist across upgrades.
- After configuration of Dependabot and alert digest emails, the instance would send digest emails to suspended users.
- If a user configured a pre-receive hook for multiple repositories, the instances **Hooks** page would not always display the correct status for the hook.
- Zombie processes no longer accumulate in the `gitrpcd` container.
known_issues:
- After upgrading to {% data variables.product.prodname_ghe_server %} 3.3, {% data variables.product.prodname_actions %} may fail to start automatically. To resolve this issue, connect to the appliance via SSH and run the `ghe-actions-start` command.
- On a freshly set up {% data variables.product.prodname_ghe_server %} instance without any users, an attacker could create the first admin user.

2
data/release-notes/enterprise-server/3-3/17.yml
View File

@@ -4,7 +4,7 @@ sections:
- |
**HIGH**: A path traversal vulnerability was identified in GitHub Enterprise Server that allowed remote code execution when building a GitHub Pages site. To exploit this vulnerability, an attacker would need permission to create and build a GitHub Pages site on the instance. This vulnerability was reported via the [GitHub Bug Bounty Program](https://bounty.github.com/) and has been assigned [CVE-2022-46256](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-46256).
- |
**HIGH**: An incorrect authorization vulnerability allowed a scoped user-to-server token to escalate to full admin access for a repository. An attacker would require an account with admin access to install a malicious GitHub App. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.7.0. This vulnerability was reported via the GitHub Bug Bounty program and has been assigned [CVE-2022-23741](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23741). bugs:
**HIGH**: An incorrect authorization vulnerability allowed a scoped user-to-server token to escalate to full admin access for a repository. An attacker would require an account with admin access to install a malicious GitHub App. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.7.0. This vulnerability was reported via the GitHub Bug Bounty program and has been assigned [CVE-2022-23741](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23741).
bugs:
- Installation of GitHub Enterprise Server on the VMware ESXi hypervisor failed due to the generation of an OVA file with an invalid capacity value.
- When users performed an operation using the API, GitHub Enterprise Server enforced repository size quotas even when disabled globally.

21
data/release-notes/enterprise-server/3-4/11.yml
View File

@@ -3,17 +3,18 @@ sections:
security_fixes:
- "**MEDIUM**: Updated [CommonMarker](https://github.com/gjtorikian/commonmarker) to address a scenario where parallel requests to the Markdown REST API could result in unbounded resource exhaustion. This vulnerability has been assigned [CVE-2022-39209](https://nvd.nist.gov/vuln/detail/CVE-2022-39209)."
- "**MEDIUM**: Scoped user-to-server tokens from GitHub Apps could bypass authorization checks in GraphQL API requests when accessing non-repository resources. This vulnerability was reported via the [GitHub Bug Bounty Program](https://bounty.github.com/)."
- "**MEDIUM**: Pull request preview links did not properly sanitize URLs, allowing a malicious user to embed dangerous links in the instances web UI. This vulnerability was reported via the [GitHub Bug Bounty program](https://bounty.github.com)."
- The [Create or update file contents API](/rest/repos/contents#create-or-update-file-contents) correctly enforces workflow scope. This vulnerability was reported via the [GitHub Bug Bounty program](https://bounty.github.com).
- "**MEDIUM**: Pull request preview links did not properly sanitize URLs, allowing a malicious user to embed dangerous links in the instances web UI. This vulnerability was reported via the [GitHub Bug Bounty program](https://bounty.github.com)."
- |
**MEDIUM**: An incorrect authorization vulnerability was identified in GitHub Enterprise Server that allowed a repository-scoped token with read/write access to modify GitHub Actions workflow files without a workflow scope. The "[Create or Update file contents API](/rest/repos/contents#create-or-update-file-contents)" should enforce workflow scope. This vulnerability was reported via the [GitHub Bug Bounty program](https://bounty.github.com) and has been assigned [CVE-2022-46258](https://www.cve.org/CVERecord?id=CVE-2022-46258).
bugs:
- If GitHub Actions was configured with S3 blob storage for the instance, content like logs and artifacts from deleted or expired workflow runs would remain in blob storage indefinitely. The instance will delete this content automatically the next time a regular background cleanup job runs.
- Setting the maintenance mode with an IP Exception List would not persist across upgrades.
- GitHub Pages builds could time out on instances in AWS that are configured for high availability.
- After configuration of Dependabot and alert digest emails, the instance would send digest emails to suspended users.
- If a user configured a pre-receive hook for multiple repositories, the instances **Hooks** page would not always display the correct status for the hook.
- In some cases, users could not merge a pull request due to unexpected status checks.
- After running migrations for the GitHub Enterprise Importer on an instance configured for high availability, replication of migration storage assets would not catch up.
- Zombie processes no longer accumulate in the `gitrpcd` container.
- If GitHub Actions was configured with S3 blob storage for the instance, content like logs and artifacts from deleted or expired workflow runs would remain in blob storage indefinitely. The instance will delete this content automatically the next time a regular background cleanup job runs.
- Setting the maintenance mode with an IP Exception List would not persist across upgrades.
- GitHub Pages builds could time out on instances in AWS that are configured for high availability.
- After configuration of Dependabot and alert digest emails, the instance would send digest emails to suspended users.
- If a user configured a pre-receive hook for multiple repositories, the instances **Hooks** page would not always display the correct status for the hook.
- In some cases, users could not merge a pull request due to unexpected status checks.
- After running migrations for the GitHub Enterprise Importer on an instance configured for high availability, replication of migration storage assets would not catch up.
- Zombie processes no longer accumulate in the `gitrpcd` container.
known_issues:
- On a freshly set up {% data variables.product.prodname_ghe_server %} instance without any users, an attacker could create the first admin user.
- Custom firewall rules are removed during the upgrade process.

2
data/release-notes/enterprise-server/3-4/12.yml
View File

@@ -4,7 +4,7 @@ sections:
- |
**HIGH**: A path traversal vulnerability was identified in GitHub Enterprise Server that allowed remote code execution when building a GitHub Pages site. To exploit this vulnerability, an attacker would need permission to create and build a GitHub Pages site on the instance. This vulnerability was reported via the [GitHub Bug Bounty Program](https://bounty.github.com/) and has been assigned [CVE-2022-46256](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-46256).
- |
**HIGH**: An incorrect authorization vulnerability allowed a scoped user-to-server token to escalate to full admin access for a repository. An attacker would require an account with admin access to install a malicious GitHub App. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.7.0. This vulnerability was reported via the GitHub Bug Bounty program and has been assigned [CVE-2022-23741](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23741). bugs:
**HIGH**: An incorrect authorization vulnerability allowed a scoped user-to-server token to escalate to full admin access for a repository. An attacker would require an account with admin access to install a malicious GitHub App. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.7.0. This vulnerability was reported via the GitHub Bug Bounty program and has been assigned [CVE-2022-23741](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23741).
bugs:
- When a site administrator ran the `ghe-repl-sync-ca-certificates` command from an instances primary node via the administrative shell (SSH), the command only replicated CA certificates from the instances primary node to a single replica node. The command did not replicate the certificates to all available replica nodes.
- Installation of GitHub Enterprise Server on the VMware ESXi hypervisor failed due to the generation of an OVA file with an invalid capacity value.

23
data/release-notes/enterprise-server/3-5/8.yml
View File

@@ -4,18 +4,19 @@ sections:
- "**MEDIUM**: Updated [CommonMarker](https://github.com/gjtorikian/commonmarker) to address a scenario where parallel requests to the Markdown REST API could result in unbounded resource exhaustion. This vulnerability has been assigned [CVE-2022-39209](https://nvd.nist.gov/vuln/detail/CVE-2022-39209)."
- "**MEDIUM**: Scoped user-to-server tokens from GitHub Apps could bypass authorization checks in GraphQL API requests when accessing non-repository resources. This vulnerability was reported via the [GitHub Bug Bounty Program](https://bounty.github.com/)."
- "**MEDIUM**: Pull request preview links did not properly sanitize URLs, allowing a malicious user to embed dangerous links in the instances web UI. This vulnerability was reported via the [GitHub Bug Bounty program](https://bounty.github.com)."
- The [Create or update file contents API](/rest/repos/contents#create-or-update-file-contents) correctly enforces workflow scope. This vulnerability was reported via the [GitHub Bug Bounty program](https://bounty.github.com).
- |
**MEDIUM**: An incorrect authorization vulnerability was identified in GitHub Enterprise Server that allowed a repository-scoped token with read/write access to modify GitHub Actions workflow files without a workflow scope. The "[Create or Update file contents API](/rest/repos/contents#create-or-update-file-contents)" should enforce workflow scope. This vulnerability was reported via the [GitHub Bug Bounty program](https://bounty.github.com) and has been assigned [CVE-2022-46258](https://www.cve.org/CVERecord?id=CVE-2022-46258).
bugs:
- Setting the maintenance mode with an IP Exception List would not persist across upgrades.
- GitHub Pages builds could time out on instances in AWS that are configured for high availability.
- After configuration of Dependabot and alert digest emails, the instance would send digest emails to suspended users.
- The audit log timestamp for Dependabot alert events returned the creation date of the alert instead of the timestamp when a user took action on the alert.
- When accessing an instances JavaScript resources from behind a proxy, the browser displayed Cross-Origin Resource Sharing (CORS) errors.
- If a user named a status check with leading or trailing spaces, the instance created a duplicate check if another check existed with the same name and no leading or trailing spaces.
- If a user configured a pre-receive hook for multiple repositories, the instances **Hooks** page would not always display the correct status for the hook.
- When an enterprise owner impersonated a user and tried to install a GitHub App, the button to confirm the installation was disabled and could not be clicked.
- After running migrations for the GitHub Enterprise Importer on an instance configured for high availability, replication of migration storage assets would not catch up.
- Zombie processes no longer accumulate in the `gitrpcd` container.
- Setting the maintenance mode with an IP Exception List would not persist across upgrades.
- GitHub Pages builds could time out on instances in AWS that are configured for high availability.
- After configuration of Dependabot and alert digest emails, the instance would send digest emails to suspended users.
- The audit log timestamp for Dependabot alert events returned the creation date of the alert instead of the timestamp when a user took action on the alert.
- When accessing an instances JavaScript resources from behind a proxy, the browser displayed Cross-Origin Resource Sharing (CORS) errors.
- If a user named a status check with leading or trailing spaces, the instance created a duplicate check if another check existed with the same name and no leading or trailing spaces.
- If a user configured a pre-receive hook for multiple repositories, the instances **Hooks** page would not always display the correct status for the hook.
- When an enterprise owner impersonated a user and tried to install a GitHub App, the button to confirm the installation was disabled and could not be clicked.
- After running migrations for the GitHub Enterprise Importer on an instance configured for high availability, replication of migration storage assets would not catch up.
- Zombie processes no longer accumulate in the `gitrpcd` container.
known_issues:
- On a freshly set up {% data variables.product.prodname_ghe_server %} instance without any users, an attacker could create the first admin user.
- Custom firewall rules are removed during the upgrade process.

2
data/release-notes/enterprise-server/3-5/9.yml
View File

@@ -4,7 +4,7 @@ sections:
- |
**HIGH**: A path traversal vulnerability was identified in GitHub Enterprise Server that allowed remote code execution when building a GitHub Pages site. To exploit this vulnerability, an attacker would need permission to create and build a GitHub Pages site on the instance. This vulnerability was reported via the [GitHub Bug Bounty Program](https://bounty.github.com/) and has been assigned [CVE-2022-46256](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-46256).
- |
**HIGH**: An incorrect authorization vulnerability allowed a scoped user-to-server token to escalate to full admin access for a repository. An attacker would require an account with admin access to install a malicious GitHub App. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.7.0. This vulnerability was reported via the GitHub Bug Bounty program and has been assigned [CVE-2022-23741](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23741). bugs:
**HIGH**: An incorrect authorization vulnerability allowed a scoped user-to-server token to escalate to full admin access for a repository. An attacker would require an account with admin access to install a malicious GitHub App. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.7.0. This vulnerability was reported via the GitHub Bug Bounty program and has been assigned [CVE-2022-23741](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23741).
bugs:
- If a GitHub Actions dependency uses a pinned SHA version, Dependabot will no longer mark the dependency as vulnerable.
- When a site administrator ran the `ghe-repl-sync-ca-certificates` command from an instances primary node via the administrative shell (SSH), the command only replicated CA certificates from the instances primary node to a single replica node. The command did not replicate the certificates to all available replica nodes.

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