Merge branch 'github:main' into patch-1
@@ -28,50 +28,58 @@ const MAX_COMMENT_SIZE = 125000
|
||||
|
||||
const PROD_URL = 'https://docs.github.com'
|
||||
|
||||
run()
|
||||
// When this file is invoked directly from action as opposed to being imported
|
||||
if (import.meta.url.endsWith(process.argv[1])) {
|
||||
const owner = context.repo.owner
|
||||
const repo = context.payload.repository.name
|
||||
const baseSHA = context.payload.pull_request.base.sha
|
||||
const headSHA = context.payload.pull_request.head.sha
|
||||
|
||||
async function run() {
|
||||
const isHealthy = await waitUntilUrlIsHealthy(new URL('/healthz', APP_URL).toString())
|
||||
if (!isHealthy) {
|
||||
return core.setFailed(`Timeout waiting for preview environment: ${APP_URL}`)
|
||||
core.setFailed(`Timeout waiting for preview environment: ${APP_URL}`)
|
||||
} else {
|
||||
const markdownTable = await main(owner, repo, baseSHA, headSHA)
|
||||
core.setOutput('changesTable', markdownTable)
|
||||
}
|
||||
}
|
||||
|
||||
async function main(owner, repo, baseSHA, headSHA) {
|
||||
const octokit = github.getOctokit(GITHUB_TOKEN)
|
||||
// get the list of file changes from the PR
|
||||
const response = await octokit.rest.repos.compareCommitsWithBasehead({
|
||||
owner: context.repo.owner,
|
||||
repo: context.payload.repository.name,
|
||||
basehead: `${context.payload.pull_request.base.sha}...${context.payload.pull_request.head.sha}`,
|
||||
owner,
|
||||
repo,
|
||||
basehead: `${baseSHA}...${headSHA}`,
|
||||
})
|
||||
|
||||
const { files } = response.data
|
||||
|
||||
let markdownTable =
|
||||
'| **Source** | **Preview** | **Production** | **What Changed** |\n|:----------- |:----------- |:----------- |:----------- |\n'
|
||||
const markdownTableHead = [
|
||||
'| **Source** | **Preview** | **Production** | **What Changed** |',
|
||||
'|:----------- |:----------- |:----------- |:----------- |',
|
||||
]
|
||||
let markdownTable = ''
|
||||
|
||||
const pathPrefix = 'content/'
|
||||
const articleFiles = files.filter(
|
||||
({ filename }) => filename.startsWith(pathPrefix) && !filename.endsWith('/index.md')
|
||||
)
|
||||
const articleFiles = files.filter(({ filename }) => filename.startsWith(pathPrefix))
|
||||
|
||||
const lines = await Promise.all(
|
||||
articleFiles.map(async (file) => {
|
||||
const sourceUrl = file.blob_url
|
||||
const fileName = file.filename.slice(pathPrefix.length)
|
||||
const fileUrl = fileName.slice(0, fileName.lastIndexOf('.'))
|
||||
const fileUrl = fileName.replace('/index.md', '').replace(/\.md$/, '')
|
||||
|
||||
// get the file contents and decode them
|
||||
// this script is called from the main branch, so we need the API call to get the contents from the branch, instead
|
||||
const fileContents = await getContents(
|
||||
context.repo.owner,
|
||||
context.payload.repository.name,
|
||||
owner,
|
||||
repo,
|
||||
// Can't get its content if it no longer exists.
|
||||
// Meaning, you'd get a 404 on the `getContents()` utility function.
|
||||
// So, to be able to get necessary meta data about what it *was*,
|
||||
// if it was removed, fall back to the 'base'.
|
||||
file.status === 'removed'
|
||||
? context.payload.pull_request.base.sha
|
||||
: context.payload.pull_request.head.sha,
|
||||
file.status === 'removed' ? baseSHA : headSHA,
|
||||
file.filename
|
||||
)
|
||||
|
||||
@@ -164,7 +172,13 @@ async function run() {
|
||||
return previous
|
||||
}, markdownTable.length)
|
||||
|
||||
if (cappedLines.length) {
|
||||
cappedLines.unshift(...markdownTableHead)
|
||||
}
|
||||
|
||||
markdownTable += cappedLines.join('\n')
|
||||
|
||||
core.setOutput('changesTable', markdownTable)
|
||||
return markdownTable
|
||||
}
|
||||
|
||||
export default main
|
||||
|
||||
67
.github/actions/clone-translations/action.yml
vendored
Normal file
@@ -0,0 +1,67 @@
|
||||
name: Clone translations
|
||||
|
||||
description: Clone all remote translations so they're available
|
||||
|
||||
inputs:
|
||||
token:
|
||||
description: PAT
|
||||
required: true
|
||||
|
||||
runs:
|
||||
using: 'composite'
|
||||
steps:
|
||||
- name: Clone Simplified Chinese
|
||||
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
|
||||
with:
|
||||
repository: github/docs-internal.zh-cn
|
||||
token: ${{ inputs.token }}
|
||||
path: translations/zh-cn
|
||||
|
||||
- name: Clone Japanese
|
||||
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
|
||||
with:
|
||||
repository: github/docs-internal.ja-jp
|
||||
token: ${{ inputs.token }}
|
||||
path: translations/ja-jp
|
||||
|
||||
- name: Clone Spanish
|
||||
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
|
||||
with:
|
||||
repository: github/docs-internal.es-es
|
||||
token: ${{ inputs.token }}
|
||||
path: translations/es-es
|
||||
|
||||
- name: Clone Portuguese
|
||||
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
|
||||
with:
|
||||
repository: github/docs-internal.pt-br
|
||||
token: ${{ inputs.token }}
|
||||
path: translations/pt-br
|
||||
|
||||
- name: Clone German
|
||||
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
|
||||
with:
|
||||
repository: github/docs-internal.de-de
|
||||
token: ${{ inputs.token }}
|
||||
path: translations/de-de
|
||||
|
||||
- name: Clone French
|
||||
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
|
||||
with:
|
||||
repository: github/docs-internal.fr-fr
|
||||
token: ${{ inputs.token }}
|
||||
path: translations/fr-fr
|
||||
|
||||
- name: Clone Russian
|
||||
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
|
||||
with:
|
||||
repository: github/docs-internal.ru-ru
|
||||
token: ${{ inputs.token }}
|
||||
path: translations/ru-ru
|
||||
|
||||
- name: Clone Korean
|
||||
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
|
||||
with:
|
||||
repository: github/docs-internal.ko-kr
|
||||
token: ${{ inputs.token }}
|
||||
path: translations/ko-kr
|
||||
22
.github/actions/node-npm-setup/action.yml
vendored
Normal 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
|
||||
70
.github/workflows/azure-prod-build-deploy.yml
vendored
@@ -71,77 +71,9 @@ jobs:
|
||||
- name: Merge docs-early-access repo's folders
|
||||
run: .github/actions-scripts/merge-early-access.sh
|
||||
|
||||
- name: Clone Simplified Chinese
|
||||
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
|
||||
- uses: ./.github/actions/clone-translations
|
||||
with:
|
||||
repository: github/docs-internal.zh-cn
|
||||
token: ${{ secrets.DOCUBOT_REPO_PAT }}
|
||||
path: translations/zh-cn
|
||||
|
||||
- name: Clone Japanese
|
||||
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
|
||||
with:
|
||||
repository: github/docs-internal.ja-jp
|
||||
token: ${{ secrets.DOCUBOT_REPO_PAT }}
|
||||
path: translations/ja-jp
|
||||
|
||||
- name: Clone Spanish
|
||||
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
|
||||
with:
|
||||
repository: github/docs-internal.es-es
|
||||
token: ${{ secrets.DOCUBOT_REPO_PAT }}
|
||||
path: translations/es-es
|
||||
|
||||
- name: Clone Portuguese
|
||||
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
|
||||
with:
|
||||
repository: github/docs-internal.pt-br
|
||||
token: ${{ secrets.DOCUBOT_REPO_PAT }}
|
||||
path: translations/pt-br
|
||||
|
||||
- name: Clone German
|
||||
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
|
||||
with:
|
||||
repository: github/docs-internal.de-de
|
||||
token: ${{ secrets.DOCUBOT_REPO_PAT }}
|
||||
path: translations/de-de
|
||||
|
||||
- name: Clone French
|
||||
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
|
||||
with:
|
||||
repository: github/docs-internal.fr-fr
|
||||
token: ${{ secrets.DOCUBOT_REPO_PAT }}
|
||||
path: translations/fr-fr
|
||||
|
||||
- name: Clone Russian
|
||||
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
|
||||
with:
|
||||
repository: github/docs-internal.ru-ru
|
||||
token: ${{ secrets.DOCUBOT_REPO_PAT }}
|
||||
path: translations/ru-ru
|
||||
|
||||
- name: Clone Korean
|
||||
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
|
||||
with:
|
||||
repository: github/docs-internal.ko-kr
|
||||
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
|
||||
|
||||
@@ -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
@@ -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
|
||||
|
||||
@@ -83,6 +83,7 @@ jobs:
|
||||
body-includes: '<!-- MODIFIED_CONTENT_LINKING_COMMENT -->'
|
||||
|
||||
- name: Update comment
|
||||
if: ${{ steps.changes.outputs.changesTable != '' }}
|
||||
uses: peter-evans/create-or-update-comment@c9fcb64660bc90ec1cc535646af190c992007c32
|
||||
with:
|
||||
comment-id: ${{ steps.findComment.outputs.comment-id }}
|
||||
|
||||
9
.github/workflows/enterprise-dates.yml
vendored
@@ -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: |
|
||||
|
||||
15
.github/workflows/keep-caches-warm.yml
vendored
@@ -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
@@ -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
@@ -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' }}
|
||||
|
||||
3
.github/workflows/manually-purge-fastly.yml
vendored
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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 }}
|
||||
|
||||
29
.github/workflows/sync-search-elasticsearch.yml
vendored
@@ -35,18 +35,6 @@ env:
|
||||
FREEZE: ${{ secrets.FREEZE }}
|
||||
ELASTICSEARCH_URL: ${{ secrets.ELASTICSEARCH_URL }}
|
||||
|
||||
# This might seem a bit strange, but it's clever. Since this action
|
||||
# uses a matrix to deal with one language at a time, we can use this
|
||||
# to pretend it's always the same directory.
|
||||
TRANSLATIONS_ROOT_ES_ES: translation
|
||||
TRANSLATIONS_ROOT_ZH_CN: translation
|
||||
TRANSLATIONS_ROOT_JA_JP: translation
|
||||
TRANSLATIONS_ROOT_PT_BR: translation
|
||||
TRANSLATIONS_ROOT_FR_FR: translation
|
||||
TRANSLATIONS_ROOT_RU_RU: translation
|
||||
TRANSLATIONS_ROOT_KO_KR: translation
|
||||
TRANSLATIONS_ROOT_DE_DE: translation
|
||||
|
||||
jobs:
|
||||
figureOutMatrix:
|
||||
runs-on: ubuntu-latest
|
||||
@@ -110,22 +98,13 @@ jobs:
|
||||
- name: Check out repo
|
||||
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
|
||||
|
||||
- name: Checkout the non-English repo
|
||||
- name: Clone all translations
|
||||
if: ${{ matrix.language != 'en' }}
|
||||
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
|
||||
uses: ./.github/actions/clone-translations
|
||||
with:
|
||||
repository: github/docs-internal.${{ fromJSON('{"zh":"zh-cn","es":"es-es","ru":"ru-ru","ja":"ja-jp","pt":"pt-br","de":"de-de","fr":"fr-fr","ko":"ko-kr"}')[matrix.language] }}
|
||||
token: ${{ secrets.DOCUBOT_READORG_REPO_WORKFLOW_SCOPES }}
|
||||
path: translation
|
||||
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: Cache nextjs build
|
||||
uses: actions/cache@9b0c1fce7a93df8e3bb8926b0d6e9d89e92f20a7
|
||||
|
||||
15
.github/workflows/sync-search-pr.yml
vendored
@@ -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
|
||||
|
||||
113
.github/workflows/test.yml
vendored
@@ -27,8 +27,36 @@ env:
|
||||
ENABLE_SEARCH_RESULTS_PAGE: true
|
||||
|
||||
jobs:
|
||||
test:
|
||||
figureOutMatrix:
|
||||
if: github.repository == 'github/docs-internal' || github.repository == 'github/docs'
|
||||
runs-on: ubuntu-latest
|
||||
outputs:
|
||||
matrix: ${{ steps.set-matrix.outputs.result }}
|
||||
steps:
|
||||
- uses: actions/github-script@d556feaca394842dc55e4734bf3bb9f685482fa0
|
||||
id: set-matrix
|
||||
with:
|
||||
script: |
|
||||
// We only want to run the 'translations' suite when we know
|
||||
// we're on the private docs-internal repo because only that
|
||||
// one has ability to clone the remote (private) translations
|
||||
// repos.
|
||||
const all = [
|
||||
'content',
|
||||
'graphql',
|
||||
'meta',
|
||||
'rendering',
|
||||
'routing',
|
||||
'unit',
|
||||
'linting',
|
||||
];
|
||||
if (context.payload.repository.full_name === 'github/docs-internal') {
|
||||
all.push('translations');
|
||||
}
|
||||
return all;
|
||||
|
||||
test:
|
||||
needs: figureOutMatrix
|
||||
# Run on ubuntu-20.04-xl if the private repo or ubuntu-latest if the public repo
|
||||
# See pull # 17442 in the private repo for context
|
||||
runs-on: ${{ fromJSON('["ubuntu-latest", "ubuntu-20.04-xl"]')[github.repository == 'github/docs-internal'] }}
|
||||
@@ -36,17 +64,7 @@ jobs:
|
||||
strategy:
|
||||
fail-fast: false
|
||||
matrix:
|
||||
test-group:
|
||||
[
|
||||
content,
|
||||
graphql,
|
||||
meta,
|
||||
rendering,
|
||||
routing,
|
||||
unit,
|
||||
linting,
|
||||
translations,
|
||||
]
|
||||
test-group: ${{ fromJSON(needs.figureOutMatrix.outputs.matrix) }}
|
||||
steps:
|
||||
- name: Install a local Elasticsearch for testing
|
||||
# For the sake of saving time, only run this step if the test-group
|
||||
@@ -67,14 +85,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: Figure out which docs-early-access branch to checkout, if internal repo
|
||||
if: ${{ github.repository == 'github/docs-internal' }}
|
||||
@@ -99,69 +110,11 @@ jobs:
|
||||
.github/actions-scripts/merge-early-access.sh
|
||||
rm -fr docs-early-access
|
||||
|
||||
- name: Clone Simplified Chinese
|
||||
- name: Clone all translations
|
||||
if: ${{ matrix.test-group == 'translations' }}
|
||||
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
|
||||
uses: ./.github/actions/clone-translations
|
||||
with:
|
||||
repository: github/docs-internal.zh-cn
|
||||
token: ${{ secrets.DOCUBOT_REPO_PAT }}
|
||||
path: translations/zh-cn
|
||||
|
||||
- name: Clone Japanese
|
||||
if: ${{ matrix.test-group == 'translations' }}
|
||||
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
|
||||
with:
|
||||
repository: github/docs-internal.ja-jp
|
||||
token: ${{ secrets.DOCUBOT_REPO_PAT }}
|
||||
path: translations/ja-jp
|
||||
|
||||
- name: Clone Spanish
|
||||
if: ${{ matrix.test-group == 'translations' }}
|
||||
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
|
||||
with:
|
||||
repository: github/docs-internal.es-es
|
||||
token: ${{ secrets.DOCUBOT_REPO_PAT }}
|
||||
path: translations/es-es
|
||||
|
||||
- name: Clone Portuguese
|
||||
if: ${{ matrix.test-group == 'translations' }}
|
||||
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
|
||||
with:
|
||||
repository: github/docs-internal.pt-br
|
||||
token: ${{ secrets.DOCUBOT_REPO_PAT }}
|
||||
path: translations/pt-br
|
||||
|
||||
- name: Clone German
|
||||
if: ${{ matrix.test-group == 'translations' }}
|
||||
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
|
||||
with:
|
||||
repository: github/docs-internal.de-de
|
||||
token: ${{ secrets.DOCUBOT_REPO_PAT }}
|
||||
path: translations/de-de
|
||||
|
||||
- name: Clone French
|
||||
if: ${{ matrix.test-group == 'translations' }}
|
||||
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
|
||||
with:
|
||||
repository: github/docs-internal.fr-fr
|
||||
token: ${{ secrets.DOCUBOT_REPO_PAT }}
|
||||
path: translations/fr-fr
|
||||
|
||||
- name: Clone Russian
|
||||
if: ${{ matrix.test-group == 'translations' }}
|
||||
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
|
||||
with:
|
||||
repository: github/docs-internal.ru-ru
|
||||
token: ${{ secrets.DOCUBOT_REPO_PAT }}
|
||||
path: translations/ru-ru
|
||||
|
||||
- name: Clone Korean
|
||||
if: ${{ matrix.test-group == 'translations' }}
|
||||
uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8
|
||||
with:
|
||||
repository: github/docs-internal.ko-kr
|
||||
token: ${{ secrets.DOCUBOT_REPO_PAT }}
|
||||
path: translations/ko-kr
|
||||
|
||||
- name: Gather files changed
|
||||
env:
|
||||
|
||||
@@ -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: |
|
||||
|
||||
8
.github/workflows/update-graphql-files.yml
vendored
@@ -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
|
||||
|
||||
1
.gitignore
vendored
@@ -14,6 +14,7 @@ coverage/
|
||||
.next
|
||||
.eslintcache
|
||||
*.tsbuildinfo
|
||||
translations/
|
||||
|
||||
# blc: broken link checker
|
||||
blc_output.log
|
||||
|
||||
|
Before Width: | Height: | Size: 10 KiB After Width: | Height: | Size: 34 KiB |
BIN
assets/images/help/codespaces/settings-sync-turn-off.png
Normal file
|
After Width: | Height: | Size: 32 KiB |
BIN
assets/images/help/codespaces/turn-off-sync-dialog.png
Normal file
|
After Width: | Height: | Size: 37 KiB |
|
After Width: | Height: | Size: 53 KiB |
|
After Width: | Height: | Size: 48 KiB |
BIN
assets/images/help/repository/actions-secrets-tab.png
Normal file
|
After Width: | Height: | Size: 51 KiB |
BIN
assets/images/help/repository/actions-variables-tab.png
Normal file
|
After Width: | Height: | Size: 47 KiB |
BIN
assets/images/help/security/advanced-code-scanning-setup.png
Normal file
|
After Width: | Height: | Size: 116 KiB |
BIN
assets/images/help/security/default-code-scanning-setup.png
Normal file
|
After Width: | Height: | Size: 115 KiB |
BIN
assets/images/help/security/enable-codeql-default-setup.png
Normal file
|
After Width: | Height: | Size: 61 KiB |
BIN
assets/images/help/settings/actions-required-workflow-locate.png
Normal file
|
After Width: | Height: | Size: 23 KiB |
BIN
assets/images/help/settings/actions-required-workflows-add.png
Normal file
|
After Width: | Height: | Size: 23 KiB |
BIN
assets/images/help/settings/actions-required-workflows-repos.png
Normal file
|
After Width: | Height: | Size: 33 KiB |
|
After Width: | Height: | Size: 27 KiB |
BIN
assets/images/help/settings/example-required-workflow.png
Normal file
|
After Width: | Height: | Size: 62 KiB |
BIN
assets/images/help/settings/view-required-workflows.png
Normal file
|
After Width: | Height: | Size: 12 KiB |
@@ -6,21 +6,21 @@ introLinks:
|
||||
quickstart: /get-started/onboarding/getting-started-with-your-github-account
|
||||
featuredLinks:
|
||||
guides:
|
||||
- /account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/changing-your-github-username
|
||||
- '{% ifversion ghae %}/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/about-your-personal-dashboard{% endif %}'
|
||||
- /account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-personal-account-settings/changing-your-github-username
|
||||
- '{% ifversion ghae %}/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-personal-account-settings/about-your-personal-dashboard{% endif %}'
|
||||
- /account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/managing-your-profile-readme
|
||||
- '{% ifversion ghae %}/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile{% endif %}'
|
||||
- /account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/about-notifications
|
||||
popular:
|
||||
- /account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/managing-your-theme-settings
|
||||
- /account-and-profile/setting-up-and-managing-your-github-user-account/managing-email-preferences/setting-your-commit-email-address
|
||||
- /account-and-profile/setting-up-and-managing-your-github-user-account/managing-access-to-your-personal-repositories/inviting-collaborators-to-a-personal-repository
|
||||
- /account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-personal-account-settings/managing-your-theme-settings
|
||||
- /account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/setting-your-commit-email-address
|
||||
- /account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-access-to-your-personal-repositories/inviting-collaborators-to-a-personal-repository
|
||||
- /account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications
|
||||
guideCards:
|
||||
- /account-and-profile/setting-up-and-managing-your-github-profile/managing-contribution-settings-on-your-profile/why-are-my-contributions-not-showing-up-on-my-profile
|
||||
- /account-and-profile/managing-subscriptions-and-notifications-on-github/viewing-and-triaging-notifications/managing-notifications-from-your-inbox
|
||||
- /account-and-profile/setting-up-and-managing-your-github-user-account/managing-email-preferences/blocking-command-line-pushes-that-expose-your-personal-email-address
|
||||
- '{% ifversion ghes or ghae %}/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/managing-the-default-branch-name-for-your-repositories{% endif %}'
|
||||
- /account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/blocking-command-line-pushes-that-expose-your-personal-email-address
|
||||
- '{% ifversion ghes or ghae %}/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-personal-account-settings/managing-the-default-branch-name-for-your-repositories{% endif %}'
|
||||
changelog:
|
||||
label: 'profiles, github-themes, notifications'
|
||||
versions:
|
||||
@@ -41,4 +41,3 @@ children:
|
||||
- /setting-up-and-managing-your-github-profile
|
||||
- /managing-subscriptions-and-notifications-on-github
|
||||
---
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -17,9 +17,9 @@ topics:
|
||||
|
||||
## Overview of OpenID Connect
|
||||
|
||||
{% data variables.product.prodname_actions %} workflows are often designed to access a cloud provider (such as AWS, Azure, GCP, or HashiCorp Vault) in order to deploy software or use the cloud's services. Before the workflow can access these resources, it will supply credentials, such as a password or token, to the cloud provider. These credentials are usually stored as a secret in {% data variables.product.prodname_dotcom %}, and the workflow presents this secret to the cloud provider every time it runs.
|
||||
{% data variables.product.prodname_actions %} workflows are often designed to access a cloud provider (such as AWS, Azure, GCP, or HashiCorp Vault) in order to deploy software or use the cloud's services. Before the workflow can access these resources, it will supply credentials, such as a password or token, to the cloud provider. These credentials are usually stored as a secret in {% data variables.product.prodname_dotcom %}, and the workflow presents this secret to the cloud provider every time it runs.
|
||||
|
||||
However, using hardcoded secrets requires you to create credentials in the cloud provider and then duplicate them in {% data variables.product.prodname_dotcom %} as a secret.
|
||||
However, using hardcoded secrets requires you to create credentials in the cloud provider and then duplicate them in {% data variables.product.prodname_dotcom %} as a secret.
|
||||
|
||||
With OpenID Connect (OIDC), you can take a different approach by configuring your workflow to request a short-lived access token directly from the cloud provider. Your cloud provider also needs to support OIDC on their end, and you must configure a trust relationship that controls which workflows are able to request the access tokens. Providers that currently support OIDC include Amazon Web Services, Azure, Google Cloud Platform, and HashiCorp Vault, among others.
|
||||
|
||||
@@ -27,7 +27,7 @@ With OpenID Connect (OIDC), you can take a different approach by configuring you
|
||||
|
||||
By updating your workflows to use OIDC tokens, you can adopt the following good security practices:
|
||||
|
||||
- **No cloud secrets**: You won't need to duplicate your cloud credentials as long-lived {% data variables.product.prodname_dotcom %} secrets. Instead, you can configure the OIDC trust on your cloud provider, and then update your workflows to request a short-lived access token from the cloud provider through OIDC.
|
||||
- **No cloud secrets**: You won't need to duplicate your cloud credentials as long-lived {% data variables.product.prodname_dotcom %} secrets. Instead, you can configure the OIDC trust on your cloud provider, and then update your workflows to request a short-lived access token from the cloud provider through OIDC.
|
||||
- **Authentication and authorization management**: You have more granular control over how workflows can use credentials, using your cloud provider's authentication (authN) and authorization (authZ) tools to control access to cloud resources.
|
||||
- **Rotating credentials**: With OIDC, your cloud provider issues a short-lived access token that is only valid for a single job, and then automatically expires.
|
||||
|
||||
@@ -48,7 +48,7 @@ When you configure your cloud to trust {% data variables.product.prodname_dotcom
|
||||
|
||||
- Before granting an access token, your cloud provider checks that the [`subject`](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) and other claims used to set conditions in its trust settings match those in the request's JSON Web Token (JWT). As a result, you must take care to correctly define the _subject_ and other conditions in your cloud provider.
|
||||
- The OIDC trust configuration steps and the syntax to set conditions for cloud roles (using _Subject_ and other claims) will vary depending on which cloud provider you're using. For some examples, see "[Example subject claims](#example-subject-claims)."
|
||||
|
||||
|
||||
### Understanding the OIDC token
|
||||
|
||||
Each job requests an OIDC token from {% data variables.product.prodname_dotcom %}'s OIDC provider, which responds with an automatically generated JSON web token (JWT) that is unique for each workflow job where it is generated. When the job runs, the OIDC token is presented to the cloud provider. To validate the token, the cloud provider checks if the OIDC token's subject and other claims are a match for the conditions that were preconfigured on the cloud role's OIDC trust definition.
|
||||
@@ -92,51 +92,58 @@ The following example OIDC token uses a subject (`sub`) that references a job en
|
||||
}
|
||||
```
|
||||
|
||||
To see all the claims supported by {% data variables.product.prodname_dotcom %}'s OIDC provider, review the `claims_supported` entries at
|
||||
To see all the claims supported by {% data variables.product.prodname_dotcom %}'s OIDC provider, review the `claims_supported` entries at
|
||||
{% ifversion ghes %}`https://HOSTNAME/_services/token/.well-known/openid-configuration`{% else %}https://token.actions.githubusercontent.com/.well-known/openid-configuration{% endif %}.
|
||||
|
||||
The token includes the standard audience, issuer, and subject claims:
|
||||
|
||||
| Claim | Description |
|
||||
| ----------- | ---------------------- |
|
||||
| `aud`| _(Audience)_ By default, this is the URL of the repository owner, such as the organization that owns the repository. This is the only claim that can be customized. You can set a custom audience with a toolkit command: [`core.getIDToken(audience)`](https://www.npmjs.com/package/@actions/core/v/1.6.0) |
|
||||
| `iss`| _(Issuer)_ The issuer of the OIDC token: {% ifversion ghes %}`https://HOSTNAME/_services/token`{% else %}`https://token.actions.githubusercontent.com`{% endif %} |
|
||||
| `aud`| _(Audience)_ By default, this is the URL of the repository owner, such as the organization that owns the repository. This is the only claim that can be customized. You can set a custom audience with a toolkit command: [`core.getIDToken(audience)`](https://www.npmjs.com/package/@actions/core/v/1.6.0) |
|
||||
| `iss`| _(Issuer)_ The issuer of the OIDC token: {% ifversion ghes %}`https://HOSTNAME/_services/token`{% else %}`https://token.actions.githubusercontent.com`{% endif %} |
|
||||
| `sub`| _(Subject)_ Defines the subject claim that is to be validated by the cloud provider. This setting is essential for making sure that access tokens are only allocated in a predictable way.|
|
||||
|
||||
The OIDC token also includes additional standard claims:
|
||||
|
||||
| Claim | Description |
|
||||
| ----------- | ---------------------- |
|
||||
| `alg`| _(Algorithm)_ The algorithm used by the OIDC provider. |
|
||||
| `exp`| _(Expires at)_ Identifies the expiry time of the JWT. |
|
||||
| `iat`| _(Issued at)_ The time when the JWT was issued. |
|
||||
| `jti`| _(JWT token identifier)_ Unique identifier for the OIDC token. |
|
||||
| `kid`| _(Key identifier)_ Unique key for the OIDC token. |
|
||||
| `nbf`| _(Not before)_ JWT is not valid for use before this time. |
|
||||
| `typ`| _(Type)_ Describes the type of token. This is a JSON Web Token (JWT). |
|
||||
| `alg`| _(Algorithm)_ The algorithm used by the OIDC provider. |
|
||||
| `exp`| _(Expires at)_ Identifies the expiry time of the JWT. |
|
||||
| `iat`| _(Issued at)_ The time when the JWT was issued. |
|
||||
| `jti`| _(JWT token identifier)_ Unique identifier for the OIDC token. |
|
||||
| `kid`| _(Key identifier)_ Unique key for the OIDC token. |
|
||||
| `nbf`| _(Not before)_ JWT is not valid for use before this time. |
|
||||
| `typ`| _(Type)_ Describes the type of token. This is a JSON Web Token (JWT). |
|
||||
|
||||
The token also includes custom claims provided by {% data variables.product.prodname_dotcom %}:
|
||||
|
||||
| Claim | Description |
|
||||
| ----------- | ---------------------- |
|
||||
| `actor`| The personal account that initiated the workflow run. |
|
||||
| `actor`| The personal account that initiated the workflow run. |
|
||||
| `actor_id`| The ID of personal account that initiated the workflow run. |
|
||||
| `base_ref`| The target branch of the pull request in a workflow run. |
|
||||
| `environment`| The name of the environment used by the job. |
|
||||
| `event_name`| The name of the event that triggered the workflow run. |
|
||||
| `head_ref`| The source branch of the pull request in a workflow run. |
|
||||
| `job_workflow_ref`| This is the ref path to the reusable workflow used by this job. For more information, see "["Using OpenID Connect with reusable workflows"](/actions/deployment/security-hardening-your-deployments/using-openid-connect-with-reusable-workflows)." |
|
||||
| `ref`| _(Reference)_ The git ref that triggered the workflow run. |
|
||||
| `ref_type`| The type of `ref`, for example: "branch". |
|
||||
| `repository_visibility` | The visibility of the repository where the workflow is running. Accepts the following values: `internal`, `private`, or `public`. |
|
||||
| `repository`| The repository from where the workflow is running. |
|
||||
| `base_ref`| The target branch of the pull request in a workflow run. |
|
||||
| `environment`| The name of the environment used by the job. |
|
||||
| `event_name`| The name of the event that triggered the workflow run. |
|
||||
| `head_ref`| The source branch of the pull request in a workflow run. |
|
||||
| `job_workflow_ref`| For jobs using a reusable workflow, the ref path to the reusable workflow. For more information, see "[Using OpenID Connect with reusable workflows](/actions/deployment/security-hardening-your-deployments/using-openid-connect-with-reusable-workflows)." |
|
||||
{%- ifversion actions-oidc-custom-claims %}
|
||||
| `job_workflow_sha`| {% data reusables.actions.job-workflow-sha-description %} |
|
||||
{%- endif %}
|
||||
| `ref`| _(Reference)_ The git ref that triggered the workflow run. |
|
||||
| `ref_type`| The type of `ref`, for example: "branch". |
|
||||
| `repository_visibility` | The visibility of the repository where the workflow is running. Accepts the following values: `internal`, `private`, or `public`. |
|
||||
| `repository`| The repository from where the workflow is running. |
|
||||
| `repository_id`| The ID of the repository from where the workflow is running. |
|
||||
| `repository_owner`| The name of the organization in which the `repository` is stored. |
|
||||
| `repository_owner`| The name of the organization in which the `repository` is stored. |
|
||||
| `repository_owner_id`| The ID of the organization in which the `repository` is stored. |
|
||||
| `run_id`| The ID of the workflow run that triggered the workflow. |
|
||||
| `run_number`| The number of times this workflow has been run. |
|
||||
| `run_attempt`| The number of times this workflow run has been retried. |
|
||||
| `workflow`| The name of the workflow. |
|
||||
| `run_id`| The ID of the workflow run that triggered the workflow. |
|
||||
| `run_number`| The number of times this workflow has been run. |
|
||||
| `run_attempt`| The number of times this workflow run has been retried. |
|
||||
| `workflow`| The name of the workflow. |
|
||||
{%- ifversion actions-oidc-custom-claims %}
|
||||
| `workflow_ref`| {% data reusables.actions.workflow-ref-description %} |
|
||||
| `workflow_sha`| {% data reusables.actions.workflow-sha-description %} |
|
||||
{%- endif %}
|
||||
|
||||
### Defining trust conditions on cloud roles using OIDC claims
|
||||
|
||||
@@ -168,7 +175,7 @@ You can configure a subject that filters for a specific [environment](/actions/d
|
||||
|
||||
| | |
|
||||
| ------ | ----------- |
|
||||
| Syntax: | `repo:<orgName/repoName>:environment:<environmentName>` |
|
||||
| Syntax: | `repo:<orgName/repoName>:environment:<environmentName>` |
|
||||
| Example:| `repo:octo-org/octo-repo:environment:Production` |
|
||||
|
||||
#### Filtering for `pull_request` events
|
||||
@@ -179,7 +186,7 @@ You can configure a subject that filters for the [`pull_request`](/actions/learn
|
||||
|
||||
| | |
|
||||
| ------ | ----------- |
|
||||
| Syntax: | `repo:<orgName/repoName>:pull_request` |
|
||||
| Syntax: | `repo:<orgName/repoName>:pull_request` |
|
||||
| Example:| `repo:octo-org/octo-repo:pull_request` |
|
||||
|
||||
#### Filtering for a specific branch
|
||||
@@ -190,7 +197,7 @@ You can configure a subject that filters for a specific branch name. In this exa
|
||||
|
||||
| | |
|
||||
| ------ | ----------- |
|
||||
| Syntax: | `repo:<orgName/repoName>:ref:refs/heads/branchName` |
|
||||
| Syntax: | `repo:<orgName/repoName>:ref:refs/heads/branchName` |
|
||||
| Example:| `repo:octo-org/octo-repo:ref:refs/heads/demo-branch` |
|
||||
|
||||
#### Filtering for a specific tag
|
||||
@@ -201,7 +208,7 @@ You can create a subject that filters for specific tag. In this example, the wor
|
||||
|
||||
| | |
|
||||
| ------ | ----------- |
|
||||
| Syntax: | `repo:<orgName/repoName>:ref:refs/tags/<tagName>` |
|
||||
| Syntax: | `repo:<orgName/repoName>:ref:refs/tags/<tagName>` |
|
||||
| Example:| `repo:octo-org/octo-repo:ref:refs/tags/demo-tag` |
|
||||
|
||||
### Configuring the subject in your cloud provider
|
||||
@@ -210,7 +217,7 @@ To configure the subject in your cloud provider's trust relationship, you must a
|
||||
|
||||
| | |
|
||||
| ------ | ----------- |
|
||||
| Amazon Web Services | `"{% ifversion ghes %}HOSTNAME/_services/token{% else %}token.actions.githubusercontent.com{% endif %}:sub": "repo:octo-org/octo-repo:ref:refs/heads/demo-branch"` |
|
||||
| Amazon Web Services | `"{% ifversion ghes %}HOSTNAME/_services/token{% else %}token.actions.githubusercontent.com{% endif %}:sub": "repo:octo-org/octo-repo:ref:refs/heads/demo-branch"` |
|
||||
| Azure| `repo:octo-org/octo-repo:ref:refs/heads/demo-branch` |
|
||||
| Google Cloud Platform| `(assertion.sub=='repo:octo-org/octo-repo:ref:refs/heads/demo-branch')` |
|
||||
| HashiCorp Vault| `bound_subject="repo:octo-org/octo-repo:ref:refs/heads/demo-branch" ` |
|
||||
@@ -225,7 +232,7 @@ You could also use a `curl` command to request the JWT, using the following envi
|
||||
|
||||
| | |
|
||||
| ------ | ----------- |
|
||||
| `ACTIONS_ID_TOKEN_REQUEST_URL` | The URL for {% data variables.product.prodname_dotcom %}'s OIDC provider. |
|
||||
| `ACTIONS_ID_TOKEN_REQUEST_URL` | The URL for {% data variables.product.prodname_dotcom %}'s OIDC provider. |
|
||||
| `ACTIONS_ID_TOKEN_REQUEST_TOKEN` | Bearer token for the request to the OIDC provider. |
|
||||
|
||||
|
||||
@@ -256,7 +263,7 @@ To customize these claim formats, organization and repository admins can use the
|
||||
|
||||
By default, the JWT is issued by {% data variables.product.prodname_dotcom %}'s OIDC provider at `https://token.actions.githubusercontent.com`. This path is presented to your cloud provider using the `iss` value in the JWT.
|
||||
|
||||
Enterprise admins can security harden their OIDC configuration by configuring their enterprise to receive tokens from a unique URL at `https://token.actions.githubusercontent.com/<enterpriseSlug>`. Replace `<enterpriseSlug>` with the slug value of your enterprise.
|
||||
Enterprise admins can security harden their OIDC configuration by configuring their enterprise to receive tokens from a unique URL at `https://token.actions.githubusercontent.com/<enterpriseSlug>`. Replace `<enterpriseSlug>` with the slug value of your enterprise.
|
||||
|
||||
This configuration means that your enterprise will receive the OIDC token from a unique URL, and you can then configure your cloud provider to only accept tokens from that URL. This helps ensure that only the enterprise's repositories can access your cloud resources using OIDC.
|
||||
|
||||
@@ -291,7 +298,7 @@ To help improve security, compliance, and standardization, you can customize the
|
||||
|
||||
Customizing the claims results in a new format for the entire `sub` claim, which replaces the default predefined `sub` format in the token described in "[Example subject claims](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#example-subject-claims)."
|
||||
|
||||
The following example templates demonstrate various ways to customize the subject claim. To configure these settings on {% data variables.product.prodname_dotcom %}, admins use the REST API to specify a list of claims that must be included in the subject (`sub`) claim.
|
||||
The following example templates demonstrate various ways to customize the subject claim. To configure these settings on {% data variables.product.prodname_dotcom %}, admins use the REST API to specify a list of claims that must be included in the subject (`sub`) claim.
|
||||
|
||||
{% data reusables.actions.use-request-body-api %}
|
||||
|
||||
@@ -314,7 +321,7 @@ In your cloud provider's OIDC configuration, configure the `sub` condition to re
|
||||
|
||||
#### Example: Allowing access to all repositories with a specific owner
|
||||
|
||||
This example template enables the `sub` claim to have a new format with only the value of `repository_owner`.
|
||||
This example template enables the `sub` claim to have a new format with only the value of `repository_owner`.
|
||||
|
||||
{% data reusables.actions.use-request-body-api %}
|
||||
|
||||
@@ -365,12 +372,12 @@ This example also demonstrates how to use `"context"` to define your conditions.
|
||||
|
||||
In your cloud provider's OIDC configuration, configure the `sub` condition to require that claims must include specific values for `repo`, `context`, and `job_workflow_ref`.
|
||||
|
||||
This customization template requires that the `sub` uses the following format: `repo:<orgName/repoName>:environment:<environmentName>:job_workflow_ref:<reusableWorkflowPath>`.
|
||||
This customization template requires that the `sub` uses the following format: `repo:<orgName/repoName>:environment:<environmentName>:job_workflow_ref:<reusableWorkflowPath>`.
|
||||
For example: `"sub": "repo:octo-org/octo-repo:environment:prod:job_workflow_ref:octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main"`
|
||||
|
||||
#### Example: Granting access to a specific repository
|
||||
|
||||
This example template lets you grant cloud access to all the workflows in a specific repository, across all branches/tags and environments. To help improve security, combine this template with the custom issuer URL described in "[Customizing the token URL for an enterprise](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#customizing-the-token-url-for-an-enterprise)."
|
||||
This example template lets you grant cloud access to all the workflows in a specific repository, across all branches/tags and environments. To help improve security, combine this template with the custom issuer URL described in "[Customizing the token URL for an enterprise](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#customizing-the-token-url-for-an-enterprise)."
|
||||
|
||||
{% data reusables.actions.use-request-body-api %}
|
||||
|
||||
@@ -386,7 +393,7 @@ In your cloud provider's OIDC configuration, configure the `sub` condition to re
|
||||
|
||||
#### Example: Using system-generated GUIDs
|
||||
|
||||
This example template enables predictable OIDC claims with system-generated GUIDs that do not change between renames of entities (such as renaming a repository).
|
||||
This example template enables predictable OIDC claims with system-generated GUIDs that do not change between renames of entities (such as renaming a repository).
|
||||
|
||||
{% data reusables.actions.use-request-body-api %}
|
||||
|
||||
@@ -431,7 +438,7 @@ In your cloud provider's OIDC configuration, configure the `sub` condition to re
|
||||
|
||||
#### Using the default subject claims
|
||||
|
||||
For repositories that can receive a subject claim policy from their organization, the repository owner can later choose to opt-out and instead use the default `sub` claim format. This means that the repository will not use the organization's customized template.
|
||||
For repositories that can receive a subject claim policy from their organization, the repository owner can later choose to opt-out and instead use the default `sub` claim format. This means that the repository will not use the organization's customized template.
|
||||
|
||||
To configure the repository to use the default `sub` claim format, a repository admin must use the REST API endpoint at "[Set the customization template for an OIDC subject claim for a repository](/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-a-repository)" with the following request body:
|
||||
|
||||
|
||||
@@ -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 %}
|
||||
|
||||
@@ -9,22 +9,22 @@ featuredLinks:
|
||||
guides:
|
||||
- /actions/learn-github-actions
|
||||
- /actions/examples
|
||||
- /actions/guides/about-continuous-integration
|
||||
- /actions/deployment/deploying-with-github-actions
|
||||
- /actions/guides/about-packaging-with-github-actions
|
||||
- /actions/automating-builds-and-tests/about-continuous-integration
|
||||
- /actions/deployment/about-deployments/deploying-with-github-actions
|
||||
- /actions/publishing-packages/about-packaging-with-github-actions
|
||||
- /actions/monitoring-and-troubleshooting-workflows/about-monitoring-and-troubleshooting
|
||||
guideCards:
|
||||
- /actions/learn-github-actions/using-starter-workflows
|
||||
- /actions/guides/publishing-nodejs-packages
|
||||
- /actions/guides/building-and-testing-powershell
|
||||
- /actions/using-workflows/using-starter-workflows
|
||||
- /actions/publishing-packages/publishing-nodejs-packages
|
||||
- /actions/automating-builds-and-tests/building-and-testing-powershell
|
||||
popular:
|
||||
- /actions/learn-github-actions/workflow-syntax-for-github-actions
|
||||
- /actions/using-workflows/workflow-syntax-for-github-actions
|
||||
- /actions/learn-github-actions
|
||||
- /actions/examples
|
||||
- /actions/learn-github-actions/events-that-trigger-workflows
|
||||
- /actions/using-workflows/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
|
||||
@@ -63,4 +63,3 @@ children:
|
||||
- /creating-actions
|
||||
- /guides
|
||||
---
|
||||
|
||||
|
||||
@@ -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.<job_id>.concurrency</code> | <code>github, needs, strategy, matrix, inputs</code> | |
|
||||
| <code>jobs.<job_id>.container</code> | <code>github, needs, strategy, matrix, env, secrets, inputs</code> | |
|
||||
| <code>jobs.<job_id>.container.credentials</code> | <code>github, needs, strategy, matrix, env, secrets, inputs</code> | |
|
||||
| <code>jobs.<job_id>.container.env.<env_id></code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, inputs</code> | |
|
||||
| <code>jobs.<job_id>.continue-on-error</code> | <code>github, needs, strategy, matrix, inputs</code> | |
|
||||
| <code>jobs.<job_id>.defaults.run</code> | <code>github, needs, strategy, matrix, env, inputs</code> | |
|
||||
| <code>jobs.<job_id>.env</code> | <code>github, needs, strategy, matrix, secrets, inputs</code> | |
|
||||
| <code>jobs.<job_id>.environment</code> | <code>github, needs, strategy, matrix, inputs</code> | |
|
||||
| <code>jobs.<job_id>.environment.url</code> | <code>github, needs, strategy, matrix, job, runner, env, steps, inputs</code> | |
|
||||
| <code>jobs.<job_id>.if</code> | <code>github, needs, inputs</code> | <code>always, cancelled, success, failure</code> |
|
||||
| <code>jobs.<job_id>.name</code> | <code>github, needs, strategy, matrix, inputs</code> | |
|
||||
| <code>jobs.<job_id>.outputs.<output_id></code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps, inputs</code> | |
|
||||
| <code>jobs.<job_id>.runs-on</code> | <code>github, needs, strategy, matrix, inputs</code> | |
|
||||
| <code>jobs.<job_id>.secrets.<secrets_id></code> | <code>github, needs,{% ifversion actions-reusable-workflow-matrix %} strategy, matrix,{% endif %} secrets{% ifversion actions-unified-inputs %}, inputs{% endif %}</code> | |
|
||||
| <code>jobs.<job_id>.services</code> | <code>github, needs, strategy, matrix, inputs</code> | |
|
||||
| <code>jobs.<job_id>.services.<service_id>.credentials</code> | <code>github, needs, strategy, matrix, env, secrets, inputs</code> | |
|
||||
| <code>jobs.<job_id>.services.<service_id>.env.<env_id></code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, inputs</code> | |
|
||||
| <code>jobs.<job_id>.steps.continue-on-error</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps, inputs</code> | <code>hashFiles</code> |
|
||||
| <code>jobs.<job_id>.steps.env</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps, inputs</code> | <code>hashFiles</code> |
|
||||
| <code>jobs.<job_id>.steps.if</code> | <code>github, needs, strategy, matrix, job, runner, env, steps, inputs</code> | <code>always, cancelled, success, failure, hashFiles</code> |
|
||||
| <code>jobs.<job_id>.steps.name</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps, inputs</code> | <code>hashFiles</code> |
|
||||
| <code>jobs.<job_id>.steps.run</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps, inputs</code> | <code>hashFiles</code> |
|
||||
| <code>jobs.<job_id>.steps.timeout-minutes</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps, inputs</code> | <code>hashFiles</code> |
|
||||
| <code>jobs.<job_id>.steps.with</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps, inputs</code> | <code>hashFiles</code> |
|
||||
| <code>jobs.<job_id>.steps.working-directory</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps, inputs</code> | <code>hashFiles</code> |
|
||||
| <code>jobs.<job_id>.strategy</code> | <code>github, needs, inputs</code> | |
|
||||
| <code>jobs.<job_id>.timeout-minutes</code> | <code>github, needs, strategy, matrix, inputs</code> | |
|
||||
| <code>jobs.<job_id>.with.<with_id></code> | <code>github, needs{% ifversion actions-reusable-workflow-matrix %}, strategy, matrix{% endif %}{% ifversion actions-unified-inputs %}, inputs{% endif %}</code> | |
|
||||
| <code>on.workflow_call.inputs.<inputs_id>.default</code> | <code>github{% ifversion actions-unified-inputs %}, inputs{% endif %}</code> | |
|
||||
| <code>on.workflow_call.outputs.<output_id>.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.<job_id>.concurrency</code> | <code>github, needs, strategy, matrix, inputs{% ifversion actions-configuration-variables %}, vars{% endif %}</code> | |
|
||||
| <code>jobs.<job_id>.container</code> | <code>github, needs, strategy, matrix, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, inputs</code> | |
|
||||
| <code>jobs.<job_id>.container.credentials</code> | <code>github, needs, strategy, matrix, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, inputs</code> | |
|
||||
| <code>jobs.<job_id>.container.env.<env_id></code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, inputs</code> | |
|
||||
| <code>jobs.<job_id>.continue-on-error</code> | <code>github, needs, strategy, {% ifversion actions-configuration-variables %}vars, {% endif %}matrix, inputs</code> | |
|
||||
| <code>jobs.<job_id>.defaults.run</code> | <code>github, needs, strategy, matrix, env, {% ifversion actions-configuration-variables %}vars, {% endif %}inputs</code> | |
|
||||
| <code>jobs.<job_id>.env</code> | <code>github, needs, strategy, matrix, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, inputs</code> | |
|
||||
| <code>jobs.<job_id>.environment</code> | <code>github, needs, strategy, matrix, {% ifversion actions-configuration-variables %}vars, {% endif %}inputs</code> | |
|
||||
| <code>jobs.<job_id>.environment.url</code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}steps, inputs</code> | |
|
||||
| <code>jobs.<job_id>.if</code> | <code>github, needs, {% ifversion actions-configuration-variables %}vars, {% endif %}inputs</code> | <code>always, cancelled, success, failure</code> |
|
||||
| <code>jobs.<job_id>.name</code> | <code>github, needs, strategy, matrix, {% ifversion actions-configuration-variables %}vars, {% endif %}inputs</code> | |
|
||||
| <code>jobs.<job_id>.outputs.<output_id></code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, steps, inputs</code> | |
|
||||
| <code>jobs.<job_id>.runs-on</code> | <code>github, needs, strategy, matrix, {% ifversion actions-configuration-variables %}vars, {% endif %}inputs</code> | |
|
||||
| <code>jobs.<job_id>.secrets.<secrets_id></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.<job_id>.services</code> | <code>github, needs, strategy, matrix, {% ifversion actions-configuration-variables %}vars, {% endif %}inputs</code> | |
|
||||
| <code>jobs.<job_id>.services.<service_id>.credentials</code> | <code>github, needs, strategy, matrix, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, inputs</code> | |
|
||||
| <code>jobs.<job_id>.services.<service_id>.env.<env_id></code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, inputs</code> | |
|
||||
| <code>jobs.<job_id>.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.<job_id>.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.<job_id>.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.<job_id>.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.<job_id>.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.<job_id>.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.<job_id>.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.<job_id>.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.<job_id>.strategy</code> | <code>github, needs, {% ifversion actions-configuration-variables %}vars, {% endif %}inputs</code> | |
|
||||
| <code>jobs.<job_id>.timeout-minutes</code> | <code>github, needs, strategy, matrix, {% ifversion actions-configuration-variables %}vars, {% endif %}inputs</code> | |
|
||||
| <code>jobs.<job_id>.with.<with_id></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.<inputs_id>.default</code> | <code>github{% ifversion actions-unified-inputs %}, inputs{% endif %}{% ifversion actions-configuration-variables %}, vars{% endif %}</code> | |
|
||||
| <code>on.workflow_call.outputs.<output_id>.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.<job_id>.concurrency</code> | <code>github, needs, strategy, matrix</code> | |
|
||||
| <code>jobs.<job_id>.container</code> | <code>github, needs, strategy, matrix</code> | |
|
||||
| <code>jobs.<job_id>.container.credentials</code> | <code>github, needs, strategy, matrix, env, secrets</code> | |
|
||||
| <code>jobs.<job_id>.container.env.<env_id></code> | <code>github, needs, strategy, matrix, job, runner, env, secrets</code> | |
|
||||
| <code>jobs.<job_id>.container.credentials</code> | <code>github, needs, strategy, matrix, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets</code> | |
|
||||
| <code>jobs.<job_id>.container.env.<env_id></code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets</code> | |
|
||||
| <code>jobs.<job_id>.continue-on-error</code> | <code>github, needs, strategy, matrix</code> | |
|
||||
| <code>jobs.<job_id>.defaults.run</code> | <code>github, needs, strategy, matrix, env</code> | |
|
||||
| <code>jobs.<job_id>.defaults.run</code> | <code>github, needs, strategy, matrix, env, {% ifversion actions-configuration-variables %}vars, {% endif %}</code> | |
|
||||
| <code>jobs.<job_id>.env</code> | <code>github, needs, strategy, matrix, secrets</code> | |
|
||||
| <code>jobs.<job_id>.environment</code> | <code>github, needs, strategy, matrix</code> | |
|
||||
| <code>jobs.<job_id>.environment.url</code> | <code>github, needs, strategy, matrix, job, runner, env, steps</code> | |
|
||||
| <code>jobs.<job_id>.environment.url</code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}steps</code> | |
|
||||
| <code>jobs.<job_id>.if</code> | <code>github, needs</code> | <code>always, cancelled, success, failure</code> |
|
||||
| <code>jobs.<job_id>.name</code> | <code>github, needs, strategy, matrix</code> | |
|
||||
| <code>jobs.<job_id>.outputs.<output_id></code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps</code> | |
|
||||
| <code>jobs.<job_id>.outputs.<output_id></code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets, steps</code> | |
|
||||
| <code>jobs.<job_id>.runs-on</code> | <code>github, needs, strategy, matrix</code> | |
|
||||
| <code>jobs.<job_id>.services</code> | <code>github, needs, strategy, matrix</code> | |
|
||||
| <code>jobs.<job_id>.services.<service_id>.credentials</code> | <code>github, needs, strategy, matrix, env, secrets</code> | |
|
||||
| <code>jobs.<job_id>.services.<service_id>.env.<env_id></code> | <code>github, needs, strategy, matrix, job, runner, env, secrets</code> | |
|
||||
| <code>jobs.<job_id>.steps.continue-on-error</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps</code> | <code>hashFiles</code> |
|
||||
| <code>jobs.<job_id>.steps.env</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps</code> | <code>hashFiles</code> |
|
||||
| <code>jobs.<job_id>.steps.if</code> | <code>github, needs, strategy, matrix, job, runner, env, steps</code> | <code>always, cancelled, success, failure, hashFiles</code> |
|
||||
| <code>jobs.<job_id>.steps.name</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps</code> | <code>hashFiles</code> |
|
||||
| <code>jobs.<job_id>.steps.run</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps</code> | <code>hashFiles</code> |
|
||||
| <code>jobs.<job_id>.steps.timeout-minutes</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps</code> | <code>hashFiles</code> |
|
||||
| <code>jobs.<job_id>.steps.with</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps</code> | <code>hashFiles</code> |
|
||||
| <code>jobs.<job_id>.steps.working-directory</code> | <code>github, needs, strategy, matrix, job, runner, env, secrets, steps</code> | <code>hashFiles</code> |
|
||||
| <code>jobs.<job_id>.services.<service_id>.credentials</code> | <code>github, needs, strategy, matrix, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets</code> | |
|
||||
| <code>jobs.<job_id>.services.<service_id>.env.<env_id></code> | <code>github, needs, strategy, matrix, job, runner, env, {% ifversion actions-configuration-variables %}vars, {% endif %}secrets</code> | |
|
||||
| <code>jobs.<job_id>.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.<job_id>.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.<job_id>.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.<job_id>.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.<job_id>.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.<job_id>.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.<job_id>.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.<job_id>.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.<job_id>.strategy</code> | <code>github, needs</code> | |
|
||||
| <code>jobs.<job_id>.timeout-minutes</code> | <code>github, needs, strategy, matrix</code> | |
|
||||
{% endif %}
|
||||
@@ -189,6 +191,9 @@ The `github` context contains information about the workflow run and the event t
|
||||
| `github.action_repository` | `string` | For a step executing an action, this is the owner and repository name of the action. For example, `actions/checkout`. |
|
||||
| `github.action_status` | `string` | For a composite action, the current result of the composite action. |
|
||||
| `github.actor` | `string` | {% ifversion actions-stable-actor-ids %}The username of the user that triggered the initial workflow run. If the workflow run is a re-run, this value may differ from `github.triggering_actor`. Any workflow re-runs will use the privileges of `github.actor`, even if the actor initiating the re-run (`github.triggering_actor`) has different privileges.{% else %}The username of the user that initiated the workflow run.{% endif %} |
|
||||
{%- ifversion actions-oidc-custom-claims %}
|
||||
| `github.actor_id` | `string` | {% data reusables.actions.actor_id-description %} |
|
||||
{%- endif %}
|
||||
| `github.api_url` | `string` | The URL of the {% data variables.product.prodname_dotcom %} REST API. |
|
||||
| `github.base_ref` | `string` | The `base_ref` or target branch of the pull request in a workflow run. This property is only available when the event that triggers a workflow run is either `pull_request` or `pull_request_target`. |
|
||||
| `github.env` | `string` | Path on the runner to the file that sets environment variables from workflow commands. This file is unique to the current step and is a different file for each step in a job. For more information, see "[Workflow commands for {% data variables.product.prodname_actions %}](/actions/learn-github-actions/workflow-commands-for-github-actions#setting-an-environment-variable)." |
|
||||
@@ -198,6 +203,9 @@ The `github` context contains information about the workflow run and the event t
|
||||
| `github.graphql_url` | `string` | The URL of the {% data variables.product.prodname_dotcom %} GraphQL API. |
|
||||
| `github.head_ref` | `string` | The `head_ref` or source branch of the pull request in a workflow run. This property is only available when the event that triggers a workflow run is either `pull_request` or `pull_request_target`. |
|
||||
| `github.job` | `string` | The [`job_id`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_id) of the current job. <br /> Note: This context property is set by the Actions runner, and is only available within the execution `steps` of a job. Otherwise, the value of this property will be `null`. |
|
||||
{%- ifversion actions-oidc-custom-claims %}
|
||||
| `github.job_workflow_sha` | `string` | {% data reusables.actions.job-workflow-sha-description %} |
|
||||
{%- endif %}
|
||||
| `github.ref` | `string` | {% data reusables.actions.ref-description %} |
|
||||
{%- ifversion fpt or ghec or ghes > 3.3 or ghae > 3.3 %}
|
||||
| `github.ref_name` | `string` | {% data reusables.actions.ref_name-description %} |
|
||||
@@ -205,9 +213,15 @@ The `github` context contains information about the workflow run and the event t
|
||||
| `github.ref_type` | `string` | {% data reusables.actions.ref_type-description %} |
|
||||
{%- endif %}
|
||||
| `github.path` | `string` | Path on the runner to the file that sets system `PATH` variables from workflow commands. This file is unique to the current step and is a different file for each step in a job. For more information, see "[Workflow commands for {% data variables.product.prodname_actions %}](/actions/learn-github-actions/workflow-commands-for-github-actions#adding-a-system-path)." |
|
||||
| `github.repository` | `string` | The owner and repository name. For example, `Codertocat/Hello-World`. |
|
||||
| `github.repository_owner` | `string` | The repository owner's name. For example, `Codertocat`. |
|
||||
| `github.repositoryUrl` | `string` | The Git URL to the repository. For example, `git://github.com/codertocat/hello-world.git`. |
|
||||
| `github.repository` | `string` | The owner and repository name. For example, `octocat/Hello-World`. |
|
||||
{%- ifversion actions-oidc-custom-claims %}
|
||||
| `github.repository_id` | `string` | {% data reusables.actions.repository_id-description %} |
|
||||
{%- endif %}
|
||||
| `github.repository_owner` | `string` | The repository owner's username. For example, `octocat`. |
|
||||
{%- ifversion actions-oidc-custom-claims %}
|
||||
| `github.repository_owner_id` | `string` | {% data reusables.actions.repository_owner_id-description %} |
|
||||
{%- endif %}
|
||||
| `github.repositoryUrl` | `string` | The Git URL to the repository. For example, `git://github.com/octocat/hello-world.git`. |
|
||||
| `github.retention_days` | `string` | The number of days that workflow run logs and artifacts are kept. |
|
||||
| `github.run_id` | `string` | {% data reusables.actions.run_id_description %} |
|
||||
| `github.run_number` | `string` | {% data reusables.actions.run_number_description %} |
|
||||
@@ -222,6 +236,10 @@ The `github` context contains information about the workflow run and the event t
|
||||
| `github.token` | `string` | A token to authenticate on behalf of the GitHub App installed on your repository. This is functionally equivalent to the `GITHUB_TOKEN` secret. For more information, see "[Automatic token authentication](/actions/security-guides/automatic-token-authentication)." <br /> Note: This context property is set by the Actions runner, and is only available within the execution `steps` of a job. Otherwise, the value of this property will be `null`. |{% ifversion actions-stable-actor-ids %}
|
||||
| `github.triggering_actor` | `string` | The username of the user that initiated the workflow run. If the workflow run is a re-run, this value may differ from `github.actor`. Any workflow re-runs will use the privileges of `github.actor`, even if the actor initiating the re-run (`github.triggering_actor`) has different privileges. |{% endif %}
|
||||
| `github.workflow` | `string` | The name of the workflow. If the workflow file doesn't specify a `name`, the value of this property is the full path of the workflow file in the repository. |
|
||||
{%- ifversion actions-oidc-custom-claims %}
|
||||
| `github.workflow_ref` | `string` | {% data reusables.actions.workflow-ref-description %} |
|
||||
| `github.workflow_sha` | `string` | {% data reusables.actions.workflow-sha-description %} |
|
||||
{%- endif %}
|
||||
| `github.workspace` | `string` | 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. |
|
||||
|
||||
### Example contents of the `github` context
|
||||
@@ -295,11 +313,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 +326,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 +366,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.
|
||||
|
||||
@@ -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)."
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -24,7 +24,7 @@ children:
|
||||
- /essential-features-of-github-actions
|
||||
- /expressions
|
||||
- /contexts
|
||||
- /environment-variables
|
||||
- /variables
|
||||
- /usage-limits-billing-and-administration
|
||||
---
|
||||
|
||||
|
||||
330
content/actions/learn-github-actions/variables.md
Normal file
@@ -0,0 +1,330 @@
|
||||
---
|
||||
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 %}
|
||||

|
||||
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 %}
|
||||

|
||||
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`. |
|
||||
{%- ifversion actions-oidc-custom-claims %}
|
||||
| `GITHUB_ACTOR_ID` | {% data reusables.actions.actor_id-description %} |
|
||||
{%- endif %}
|
||||
| `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`. |
|
||||
{%- ifversion actions-oidc-custom-claims %}
|
||||
| `GITHUB_REPOSITORY_ID` | {% data reusables.actions.repository_id-description %} |
|
||||
{%- endif %}
|
||||
| `GITHUB_REPOSITORY_OWNER` | The repository owner's name. For example, `octocat`. |
|
||||
{%- ifversion actions-oidc-custom-claims %}
|
||||
| `GITHUB_REPOSITORY_OWNER_ID` | {% data reusables.actions.repository_owner_id-description %} |
|
||||
{%- endif %}
|
||||
| `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. |
|
||||
{%- ifversion actions-oidc-custom-claims %}
|
||||
| `GITHUB_WORKFLOW_REF` | {% data reusables.actions.workflow-ref-description %} |
|
||||
| `GITHUB_WORKFLOW_SHA` | {% data reusables.actions.workflow-sha-description %} |
|
||||
{%- endif %}
|
||||
| `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)."
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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 %}
|
||||
|
||||
|
||||
@@ -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)."
|
||||
|
||||
@@ -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 %}
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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 %}
|
||||
{% 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 %}
|
||||
{% 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:
|
||||

|
||||

|
||||
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
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -150,7 +150,7 @@ jobs:
|
||||
run: npm install
|
||||
|
||||
- name: Build
|
||||
run: npm build
|
||||
run: npm run build
|
||||
|
||||
- name: Test
|
||||
run: npm test
|
||||
|
||||
@@ -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
@@ -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.
|
||||
|
||||

|
||||
|
||||
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."
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
## 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)."
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -70,12 +70,12 @@ changelog:
|
||||
label: enterprise
|
||||
featuredLinks:
|
||||
guides:
|
||||
- '{% ifversion ghae %}/admin/user-management/auditing-users-across-your-enterprise{% endif %}'
|
||||
- '{% ifversion ghae %}/admin/user-management/managing-users-in-your-enterprise/auditing-users-across-your-enterprise{% endif %}'
|
||||
- /admin/identity-and-access-management/managing-iam-for-your-enterprise/about-authentication-for-your-enterprise
|
||||
- /admin/policies/enforcing-policies-for-your-enterprise/about-enterprise-policies
|
||||
- '{% ifversion ghae %}/admin/configuration/restricting-network-traffic-to-your-enterprise-with-an-ip-allow-list{% endif %}'
|
||||
- '{% ifversion ghes %}/admin/configuration/configuring-backups-on-your-appliance{% endif %}'
|
||||
- '{% ifversion ghes %}/admin/enterprise-management/creating-a-high-availability-replica{% endif %}'
|
||||
- '{% ifversion ghes %}/admin/configuration/configuring-your-enterprise/configuring-backups-on-your-appliance{% endif %}'
|
||||
- '{% ifversion ghes %}/admin/enterprise-management/configuring-high-availability/creating-a-high-availability-replica{% endif %}'
|
||||
- '{% ifversion ghes %}/admin/overview/about-upgrades-to-new-releases{% endif %}'
|
||||
- '{% ifversion ghec %}/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise{% endif %}'
|
||||
- '{% ifversion ghec %}/admin/user-management/managing-organizations-in-your-enterprise/adding-organizations-to-your-enterprise{% endif %}'
|
||||
@@ -83,16 +83,16 @@ featuredLinks:
|
||||
- '{% ifversion ghes %}/admin/github-actions/getting-started-with-github-actions-for-github-enterprise-server{% endif %}'
|
||||
- '{% ifversion ghes %}/admin/packages/getting-started-with-github-packages-for-your-enterprise{% endif %}'
|
||||
- '{% ifversion ghes %}/admin/configuration/configuring-advanced-security-features{% endif %}'
|
||||
- '{% ifversion ghae %}/admin/configuration/initializing-github-ae{% endif %}'
|
||||
- '{% ifversion ghae %}/admin/user-management/customizing-user-messages-for-your-enterprise{% endif %}'
|
||||
- '{% ifversion ghae %}/admin/github-actions/getting-started-with-github-actions-for-github-ae{% endif %}'
|
||||
- '{% ifversion ghec %}/admin/policies/enforcing-policies-for-your-enterprise/enforcing-github-actions-policies-for-your-enterprise{% endif %}'
|
||||
- '{% ifversion ghec %}/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-advanced-security-in-your-enterprise{% endif %}'
|
||||
- '{% ifversion ghae %}/admin/configuration/configuring-your-enterprise/initializing-github-ae{% endif %}'
|
||||
- '{% ifversion ghae %}/admin/user-management/managing-users-in-your-enterprise/customizing-user-messages-for-your-enterprise{% endif %}'
|
||||
- '{% ifversion ghae %}/admin/github-actions/getting-started-with-github-actions-for-your-enterprise/getting-started-with-github-actions-for-github-ae{% endif %}'
|
||||
- '{% ifversion ghec %}/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise{% endif %}'
|
||||
- '{% ifversion ghec %}/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-code-security-and-analysis-for-your-enterprise{% endif %}'
|
||||
- '{% ifversion ghec %}/admin/policies/enforcing-policies-for-your-enterprise/enforcing-repository-management-policies-in-your-enterprise{% endif %}'
|
||||
popular:
|
||||
- /admin/overview/about-github-enterprise-server
|
||||
- '{% ifversion ghae %}/admin/release-notes{% endif %}'
|
||||
- '{% ifversion ghes %}/github/getting-started-with-github/setting-up-a-trial-of-github-enterprise-server{% endif %}'
|
||||
- '{% ifversion ghes %}/get-started/signing-up-for-github/setting-up-a-trial-of-github-enterprise-server{% endif %}'
|
||||
- '{% ifversion ghes %}/admin/installation{% endif %}'
|
||||
- '{% ifversion ghae %}/admin/identity-and-access-management/configuring-authentication-and-provisioning-for-your-enterprise-using-azure-ad{% endif %}'
|
||||
- '{% ifversion ghae %}/billing/managing-billing-for-your-github-account/about-billing-for-your-enterprise{% endif %}'
|
||||
@@ -104,7 +104,7 @@ featuredLinks:
|
||||
- '{% ifversion ghec %}/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/about-the-audit-log-for-your-enterprise{% endif %}'
|
||||
- '{% ifversion ghec %}/admin/monitoring-activity-in-your-enterprise/exploring-user-activity/managing-global-webhooks{% endif %}'
|
||||
- /billing/managing-your-license-for-github-enterprise/using-visual-studio-subscription-with-github-enterprise/setting-up-visual-studio-subscription-with-github-enterprise
|
||||
- /admin/enterprise-support/about-github-enterprise-support
|
||||
- /support/learning-about-github-support/about-github-support
|
||||
layout: product-landing
|
||||
versions:
|
||||
ghec: '*'
|
||||
|
||||
@@ -33,6 +33,8 @@ Otherwise use of {% data variables.product.prodname_github_codespaces %} applies
|
||||
|
||||
For information about how to configure an organization to be billed for codespace usage, see "[Enabling {% data variables.product.prodname_github_codespaces %} for your organization](/codespaces/managing-codespaces-for-your-organization/enabling-github-codespaces-for-your-organization)." The Free, Team, and Enterprise plans for organization and enterprise accounts do not include any free use of {% data variables.product.prodname_github_codespaces %}.
|
||||
|
||||
{% ifversion fpt %}
|
||||
|
||||
### Monthly included storage and core hours for personal accounts
|
||||
|
||||
The following storage and core hours of usage are included, free of charge, for personal accounts:
|
||||
@@ -64,6 +66,8 @@ If you are blocked from resuming a codespace and you want to continue to work on
|
||||
|
||||
If you have used all of either your included storage usage or your included compute usage, and you have set up a payment method and a spending limit, any further use of codespaces owned by your personal account will incur charges for whichever type of usage has no remaining included quota. You will not be charged for the other type of usage until you have also used all of its included quota.
|
||||
|
||||
{% endif %}
|
||||
|
||||
### Pricing for paid usage
|
||||
|
||||
A {% data variables.product.prodname_github_codespaces %} instance (a "codespace") incurs charges for compute time, while it is active, and for the amount of disk space the codespace occupies, while it exists. The compute cost is proportional to the number of processor cores in the machine type you choose for your codespace, as shown in the table below. For example, the compute cost of using a codespace for an hour on a 16-core machine is eight times greater than a 2-core machine.
|
||||
|
||||
@@ -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:
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
---
|
||||
|
||||
|
||||
@@ -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**.
|
||||
|
||||

|
||||
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 %}**.
|
||||
|
||||

|
||||
|
||||
{% 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 %}
|
||||
|
||||

|
||||
|
||||
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.
|
||||

|
||||
1. Choose whether you'd like to commit directly to the default branch, or create a new branch and start a pull request.
|
||||

|
||||
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)."
|
||||

|
||||
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.
|
||||
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.
|
||||

|
||||
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.
|
||||

|
||||
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.
|
||||
|
||||

|
||||
|
||||
|
||||
@@ -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.
|
||||
```
|
||||
|
||||
|
||||
@@ -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)."
|
||||
@@ -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)**.
|
||||
|
||||

|
||||
|
||||
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.
|
||||
|
||||

|
||||

|
||||
|
||||
{% endnote %}
|
||||
|
||||
@@ -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.
|
||||

|
||||
* 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.
|
||||
|
||||

|
||||
|
||||
|
||||
## 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)."
|
||||
|
||||
@@ -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 %}
|
||||
|
||||
@@ -44,7 +44,7 @@ In the examples below, replace `:enabled` with `:not-enabled` to see repositorie
|
||||
|
||||
| Qualifier | Description |
|
||||
| -------- | -------- |
|
||||
| `code-scanning:enabled` | Display repositories that have set up {% data variables.product.prodname_code_scanning %}. |
|
||||
| `code-scanning:enabled` | Display repositories that have set up {% data variables.product.prodname_code_scanning %}. |
|
||||
| `dependabot:enabled` | Display repositories that have enabled {% data variables.product.prodname_dependabot_alerts %}. |
|
||||
| `secret-scanning:enabled` | Display repositories that have enabled {% data variables.secret-scanning.alerts %}. {% ifversion security-overview-org-risk-coverage %} |
|
||||
| `any-feature:enabled` | Display repositories where at least one security feature is enabled. |{% else %}
|
||||
@@ -79,7 +79,7 @@ These qualifiers are available in the main summary views.
|
||||
{% ifversion ghec or ghes > 3.4 or ghae > 3.4 %}
|
||||
## Filter by level of risk for repositories
|
||||
|
||||
The level of risk for a repository is determined by the number and severity of alerts from security features. If one or more security features are not enabled for a repository, the repository will have an unknown level of risk. If a repository has no risks that are detected by security features, the repository will have a clear level of risk.
|
||||
The level of risk for a repository is determined by the number and severity of alerts from security features. If one or more security features are not enabled for a repository, the repository will have an unknown level of risk. If a repository has no risks that are detected by security features, the repository will have a clear level of risk.
|
||||
|
||||
{% ifversion security-overview-org-risk-coverage %}
|
||||
These qualifiers are available in the enterprise-level view.
|
||||
@@ -100,9 +100,9 @@ These qualifiers are available in the enterprise-level view.
|
||||
|
||||
| Qualifier | Description |
|
||||
| -------- | -------- |
|
||||
| <code>code-scanning:<em>n</em></code> | Display repositories that have *n* {% data variables.product.prodname_code_scanning %} alerts. This qualifier can use `=`, `>` and `<` comparison operators. |
|
||||
| <code>secret-scanning:<em>n</em></code> | Display repositories that have *n* {% data variables.secret-scanning.alerts %}. This qualifier can use `=`, `>` and `<` comparison operators. |
|
||||
| <code>dependabot:<em>n</em></code> | Display repositories that have *n* {% data variables.product.prodname_dependabot_alerts %}. This qualifier can use `=`, `>` and `<` comparison operators. |
|
||||
| `code-scanning:NUMBER` | Display repositories that have NUMBER {% data variables.product.prodname_code_scanning %} alerts. This qualifier can use `=`, `>` and `<` comparison operators. |
|
||||
| `secret-scanning:NUMBER` | Display repositories that have NUMBER {% data variables.secret-scanning.alerts %}. This qualifier can use `=`, `>` and `<` comparison operators. |
|
||||
| `dependabot:NUMBER` | Display repositories that have NUMBER {% data variables.product.prodname_dependabot_alerts %}. This qualifier can use `=`, `>` and `<` comparison operators. |
|
||||
|
||||
|
||||
## Filter by team
|
||||
@@ -111,7 +111,7 @@ These qualifiers are available in the main summary views.
|
||||
|
||||
| Qualifier | Description |
|
||||
| -------- | -------- |
|
||||
| <code>team:<em>TEAM-NAME</em></code> | Displays repositories that *TEAM-NAME* has admin privileges for. |
|
||||
| `team:TEAM-NAME` | Displays repositories that TEAM-NAME has {% ifversion security-overview-team-write-access -%} write access or {% endif -%} admin access to. |
|
||||
|
||||
## Filter by topic
|
||||
|
||||
@@ -119,7 +119,7 @@ These qualifiers are available in the main summary views.
|
||||
|
||||
| Qualifier | Description |
|
||||
| -------- | -------- |
|
||||
| <code>topic:<em>TOPIC-NAME</em></code> | Displays repositories that are classified with *TOPIC-NAME*. |
|
||||
| `topic:TOPIC-NAME` | Displays repositories that are classified with TOPIC-NAME. |
|
||||
|
||||
{% ifversion security-overview-alert-views %}
|
||||
|
||||
@@ -159,4 +159,3 @@ You can filter the view to show {% data variables.product.prodname_dependabot_al
|
||||
| `secret-type:CUSTOM-PATTERN` | Displays alerts for secrets matching the specified custom pattern. |
|
||||
|
||||
For more information, see "[{% data variables.product.prodname_secret_scanning_caps %} patterns](/code-security/secret-scanning/secret-scanning-patterns)."
|
||||
|
||||
|
||||
@@ -114,3 +114,7 @@ Certain development features can potentially add risk to your environment. For e
|
||||
#### Using extensions
|
||||
|
||||
Any additional {% data variables.product.prodname_vscode_shortname %} extensions that you've installed can potentially introduce more risk. To help mitigate this risk, ensure that the you only install trusted extensions, and that they are always kept up to date.
|
||||
|
||||
#### Using Settings Sync
|
||||
|
||||
{% data variables.product.prodname_vscode_shortname %}'s Settings Sync can allow potentially malicious content to transfer across devices. If you're creating a codespace for a repository whose contents you do not trust, you should open the codespace in the browser and leave Settings Sync disabled.
|
||||
@@ -31,13 +31,35 @@ Project maintainers can also define a default configuration that applies to ever
|
||||
|
||||
## Settings Sync
|
||||
|
||||
Settings Sync allows you to synchronize configurations such as settings, keyboard shortcuts, snippets, extensions, and UI state across machines and instances of {% data variables.product.prodname_vscode_shortname %}.
|
||||
Settings Sync allows you to synchronize configurations such as settings, keyboard shortcuts, snippets, extensions, and UI state across machines and instances of {% data variables.product.prodname_vscode_shortname %}. For more information, see [Settings Sync](https://code.visualstudio.com/docs/editor/settings-sync) in the {% data variables.product.prodname_vscode_shortname %} documentation.
|
||||
|
||||
To enable Settings Sync, in the bottom-left corner of {% data variables.product.prodname_vscode %}'s Activity Bar, select {% octicon "gear" aria-label="The gear icon" %} and click **Turn on Settings Sync…**. In the dialog box, select the settings you'd like to sync.
|
||||
{% data reusables.codespaces.about-settings-sync %}
|
||||
|
||||

|
||||
- If you open a codespace in the browser, Settings Sync is always disabled at first. This means the transfer of settings takes place in one direction and at one time only: {% data variables.product.prodname_github_codespaces %} pulls the settings stored in the cloud into the codespace at the point of creation, but any updates you make to the settings in the codespace are not propagated to the cloud, so are not reflected in any other codespaces. Equally, any updates you make to your settings elsewhere are not reflected in your codespace.
|
||||
- If you open a codespace in the {% data variables.product.prodname_vscode_shortname %} desktop application, Settings Sync remains enabled in the codespace if you have previously enabled it for the application. Any updates you make to your settings are pushed to cloud, so are reflected in new codespaces and any existing codespaces in which Settings Sync is enabled. If you make updates to your settings in other {% data variables.product.prodname_vscode_shortname %} instances where Settings Sync is enabled, these updates are reflected in your codespace.
|
||||
|
||||
For more information, see the [Settings Sync guide](https://code.visualstudio.com/docs/editor/settings-sync) in the {% data variables.product.prodname_vscode_shortname %} documentation.
|
||||
If you're working in a codespace where Settings Sync is disabled, you can enable Settings Sync to push changes you have made to your settings to the cloud, or pull in the latest changes to your settings you have made elsewhere.
|
||||
|
||||
### Enabling Settings Sync
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** You should only enable Settings Sync in codespaces created from repositories you trust. For more information, see "[Security in {% data variables.product.prodname_github_codespaces %}](/codespaces/codespaces-reference/security-in-github-codespaces#using-settings-sync)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
1. In {% data variables.product.prodname_vscode_shortname %}, at the bottom of the Activity Bar, select {% octicon "gear" aria-label="The gear icon" %} and click **Turn on Settings Sync…**
|
||||
1. In the dropdown, select which settings you want to sync.
|
||||
|
||||

|
||||
|
||||
1. Click **Sign in & Turn on**, then select the account to which you want your settings to be synced.
|
||||
|
||||
When you have signed in, the {% data variables.product.prodname_vscode_shortname %} instance you're working in will immediately be updated to display the latest synced settings.
|
||||
|
||||
### Disabling Settings Sync
|
||||
|
||||
{% data reusables.codespaces.disabling-settings-sync %}
|
||||
|
||||
## Dotfiles
|
||||
|
||||
@@ -87,7 +109,7 @@ You can use your selected dotfiles repository to personalize your {% data variab
|
||||
|
||||
You can add further script, preferences, configuration files to your dotfiles repository or edit existing files whenever you want. Changes to settings will only be picked up by new codespaces.
|
||||
|
||||
If your codespace fails to pick up configuration settings from dotfiles, see "[Troubleshooting dotfiles for {% data variables.product.prodname_github_codespaces %}](/codespaces/troubleshooting/troubleshooting-dotfiles-for-codespaces)."
|
||||
If your codespace fails to pick up configuration settings from dotfiles, see "[Troubleshooting personalization options for {% data variables.product.prodname_github_codespaces %}](/codespaces/troubleshooting/troubleshooting-personalization-for-codespaces#troubleshooting-dotfiles)."
|
||||
|
||||
## Other available settings
|
||||
|
||||
|
||||
@@ -93,7 +93,9 @@ When you connect to a codespace using the browser, or the {% data variables.prod
|
||||
|
||||

|
||||
|
||||
If you are using a codespace in the browser, or in the {% data variables.product.prodname_vscode %} desktop application, and you have [Settings Sync](https://code.visualstudio.com/docs/editor/settings-sync) turned on, any changes you make to your editor setup in the current codespace, such as changing your theme or keyboard bindings, are automatically synced to any instances of {% data variables.product.prodname_vscode %} that are signed into your {% data variables.product.prodname_dotcom %} account and to any other codespaces you create.
|
||||
### About Settings Sync
|
||||
|
||||
You can enable Settings Sync to sync extensions and other settings across devices and instances of {% data variables.product.prodname_vscode_shortname %}. {% data reusables.codespaces.about-settings-sync %} For more information, see "[Personalizing {% data variables.product.prodname_github_codespaces %} for your account](/codespaces/customizing-your-codespace/personalizing-github-codespaces-for-your-account#settings-sync)."
|
||||
|
||||
## Next steps
|
||||
|
||||
|
||||
@@ -54,4 +54,3 @@ children:
|
||||
- /the-githubdev-web-based-editor
|
||||
- /guides
|
||||
---
|
||||
|
||||
|
||||
@@ -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 %}
|
||||
|
||||
@@ -16,7 +16,7 @@ topics:
|
||||
shortTitle: Encrypted secrets
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## About encrypted secrets for {% data variables.product.prodname_github_codespaces %}
|
||||
|
||||
@@ -16,7 +16,7 @@ children:
|
||||
- /troubleshooting-creation-and-deletion-of-codespaces
|
||||
- /troubleshooting-your-connection-to-github-codespaces
|
||||
- /troubleshooting-prebuilds
|
||||
- /troubleshooting-dotfiles-for-codespaces
|
||||
- /troubleshooting-personalization-for-codespaces
|
||||
- /troubleshooting-port-forwarding-for-github-codespaces
|
||||
- /troubleshooting-github-codespaces-clients
|
||||
- /troubleshooting-gpg-verification-for-github-codespaces
|
||||
|
||||
@@ -1,16 +1,22 @@
|
||||
---
|
||||
title: Troubleshooting dotfiles for GitHub Codespaces
|
||||
title: Troubleshooting personalization options for GitHub Codespaces
|
||||
allowTitleToDifferFromFilename: true
|
||||
intro: Troubleshooting steps for common dotfiles issues.
|
||||
intro: Troubleshooting steps for common issues with dotfiles and Settings Sync.
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
type: reference
|
||||
topics:
|
||||
- Codespaces
|
||||
shortTitle: Dotfiles
|
||||
shortTitle: Personalization
|
||||
redirect_from:
|
||||
- /codespaces/troubleshooting/troubleshooting-dotfiles-for-codespaces
|
||||
---
|
||||
|
||||
You can personalize {% data variables.product.prodname_github_codespaces %} by using a `dotfiles` repository on {% data variables.product.product_name %} or by using Settings Sync. For more information, see "[Personalizing {% data variables.product.prodname_github_codespaces %} for your account](/codespaces/customizing-your-codespace/personalizing-github-codespaces-for-your-account)."
|
||||
|
||||
## Troubleshooting dotfiles
|
||||
|
||||
If your codespace fails to pick up configuration settings from dotfiles, you should work through the following debugging steps.
|
||||
|
||||
1. Enable dotfiles by selecting **Automatically install dotfiles** in [your personal {% data variables.product.prodname_github_codespaces %} settings](https://github.com/settings/codespaces).
|
||||
@@ -23,3 +29,7 @@ If your codespace fails to pick up configuration settings from dotfiles, you sho
|
||||
1. Check `/workspaces/.codespaces/.persistedshare/creation.log` for possible issues. For more information, see [Creation logs](/codespaces/troubleshooting/codespaces-logs#creation-logs).
|
||||
|
||||
If the configuration from your dotfiles is correctly picked up, but part of the configuration is incompatible with codespaces, use the `$CODESPACES` environment variable to add conditional logic for codespace-specific configuration settings.
|
||||
|
||||
## Troubleshooting Settings Sync
|
||||
|
||||
{% data reusables.codespaces.disabling-settings-sync %}
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
title: Reporting abuse or spam
|
||||
intro: You can report behavior and content that violates community guidelines and terms.
|
||||
permissions: Owners, collaborators, prior contributors, and people with write access can report issues, pull requests, and comments on issues, pull requests, and commits. Anyone can report apps in {% data variables.product.prodname_marketplace %}.
|
||||
redirect_from:
|
||||
- /articles/reporting-abuse-or-spam
|
||||
- /github/building-a-strong-community/reporting-abuse-or-spam
|
||||
@@ -11,8 +12,6 @@ topics:
|
||||
- Community
|
||||
---
|
||||
|
||||
Owners, collaborators, prior contributors, and people with write access can report issues, pull requests, and comments on issues, pull requests, and commits. Anyone can report apps in {% data variables.product.prodname_marketplace %}.
|
||||
|
||||
## About reporting abuse or spam
|
||||
|
||||
{% data reusables.policies.github-community-guidelines-and-terms %}
|
||||
|
||||
@@ -10,9 +10,9 @@ featuredLinks:
|
||||
- /education/explore-the-benefits-of-teaching-and-learning-with-github-education/github-global-campus-for-teachers/apply-to-github-global-campus-as-a-teacher
|
||||
- /education/explore-the-benefits-of-teaching-and-learning-with-github-education/use-github-at-your-educational-institution
|
||||
guideCards:
|
||||
- /github/getting-started-with-github/signing-up-for-a-new-github-account
|
||||
- /github/getting-started-with-github/git-and-github-learning-resources
|
||||
- /education/manage-coursework-with-github-classroom/basics-of-setting-up-github-classroom
|
||||
- /get-started/signing-up-for-github/signing-up-for-a-new-github-account
|
||||
- /get-started/quickstart/git-and-github-learning-resources
|
||||
- /education/manage-coursework-with-github-classroom/get-started-with-github-classroom/basics-of-setting-up-github-classroom
|
||||
popular:
|
||||
- /education/explore-the-benefits-of-teaching-and-learning-with-github-education/github-global-campus-for-students
|
||||
- /education/explore-the-benefits-of-teaching-and-learning-with-github-education/github-global-campus-for-teachers
|
||||
@@ -31,4 +31,3 @@ children:
|
||||
- /manage-coursework-with-github-classroom
|
||||
- /guides
|
||||
---
|
||||
|
||||
|
||||
@@ -26,7 +26,7 @@ introLinks:
|
||||
quickstart: /get-started/quickstart
|
||||
featuredLinks:
|
||||
guides:
|
||||
- /github/getting-started-with-github/githubs-products
|
||||
- /get-started/learning-about-github/githubs-products
|
||||
- /get-started/onboarding/getting-started-with-your-github-account
|
||||
- /get-started/onboarding/getting-started-with-github-team
|
||||
- /get-started/onboarding/getting-started-with-github-enterprise-cloud
|
||||
@@ -34,16 +34,16 @@ featuredLinks:
|
||||
- /get-started/onboarding/getting-started-with-github-ae
|
||||
- /get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/quickstart-for-writing-on-github
|
||||
popular:
|
||||
- /github/getting-started-with-github/signing-up-for-a-new-github-account
|
||||
- /get-started/signing-up-for-github/signing-up-for-a-new-github-account
|
||||
- /get-started/quickstart/hello-world
|
||||
- /github/getting-started-with-github/set-up-git
|
||||
- /get-started/quickstart/set-up-git
|
||||
- /get-started/learning-about-github/about-versions-of-github-docs
|
||||
- /github/getting-started-with-github/github-glossary
|
||||
- /github/getting-started-with-github/keyboard-shortcuts
|
||||
- /get-started/quickstart/github-glossary
|
||||
- /get-started/using-github/keyboard-shortcuts
|
||||
guideCards:
|
||||
- /github/getting-started-with-github/types-of-github-accounts
|
||||
- /github/getting-started-with-github/finding-ways-to-contribute-to-open-source-on-github
|
||||
- /github/getting-started-with-github/troubleshooting-connectivity-problems
|
||||
- /get-started/learning-about-github/types-of-github-accounts
|
||||
- /get-started/exploring-projects-on-github/finding-ways-to-contribute-to-open-source-on-github
|
||||
- /get-started/using-github/troubleshooting-connectivity-problems
|
||||
topics:
|
||||
- Pull requests
|
||||
- Issues
|
||||
|
||||
@@ -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 %}
|
||||
|
||||
|
||||
@@ -3,9 +3,9 @@ title: '{% data variables.product.product_name %}{% ifversion fpt or ghec%}.com{
|
||||
featuredLinks:
|
||||
gettingStarted:
|
||||
- /get-started/quickstart/set-up-git
|
||||
- /github/authenticating-to-github/connecting-to-github-with-ssh
|
||||
- /authentication/connecting-to-github-with-ssh
|
||||
- /repositories/creating-and-managing-repositories
|
||||
- /github/writing-on-github/basic-writing-and-formatting-syntax
|
||||
- /get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax
|
||||
popular:
|
||||
- /pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests
|
||||
- /authentication
|
||||
@@ -150,4 +150,3 @@ externalProducts:
|
||||
href: 'https://docs.npmjs.com/'
|
||||
external: true
|
||||
---
|
||||
|
||||
|
||||
@@ -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)."
|
||||
|
||||
@@ -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**.
|
||||
|
||||

|
||||
|
||||
1. Select the repository that contains the workflow and enter the path to the workflow.
|
||||
|
||||

|
||||
|
||||
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.
|
||||
|
||||

|
||||
|
||||
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.
|
||||
|
||||

|
||||
|
||||
1. To add the required workflow, click **Add workflow**.
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% ifversion fpt or ghes or ghec %}
|
||||
## Enabling workflows for private repository forks
|
||||
|
||||
|
||||
@@ -22,6 +22,7 @@ The following {% data variables.product.prodname_registry %} registries support
|
||||
- {% data variables.product.prodname_container_registry %}
|
||||
{% ifversion packages-npm-v2 %}- npm registry{% endif %}
|
||||
{% ifversion packages-nuget-v2 %}- NuGet registry{% endif %}
|
||||
{% ifversion packages-rubygems-v2 %}- RubyGems registry{% endif %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
@@ -34,10 +35,10 @@ The following {% data variables.product.prodname_registry %} registries **only**
|
||||
|
||||
{% ifversion not fpt or ghec %}- Docker registry (`docker.pkg.github.com`){% endif %}
|
||||
{% ifversion packages-npm-v2 %}{% else %}- npm registry{% endif %}
|
||||
- RubyGems registry
|
||||
- Apache Maven registry
|
||||
- Gradle registry
|
||||
{% ifversion packages-nuget-v2 %}{% else %}- NuGet registry{% endif %}
|
||||
{% ifversion packages-rubygems-v2 %}{% else %}- RubyGems registry{% endif %}
|
||||
|
||||
For {% ifversion ghes %}the {% data variables.product.prodname_container_registry %}{% else %}other registries{% endif %}, you can choose to allow packages to be scoped to a user or an organization, or linked to a repository. {% ifversion docker-ghcr-enterprise-migration %}For information about migration to the {% data variables.product.prodname_container_registry %}, see "[Migrating to the {% data variables.product.prodname_container_registry %} from the Docker registry](/packages/working-with-a-github-packages-registry/migrating-to-the-container-registry-from-the-docker-registry)."{% endif %}
|
||||
|
||||
@@ -77,6 +78,15 @@ For more information, see:{% ifversion fpt or ghec %}
|
||||
- "[Creating a {% data variables.product.pat_generic %}](/github/authenticating-to-github/creating-a-personal-access-token/)"
|
||||
- "[Available scopes](/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)"
|
||||
|
||||
## About repository transfers
|
||||
|
||||
You can transfer a repository to another user or organization account. For more information, see "[Transferring a repository](/repositories/creating-and-managing-repositories/transferring-a-repository)."
|
||||
|
||||
When you transfer a repository, {% ifversion packages-registries-v2 %}{% data variables.product.prodname_dotcom %} may transfer the packages associated with the repository, depending on the registry the packages belong to.
|
||||
|
||||
- For registries that support granular permissions, packages are scoped to a user or organization account, and the account associated with the package does not change when you transfer a repository. If you have linked a package to a repository, the link is removed when you transfer the repository to another user, and any codespaces or {% data variables.product.prodname_actions %} workflows associated with the repository will lose access to the package. For the list of these registries, see "[Granular permissions for user/organization-scoped packages](/packages/learn-github-packages/about-permissions-for-github-packages#granular-permissions-for-userorganization-scoped-packages)."
|
||||
- For registries that only support repository-scoped permissions, packages are published directly to repositories, and {% endif %}{% data variables.product.prodname_dotcom %} transfers the packages associated with a repository as part of the repository transfer. All billable usage associated with the packages will subsequently be billed to the new owner. If the previous repository owner is removed as a collaborator on the repository, they may no longer be able to access the packages associated with the repository.{% ifversion packages-registries-v2 %} For the list of these registries, see "[Permissions for repository-scoped packages](/packages/learn-github-packages/about-permissions-for-github-packages#permissions-for-repository-scoped-packages)."{% endif %}
|
||||
|
||||
## Maintaining access to packages in {% data variables.product.prodname_actions %} workflows
|
||||
|
||||
To ensure your workflows will maintain access to your packages, ensure that you're using the right access token in your workflow and that you've enabled {% data variables.product.prodname_actions %} access to your package.
|
||||
|
||||
@@ -26,6 +26,8 @@ You can extend the CI and CD capabilities of your repository by publishing or in
|
||||
{% ifversion packages-registries-v2 %}
|
||||
### Authenticating to package registries with granular permissions
|
||||
|
||||
Some {% data variables.product.prodname_registry %} registries support granular permissions. This means you can choose to allow packages to be owned by a user or an organization, or linked to a repository. For the list of registries that support granular permissions, see "[About permissions for {% data variables.product.prodname_registry %}](/packages/learn-github-packages/about-permissions-for-github-packages#granular-permissions-for-userorganization-scoped-packages)."
|
||||
|
||||
{% data reusables.package_registry.authenticate_with_pat_for_v2_registry %}
|
||||
|
||||
### Authenticating to package registries with repository-scoped permissions
|
||||
|
||||
@@ -42,10 +42,19 @@ When installing or publishing a Docker image, the {% data variables.product.prod
|
||||
|
||||
## Authenticating to the {% data variables.product.prodname_container_registry %}
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.4 %}
|
||||
To authenticate to the {% data variables.product.prodname_container_registry %} (`ghcr.io`) within a {% data variables.product.prodname_actions %} workflow, use the `GITHUB_TOKEN` for the best security and experience. {% data reusables.package_registry.authenticate_with_pat_for_v2_registry %}
|
||||
{% data reusables.package_registry.authenticate-packages %}
|
||||
|
||||
{% ifversion packages-registries-v2 %}
|
||||
|
||||
### Authenticating in a {% data variables.product.prodname_actions %} workflow
|
||||
|
||||
This registry supports granular permissions. {% data reusables.package_registry.authenticate_with_pat_for_v2_registry %}
|
||||
|
||||
{% data reusables.package_registry.v2-actions-codespaces %}
|
||||
{% endif %}
|
||||
|
||||
### Authenticating with a {% data variables.product.pat_v1 %}
|
||||
|
||||
{% ifversion ghes %}Ensure that you replace `HOSTNAME` with {% data variables.location.product_location_enterprise %} hostname or IP address in the examples below.{% endif %}
|
||||
|
||||
{% data reusables.package_registry.authenticate-to-container-registry-steps %}
|
||||
@@ -62,7 +71,7 @@ This example pushes the `2.5` version of the image.
|
||||
$ docker push {% data reusables.package_registry.container-registry-hostname %}/OWNER/IMAGE_NAME:2.5
|
||||
```
|
||||
|
||||
When you first publish a package, the default visibility is private. To change the visibility or set access permissions, see "[Configuring a package's access control and visibility](/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility)."
|
||||
{% data reusables.package_registry.publishing-user-scoped-packages %} You can link a published package to a repository using the user interface or command line. For more information, see "[Connecting a repository to a package](/packages/learn-github-packages/connecting-a-repository-to-a-package)."
|
||||
|
||||
## Pulling container images
|
||||
|
||||
@@ -139,17 +148,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 +177,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
|
||||
```
|
||||
@@ -37,9 +37,11 @@ If you reach this limit, consider deleting package versions or contact Support f
|
||||
{% data reusables.package_registry.authenticate-packages %}
|
||||
|
||||
{% ifversion packages-npm-v2 %}
|
||||
{% data reusables.package_registry.authenticate_with_pat_for_v2_registry %}
|
||||
### Authenticating in a {% data variables.product.prodname_actions %} workflow
|
||||
|
||||
You can also choose to give access permissions to packages independently for {% data variables.product.prodname_codespaces %} and {% data variables.product.prodname_actions %}. For more information, see "[Ensuring Codespaces access to your package](/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-codespaces-access-to-your-package) and [Ensuring workflow access to your package](/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-workflow-access-to-your-package)."
|
||||
This registry supports granular permissions. {% data reusables.package_registry.authenticate_with_pat_for_v2_registry %}
|
||||
|
||||
{% data reusables.package_registry.v2-actions-codespaces %}
|
||||
{% endif %}
|
||||
|
||||
### Authenticating with a {% data variables.product.pat_generic %}
|
||||
@@ -104,7 +106,7 @@ $ npm login --scope=@OWNER --registry=https://HOSTNAME/_registry/npm/
|
||||
{% ifversion packages-npm-v2 %}
|
||||
The {% data variables.product.prodname_registry %} registry stores npm packages within your organization or personal account, and allows you to associate a package with a repository. You can choose whether to inherit permissions from a repository, or set granular permissions independently of a repository.
|
||||
|
||||
{% data reusables.package_registry.publishing-user-scoped-packages %}
|
||||
{% data reusables.package_registry.publishing-user-scoped-packages %} For more information on linking a published package with a repository, see "[Connecting a repository to a package](/packages/learn-github-packages/connecting-a-repository-to-a-package)."
|
||||
{% endif %}
|
||||
|
||||
By default, {% data variables.product.prodname_registry %} publishes a package in the {% data variables.product.prodname_dotcom %} repository you specify in the name field of the *package.json* file. For example, you would publish a package named `@my-org/test` to the `my-org/test` {% data variables.product.prodname_dotcom %} repository. If you're running [npm v8.5.3](https://github.com/npm/cli/releases/tag/v8.5.3) or later, you can add a summary for the package listing page by including a *README.md* file in your package directory. For more information, see "[Working with package.json](https://docs.npmjs.com/getting-started/using-a-package.json)" and "[How to create Node.js Modules](https://docs.npmjs.com/getting-started/creating-node-modules)" in the npm documentation.
|
||||
|
||||
@@ -26,22 +26,28 @@ shortTitle: NuGet registry
|
||||
|
||||
{% data reusables.package_registry.authenticate-packages %}
|
||||
|
||||
{% ifversion packages-nuget-v2 %}
|
||||
You can choose to give access permissions to packages independently for {% data variables.product.prodname_github_codespaces %} and {% data variables.product.prodname_actions %}. For more information, see "[Ensuring Codespaces access to your package](/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-codespaces-access-to-your-package)" and "[Ensuring workflow access to your package](/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-workflow-access-to-your-package)."
|
||||
{% endif %}
|
||||
### Authenticating in a {% data variables.product.prodname_actions %} workflow
|
||||
|
||||
### Authenticating with `GITHUB_TOKEN` in {% data variables.product.prodname_actions %}
|
||||
{% ifversion packages-nuget-v2 %}
|
||||
This registry supports granular permissions. {% data reusables.package_registry.authenticate_with_pat_for_v2_registry %} {% endif %}
|
||||
|
||||
Use the following command to authenticate to {% data variables.product.prodname_registry %} in a {% data variables.product.prodname_actions %} workflow using the `GITHUB_TOKEN` instead of hardcoding a {% data variables.product.pat_generic %} in a nuget.config file in the repository:
|
||||
|
||||
```shell
|
||||
dotnet nuget add source --username USERNAME --password {%raw%}${{ secrets.GITHUB_TOKEN }}{% endraw %} --store-password-in-clear-text --name github "https://{% ifversion fpt or ghec %}nuget.pkg.github.com{% else %}nuget.HOSTNAME{% endif %}/OWNER/index.json"
|
||||
```
|
||||
{% ifversion packages-nuget-v2 %}{% else %}{% data reusables.package_registry.authenticate-packages-github-token %}{% endif %}
|
||||
|
||||
{% data reusables.package_registry.authenticate-packages-github-token %}
|
||||
{% ifversion packages-nuget-v2 %}
|
||||
|
||||
{% data reusables.package_registry.v2-actions-codespaces %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
### Authenticating with a {% data variables.product.pat_generic %}
|
||||
|
||||
{% data reusables.package_registry.authenticate-packages %}
|
||||
|
||||
{% data reusables.package_registry.required-scopes %}
|
||||
|
||||
To authenticate to {% data variables.product.prodname_registry %} with the `dotnet` command-line interface (CLI), create a *nuget.config* file in your project directory specifying {% data variables.product.prodname_registry %} as a source under `packageSources` for the `dotnet` CLI client.
|
||||
@@ -99,7 +105,7 @@ You can publish a package to {% data variables.product.prodname_registry %} by a
|
||||
|
||||
The NuGet registry stores packages within your organization or personal account, and allows you to associate packages with a repository. You can choose whether to inherit permissions from a repository, or set granular permissions independently of a repository.
|
||||
|
||||
{% data reusables.package_registry.publishing-user-scoped-packages %}
|
||||
{% data reusables.package_registry.publishing-user-scoped-packages %} For more information on linking a published package with a repository, see "[Connecting a repository to a package](/packages/learn-github-packages/connecting-a-repository-to-a-package)."
|
||||
|
||||
If you specify a `RepositoryURL` in your `nuget.config` file, the published package will automatically be connected to the specified repository. For more information, see "[Publishing a package using a `nuget.config` file](/packages/working-with-a-github-packages-registry/working-with-the-nuget-registry#publishing-a-package-using-a-nugetconfig-file)." For information on linking an already-published package to a repository, see "[Connecting a repository to a package](/packages/learn-github-packages/connecting-a-repository-to-a-package)."
|
||||
|
||||
|
||||
@@ -40,7 +40,15 @@ shortTitle: RubyGems registry
|
||||
|
||||
{% data reusables.package_registry.authenticate-packages %}
|
||||
|
||||
{% data reusables.package_registry.authenticate-packages-github-token %}
|
||||
{% ifversion packages-rubygems-v2 %}
|
||||
|
||||
### Authenticating in a {% data variables.product.prodname_actions %} workflow
|
||||
|
||||
This registry supports granular permissions. {% data reusables.package_registry.authenticate_with_pat_for_v2_registry %}
|
||||
|
||||
{% data reusables.package_registry.v2-actions-codespaces %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
### Authenticating with a {% data variables.product.pat_generic %}
|
||||
|
||||
@@ -79,16 +87,14 @@ $ bundle config https://{% ifversion fpt or ghec %}rubygems.pkg.github.com{% els
|
||||
|
||||
## Publishing a package
|
||||
|
||||
{% data reusables.package_registry.default-name %} For example, when you publish `<GEM NAME>` to the `octo-org` organization, {% data variables.product.prodname_registry %} publishes the gem to the `octo-org/<GEM NAME>` repository. For more information on creating your gem, see "[Make your own gem](http://guides.rubygems.org/make-your-own-gem/)" in the RubyGems documentation.
|
||||
|
||||
{% data reusables.package_registry.viewing-packages %}
|
||||
{% ifversion packages-rubygems-v2 %}{% data reusables.package_registry.publishing-user-scoped-packages %}{% else %}By default, GitHub publishes the package to an existing repository with the same name as the package. For example, when you publish `<GEM NAME>` to the `octo-org` organization, GitHub Packages publishes the gem to the `octo-org/<GEM NAME>` repository.{% endif %} For more information on creating your gem, see "[Make your own gem](http://guides.rubygems.org/make-your-own-gem/)" in the RubyGems documentation.
|
||||
|
||||
{% data reusables.package_registry.authenticate-step %}
|
||||
2. Build the package from the *gemspec* to create the *.gem* package.
|
||||
1. Build the package from the *gemspec* to create the *.gem* package.
|
||||
```
|
||||
gem build <GEM NAME>.gemspec
|
||||
```
|
||||
3. Publish a package to {% data variables.product.prodname_registry %}, replacing `OWNER` with the name of the user or organization account that owns the repository containing your project and `<GEM NAME>` with the name of your gem package.{% ifversion ghes %} Replace `REGISTRY-URL` with the URL for your instance's Rubygems registry. If your instance has subdomain isolation enabled, use `rubygems.HOSTNAME`. If your instance has subdomain isolation disabled, use `HOSTNAME/_registry/rubygems`. In either case, replace *HOSTNAME* with the host name of your {% data variables.product.prodname_ghe_server %} instance.{% elsif ghae %} Replace `REGISTRY-URL` with the URL for your instance's Rubygems registry, `rubygems.HOSTNAME`. Replace *HOSTNAME* with the hostname of {% data variables.location.product_location %}.{% endif %}
|
||||
1. Publish a package to {% data variables.product.prodname_registry %}, replacing `OWNER` with the name of {% ifversion packages-rubygems-v2 %}your user or organization account{% else %}the user or organization account that owns the repository containing your project{% endif %} and `<GEM NAME>` with the name of your gem package.{% ifversion ghes %} Replace `REGISTRY-URL` with the URL for your instance's Rubygems registry. If your instance has subdomain isolation enabled, use `rubygems.HOSTNAME`. If your instance has subdomain isolation disabled, use `HOSTNAME/_registry/rubygems`. In either case, replace *HOSTNAME* with the host name of your {% data variables.product.prodname_ghe_server %} instance.{% elsif ghae %} Replace `REGISTRY-URL` with the URL for your instance's Rubygems registry, `rubygems.HOSTNAME`. Replace *HOSTNAME* with the hostname of {% data variables.location.product_location %}.{% endif %}
|
||||
|
||||
```
|
||||
$ gem push --key github \
|
||||
@@ -96,6 +102,22 @@ $ bundle config https://{% ifversion fpt or ghec %}rubygems.pkg.github.com{% els
|
||||
<GEM NAME>-0.0.1.gem
|
||||
```
|
||||
|
||||
{% ifversion packages-rubygems-v2 %}
|
||||
|
||||
## Connecting a package to a repository
|
||||
|
||||
The RubyGems registry stores packages within your organization or personal account, and allows you to associate packages with a repository. You can choose whether to inherit permissions from a repository, or set granular permissions independently of a repository.
|
||||
|
||||
You can ensure gems will be linked to a repository as soon as they are published by including the URL of the {% data variables.product.prodname_dotcom %} repository in the `github_repo` field in `gem.metadata`. You can link multiple gems to the same repository. {% ifversion ghes %} In the following example, replace *HOSTNAME* with the host name of {% data variables.location.product_location %}.{% endif %}
|
||||
|
||||
```ruby
|
||||
gem.metadata = { "github_repo" => "ssh://{% ifversion fpt or ghec %}github.com{% else %}HOSTNAME{% endif %}/OWNER/REPOSITORY" }
|
||||
```
|
||||
|
||||
For information on linking a published package with a repository, see "[Connecting a repository to a package](/packages/learn-github-packages/connecting-a-repository-to-a-package)."
|
||||
|
||||
{% else %}
|
||||
|
||||
## Publishing multiple packages to the same repository
|
||||
|
||||
To publish multiple gems to the same repository, you can include the URL to the {% data variables.product.prodname_dotcom %} repository in the `github_repo` field in `gem.metadata`. If you include this field, {% data variables.product.prodname_dotcom %} matches the repository based on this value, instead of using the gem name.{% ifversion ghes or ghae %} Replace *HOSTNAME* with the host name of {% data variables.location.product_location %}.{% endif %}
|
||||
@@ -104,12 +126,14 @@ To publish multiple gems to the same repository, you can include the URL to the
|
||||
gem.metadata = { "github_repo" => "ssh://{% ifversion fpt or ghec %}github.com{% else %}HOSTNAME{% endif %}/OWNER/REPOSITORY" }
|
||||
```
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Installing a package
|
||||
|
||||
You can use gems from {% data variables.product.prodname_registry %} much like you use gems from *rubygems.org*. You need to authenticate to {% data variables.product.prodname_registry %} by adding your {% data variables.product.prodname_dotcom %} user or organization as a source in the *~/.gemrc* file or by using Bundler and editing your *Gemfile*.
|
||||
|
||||
{% data reusables.package_registry.authenticate-step %}
|
||||
1. For Bundler, add your {% data variables.product.prodname_dotcom %} user or organization as a source in your *Gemfile* to fetch gems from this new source. For example, you can add a new `source` block to your *Gemfile* that uses {% data variables.product.prodname_registry %} only for the packages you specify, replacing *GEM NAME* with the package you want to install from {% data variables.product.prodname_registry %} and *OWNER* with the user or organization that owns the repository containing the gem you want to install.{% ifversion ghes %} Replace `REGISTRY-URL` with the URL for your instance's Rubygems registry. If your instance has subdomain isolation enabled, use `rubygems.HOSTNAME`. If your instance has subdomain isolation disabled, use `HOSTNAME/_registry/rubygems`. In either case, replace *HOSTNAME* with the host name of your {% data variables.product.prodname_ghe_server %} instance.{% elsif ghae %} Replace `REGISTRY-URL` with the URL for your instance's Rubygems registry, `rubygems.HOSTNAME`. Replace *HOSTNAME* with the hostname of {% data variables.location.product_location %}.{% endif %}
|
||||
1. For Bundler, add your {% data variables.product.prodname_dotcom %} user or organization as a source in your *Gemfile* to fetch gems from this new source. For example, you can add a new `source` block to your *Gemfile* that uses {% data variables.product.prodname_registry %} only for the packages you specify, replacing *GEM NAME* with the package you want to install from {% data variables.product.prodname_registry %} and *OWNER* with the user or organization that owns {% ifversion packages-rubygems-v2 %}{%else%}the repository containing {% endif %}the gem you want to install.{% ifversion ghes %} Replace `REGISTRY-URL` with the URL for your instance's Rubygems registry. If your instance has subdomain isolation enabled, use `rubygems.HOSTNAME`. If your instance has subdomain isolation disabled, use `HOSTNAME/_registry/rubygems`. In either case, replace *HOSTNAME* with the host name of your {% data variables.product.prodname_ghe_server %} instance.{% elsif ghae %} Replace `REGISTRY-URL` with the URL for your instance's Rubygems registry, `rubygems.HOSTNAME`. Replace *HOSTNAME* with the hostname of {% data variables.location.product_location %}.{% endif %}
|
||||
|
||||
```ruby
|
||||
source "https://rubygems.org"
|
||||
|
||||