зеркало из https://github.com/github/docs.git
Merge branch 'check-links-improvement-redux' of github.com:github/docs-internal into check-links-improvement-redux
This commit is contained in:
Sarah Schneider
Коммит
dca73aa39c
|
|
@ -25,12 +25,13 @@ module.exports = [
|
|||
'pascalgn/automerge-action@c9bd182',
|
||||
'peter-evans/create-issue-from-file@a04ce672e3acedb1f8e416b46716ddfd09905326',
|
||||
'peter-evans/create-or-update-comment@5221bf4aa615e5c6e95bb142f9673a9c791be2cd',
|
||||
'peter-evans/create-pull-request@938e6aea6f8dbdaced2064e948cb806c77fe87b8',
|
||||
'peter-evans/create-pull-request@8c603dbb04b917a9fc2dd991dc54fef54b640b43',
|
||||
'rachmari/actions-add-new-issue-to-column@1a459ef92308ba7c9c9dc2fcdd72f232495574a9',
|
||||
'rachmari/labeler@832d42ec5523f3c6d46e8168de71cd54363e3e2e',
|
||||
'repo-sync/github-sync@3832fe8e2be32372e1b3970bbae8e7079edeec88',
|
||||
'repo-sync/pull-request@33777245b1aace1a58c87a29c90321aa7a74bd7d',
|
||||
'someimportantcompany/github-actions-slack-message@0b470c14b39da4260ed9e3f9a4f1298a74ccdefd',
|
||||
'tjenkinson/gh-action-auto-merge-dependency-updates@cee2ac0',
|
||||
'EndBug/add-and-commit@9358097a71ad9fb9e2f9624c6098c89193d83575'
|
||||
'EndBug/add-and-commit@9358097a71ad9fb9e2f9624c6098c89193d83575',
|
||||
'dorny/paths-filter@eb75a1edc117d3756a18ef89958ee59f9500ba58'
|
||||
]
|
||||
|
|
|
|||
|
|
@ -1,39 +0,0 @@
|
|||
name: Close unwanted pull requests
|
||||
on:
|
||||
pull_request:
|
||||
paths:
|
||||
- '.github/workflows/**'
|
||||
- '.github/CODEOWNERS'
|
||||
- 'translations/**'
|
||||
- 'assets/fonts/**'
|
||||
- 'data/graphql/**'
|
||||
- 'lib/graphql/**'
|
||||
- 'lib/redirects/**'
|
||||
- 'lib/webhooks/**'
|
||||
jobs:
|
||||
close_unwanted_pull_requests:
|
||||
if: github.repository == 'github/docs' && github.event.pull_request.user.login != 'Octomerger'
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/github-script@626af12fe9a53dc2972b48385e7fe7dec79145c9
|
||||
with:
|
||||
script: |
|
||||
await github.issues.createComment({
|
||||
...context.repo,
|
||||
issue_number: context.payload.pull_request.number,
|
||||
body:
|
||||
`Thanks for contributing! We do not accept community changes to these files at this time.
|
||||
- '.github/workflows/**'
|
||||
- '.github/CODEOWNERS'
|
||||
- 'translations/**'
|
||||
- 'assets/fonts/**'
|
||||
- 'data/graphql/**'
|
||||
- 'lib/graphql/**'
|
||||
- 'lib/redirects/**'
|
||||
- 'lib/webhooks/**'`
|
||||
})
|
||||
await github.issues.update({
|
||||
...context.repo,
|
||||
issue_number: context.payload.pull_request.number,
|
||||
state: 'closed'
|
||||
})
|
||||
|
|
@ -2,6 +2,9 @@ name: CodeQL analysis
|
|||
|
||||
on:
|
||||
push:
|
||||
branches: main
|
||||
pull_request:
|
||||
branches: main
|
||||
paths:
|
||||
- '**/*.js'
|
||||
- '.github/workflows/codeql.yml'
|
||||
|
|
|
|||
|
|
@ -0,0 +1,73 @@
|
|||
name: Confirm internal staff meant to post in public
|
||||
|
||||
on:
|
||||
issues:
|
||||
types:
|
||||
- opened
|
||||
- reopened
|
||||
- transferred
|
||||
pull_request_target:
|
||||
types:
|
||||
- opened
|
||||
- reopened
|
||||
|
||||
jobs:
|
||||
check-team-membership:
|
||||
runs-on: ubuntu-latest
|
||||
continue-on-error: true
|
||||
if: github.repository == 'github/docs'
|
||||
steps:
|
||||
- id: membership_check
|
||||
uses: actions/github-script@626af12fe9a53dc2972b48385e7fe7dec79145c9
|
||||
with:
|
||||
github-token: ${{ secrets.DOCUBOT_FR_PROJECT_BOARD_WORKFLOWS_REPO_ORG_READ_SCOPES }}
|
||||
script: |
|
||||
// Only perform this action with GitHub employees
|
||||
try {
|
||||
await github.teams.getMembershipForUserInOrg({
|
||||
org: 'github',
|
||||
team_slug: 'employees',
|
||||
username: context.payload.sender.login,
|
||||
});
|
||||
} catch(err) {
|
||||
// An error will be thrown if the user is not a GitHub employee
|
||||
// If a user is not a GitHub employee, we should stop here and
|
||||
// Not send a notification
|
||||
return
|
||||
}
|
||||
|
||||
// Don't perform this action with Docs team members
|
||||
try {
|
||||
await github.teams.getMembershipForUserInOrg({
|
||||
org: 'github',
|
||||
team_slug: 'docs',
|
||||
username: context.payload.sender.login,
|
||||
});
|
||||
// If the user is a Docs team member, we should stop here and not send
|
||||
// a notification
|
||||
return
|
||||
} catch(err) {
|
||||
// An error will be thrown if the user is not a Docs team member
|
||||
// If a user is not a Docs team member we should continue and send
|
||||
// the notification
|
||||
}
|
||||
|
||||
const issueNo = context.number || context.issue.number
|
||||
|
||||
// Create an issue in our private repo
|
||||
await github.issues.create({
|
||||
owner: 'github',
|
||||
repo: 'docs-internal',
|
||||
title: `@${context.payload.sender.login} confirm that \#${issueNo} should be in the public github/docs repo`,
|
||||
body: `@${context.payload.sender.login} opened https://github.com/github/docs/issues/${issueNo} publicly in the github/docs repo, instead of the private github/docs-internal repo.\n\n@${context.payload.sender.login}, please confirm that this belongs in the public repo and that no sensitive information was disclosed by commenting below and closing the issue.\n\nIf this was not intentional and sensitive information was shared, please delete https://github.com/github/docs/issues/${issueNo} and notify us in the \#docs-open-source channel.\n\nThanks! \n\n/cc @github/docs @github/docs-engineering`
|
||||
});
|
||||
|
||||
core.setOutput('did_warn', 'true')
|
||||
|
||||
- name: Send Slack notification if a GitHub employee who isn't on the docs team opens an issue in public
|
||||
if: ${{ steps.membership_check.outputs.did_warn && github.repository == 'github/docs' }}
|
||||
uses: someimportantcompany/github-actions-slack-message@0b470c14b39da4260ed9e3f9a4f1298a74ccdefd
|
||||
with:
|
||||
channel: ${{ secrets.DOCS_OPEN_SOURCE_SLACK_CHANNEL_ID }}
|
||||
bot-token: ${{ secrets.SLACK_DOCS_BOT_TOKEN }}
|
||||
text: <@${{github.actor}}> opened https://github.com/github/docs/issues/${{ github.event.number || github.event.issue.number }} publicly on the github/docs repo instead of the private github/docs-internal repo. They have been notified via a new issue in the github/docs-internal repo to confirm this was intentional.
|
||||
|
|
@ -33,7 +33,7 @@ jobs:
|
|||
- name: Remove script results file
|
||||
run: rm -rf ./results.md
|
||||
- name: Create pull request
|
||||
uses: peter-evans/create-pull-request@938e6aea6f8dbdaced2064e948cb806c77fe87b8
|
||||
uses: peter-evans/create-pull-request@8c603dbb04b917a9fc2dd991dc54fef54b640b43
|
||||
with:
|
||||
# need to use a token with repo and workflow scopes for this step
|
||||
token: ${{ secrets.OCTOMERGER_PAT_WITH_REPO_AND_WORKFLOW_SCOPE }}
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ name: Repo Sync Stalls
|
|||
on:
|
||||
workflow_dispatch:
|
||||
schedule:
|
||||
- cron: '*/30 * * * *'
|
||||
- cron: '0 */2 * * *'
|
||||
jobs:
|
||||
check-freezer:
|
||||
name: Check for deployment freezes
|
||||
|
|
@ -40,7 +40,7 @@ jobs:
|
|||
const timeDelta = Date.now() - Date.parse(pr.created_at);
|
||||
const minutesOpen = timeDelta / 1000 / 60;
|
||||
|
||||
if (minutesOpen > 30) {
|
||||
if (minutesOpen > 180) {
|
||||
core.setFailed('Repo sync appears to be stalled')
|
||||
}
|
||||
})
|
||||
|
|
|
|||
|
|
@ -7,6 +7,7 @@
|
|||
name: Repo Sync
|
||||
|
||||
on:
|
||||
workflow_dispatch:
|
||||
schedule:
|
||||
- cron: '*/15 * * * *' # every 15 minutes
|
||||
|
||||
|
|
@ -51,7 +52,7 @@ jobs:
|
|||
destination_branch: main
|
||||
pr_title: 'repo sync'
|
||||
pr_body: "This is an automated pull request to sync changes between the public and private repos.\n\n:robot: This pull request should be merged (not squashed) to preserve continuity across repos, so please let a bot do the merging!"
|
||||
pr_label: automerge,autoupdate
|
||||
pr_label: automerge,autoupdate,automated-reposync-pr
|
||||
github_token: ${{ secrets.OCTOMERGER_PAT_WITH_REPO_AND_WORKFLOW_SCOPE }}
|
||||
|
||||
- name: Find pull request
|
||||
|
|
|
|||
|
|
@ -0,0 +1,122 @@
|
|||
name: Check unallowed file changes
|
||||
|
||||
on:
|
||||
pull_request_target:
|
||||
paths:
|
||||
- '.github/workflows/**'
|
||||
- '.github/CODEOWNERS'
|
||||
- 'translations/**'
|
||||
- 'assets/fonts/**'
|
||||
- 'data/graphql/**'
|
||||
- 'lib/graphql/**'
|
||||
- 'lib/redirects/**'
|
||||
- 'lib/rest/**'
|
||||
- 'lib/webhooks/**'
|
||||
|
||||
jobs:
|
||||
triage:
|
||||
if: github.repository == 'github/docs' && github.event.pull_request.user.login != 'Octomerger'
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@5a4ac9002d0be2fb38bd78e4b4dbde5606d7042f
|
||||
- name: Check for existing requested changes
|
||||
id: requested-change
|
||||
uses: actions/github-script@626af12fe9a53dc2972b48385e7fe7dec79145c9
|
||||
with:
|
||||
github-token: ${{secrets.GITHUB_TOKEN}}
|
||||
result-encoding: json
|
||||
script: |
|
||||
const pullReviews = await github.pulls.listReviews({
|
||||
...context.repo,
|
||||
pull_number: context.payload.number
|
||||
})
|
||||
|
||||
const botReviews = pullReviews.data
|
||||
.filter(review => review.user.login === 'github-actions[bot]')
|
||||
.sort((a, b) => new Date(b.submitted_at) - new Date(a.submitted_at))
|
||||
.shift()
|
||||
|
||||
if (botReviews) {
|
||||
console.log(`Pull request reviews authored by the github-action bot: ${botReviews}`)
|
||||
}
|
||||
return botReviews
|
||||
|
||||
- name: Get files changed
|
||||
uses: dorny/paths-filter@eb75a1edc117d3756a18ef89958ee59f9500ba58
|
||||
id: filter
|
||||
with:
|
||||
# Base branch used to get changed files
|
||||
base: 'main'
|
||||
|
||||
# Enables setting an output in the format in `${FILTER_NAME}_files
|
||||
# with the names of the matching files formatted as JSON array
|
||||
list-files: json
|
||||
|
||||
# Returns list of changed files matching each filter
|
||||
filters: |
|
||||
translation:
|
||||
- 'translations/**'
|
||||
openapi:
|
||||
- 'lib/rest/static/**'
|
||||
notAllowed:
|
||||
- '.github/workflows/**'
|
||||
- '.github/CODEOWNERS'
|
||||
- 'translations/**'
|
||||
- 'assets/fonts/**'
|
||||
- 'data/graphql/**'
|
||||
- 'lib/graphql/**'
|
||||
- 'lib/redirects/**'
|
||||
- 'lib/rest/**'
|
||||
- 'lib/webhooks/**'
|
||||
|
||||
# When there are changes to files we can't accept
|
||||
# and no review exists,leave a REQUEST_CHANGES review
|
||||
- name: Request pull request changes
|
||||
# Check for no reviews or reviews that aren't CHANGES_REQUESTED
|
||||
if: ${{ steps.filter.outputs.notAllowed == 'true' && (!steps.requested-change.outputs.result || fromJson(steps.requested-change.outputs.result).state != 'CHANGES_REQUESTED') }}
|
||||
uses: actions/github-script@626af12fe9a53dc2972b48385e7fe7dec79145c9
|
||||
with:
|
||||
github-token: ${{secrets.GITHUB_TOKEN}}
|
||||
script: |
|
||||
const changedFiles = ${{steps.filter.outputs.notAllowed_files}}
|
||||
const restFiles = ${{steps.filter.outputs.openapi_files}}
|
||||
const translationFiles = ${{steps.filter.outputs.translation_files}}
|
||||
const markdownFiles = changedFiles.map(file => `- \`${file}\`\n`).join('')
|
||||
|
||||
let reviewMessage = `👋 Hey there spelunker. It looks like you've modified some files that we can't accept as contributions.\n${markdownFiles}\n\nYou'll need to revert all of these ☝️ files using [GitHub Desktop](https://docs.github.com/en/free-pro-team@latest/desktop/contributing-and-collaborating-using-github-desktop/reverting-a-commit) or \`git checkout origin/main <file name>\`. Once you get those files reverted, we can continue with the review process. :octocat:`
|
||||
|
||||
if (restFiles.length > 0) {
|
||||
reviewMessage += "\n\nIt looks like you've modified the OpenAPI schema (`lib/rest/static/**`). While we aren't accepting changes to the schema directly, you can open an issue for any updates to the REST API docs. Head on over to the [`github/rest-api-description`](https://github.com/github/rest-api-description/issues/new?assignees=&labels=Inaccuracy&template=schema-inaccuracy.md&title=%5BSchema+Inaccuracy%5D+%3CDescribe+Problem%3E) repository to open an issue. ⚡"
|
||||
}
|
||||
|
||||
if (translationFiles.length > 0) {
|
||||
await github.issues.addLabels({
|
||||
...context.repo,
|
||||
issue_number: context.payload.number,
|
||||
labels: ['localization']
|
||||
})
|
||||
reviewMessage += "\n\nIt looks like you've modified translated content. Unfortunately, we are not able to accept pull requests for translated content. Our translation process involves an integration with an external service at crowdin.com, where all translation activity happens. We hope to eventually open up the translation process to the open source community, but we're not there yet. See https://github.com/github/docs/blob/main/CONTRIBUTING.md#earth_asia-translations for more details."
|
||||
}
|
||||
|
||||
await github.pulls.createReview({
|
||||
...context.repo,
|
||||
pull_number: context.payload.number,
|
||||
body: reviewMessage,
|
||||
event: 'REQUEST_CHANGES'
|
||||
})
|
||||
# When the most recent review was CHANGES_REQUESTED and the existing
|
||||
# PR no longer contains unallowed changes, dismiss the previous review
|
||||
- name: Dismiss pull request review
|
||||
# Check that unallowed files aren't modified and that a
|
||||
# CHANGES_REQUESTED review already exists
|
||||
if: ${{ steps.filter.outputs.notAllowed == 'false' && steps.requested-change.outputs.result && fromJson(steps.requested-change.outputs.result).state == 'CHANGES_REQUESTED' }}
|
||||
uses: actions/github-script@626af12fe9a53dc2972b48385e7fe7dec79145c9
|
||||
with:
|
||||
github-token: ${{secrets.GITHUB_TOKEN}}
|
||||
script: |
|
||||
await github.pulls.dismissReview({
|
||||
...context.repo,
|
||||
pull_number: context.payload.number,
|
||||
review_id: ${{fromJson(steps.requested-change.outputs.result).id}},
|
||||
message: `✨Looks like you reverted all files we don't accept contributions for. 🙌 A member of the docs team will review your PR soon. 🚂`
|
||||
})
|
||||
|
|
@ -9,6 +9,7 @@ env:
|
|||
FREEZE: ${{ secrets.FREEZE }}
|
||||
|
||||
on:
|
||||
workflow_dispatch:
|
||||
schedule:
|
||||
- cron: '20 16 * * *' # run every day at 16:20 UTC / 8:20 PST
|
||||
|
||||
|
|
@ -36,15 +37,15 @@ jobs:
|
|||
- name: Run updater scripts
|
||||
env:
|
||||
# need to use a token from a user with access to github/github for this step
|
||||
GITHUB_TOKEN: ${{ secrets.ZEKE_PAT_WITH_REPO_AND_WORKFLOW_SCOPE_FOR_REPO_SYNC }}
|
||||
GITHUB_TOKEN: ${{ secrets.RACHMARI_REPO_WORKFLOW }}
|
||||
run: |
|
||||
script/graphql/update-files.js
|
||||
- name: Create pull request
|
||||
id: create-pull-request
|
||||
uses: peter-evans/create-pull-request@938e6aea6f8dbdaced2064e948cb806c77fe87b8
|
||||
uses: peter-evans/create-pull-request@8c603dbb04b917a9fc2dd991dc54fef54b640b43
|
||||
with:
|
||||
# need to use a token with repo and workflow scopes for this step
|
||||
token: ${{ secrets.OCTOMERGER_PAT_WITH_REPO_AND_WORKFLOW_SCOPE }}
|
||||
token: ${{ secrets.GITHUB_TOKEN }}
|
||||
commit-message: 'Action ran graphql script"update-files"'
|
||||
title: GraphQL schema update
|
||||
body:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,13 @@
|
|||
{
|
||||
"version": "0.2.0",
|
||||
"configurations": [
|
||||
{
|
||||
"type": "node",
|
||||
"request": "attach",
|
||||
"name": "Node: Nodemon",
|
||||
"processId": "${command:PickProcess}",
|
||||
"restart": true,
|
||||
"protocol": "inspector",
|
||||
},
|
||||
]
|
||||
}
|
||||
|
|
@ -10,10 +10,11 @@ GEM
|
|||
|
||||
PLATFORMS
|
||||
ruby
|
||||
x86_64-linux
|
||||
|
||||
DEPENDENCIES
|
||||
graphql (= 1.10.6)
|
||||
graphql-schema_comparator (~> 1.0.0)
|
||||
|
||||
BUNDLED WITH
|
||||
2.1.4
|
||||
2.2.1
|
||||
|
|
|
|||
|
|
@ -50,6 +50,8 @@ There are a few more things to know when you're getting started with this repo:
|
|||
In addition to the README you're reading right now, this repo includes other READMEs that describe the purpose of each subdirectory in more detail:
|
||||
|
||||
- [content/README.md](content/README.md)
|
||||
- [content/graphql/README.md](content/graphql/README.md)
|
||||
- [content/rest/README.md](content/rest/README.md)
|
||||
- [contributing/README.md](contributing/README.md)
|
||||
- [data/README.md](data/README.md)
|
||||
- [data/reusables/README.md](data/reusables/README.md)
|
||||
|
|
|
|||
4
app.json
4
app.json
|
|
@ -2,9 +2,11 @@
|
|||
"name": "docs.github.com",
|
||||
"env": {
|
||||
"NODE_ENV": "production",
|
||||
"NPM_CONFIG_PRODUCTION": "true"
|
||||
"NPM_CONFIG_PRODUCTION": "true",
|
||||
"ENABLED_LANGUAGES": "en, de"
|
||||
},
|
||||
"buildpacks": [
|
||||
{ "url": "https://github.com/DataDog/heroku-buildpack-datadog.git#1.21" },
|
||||
{ "url": "heroku/nodejs" }
|
||||
],
|
||||
"formation": {
|
||||
|
|
|
|||
Двоичный файл не отображается.
|
После Ширина: | Высота: | Размер: 89 KiB |
Двоичный файл не отображается.
|
После Ширина: | Высота: | Размер: 52 KiB |
Двоичный файл не отображается.
|
После Ширина: | Высота: | Размер: 147 KiB |
Двоичный файл не отображается.
|
После Ширина: | Высота: | Размер: 66 KiB |
Двоичный файл не отображается.
|
После Ширина: | Высота: | Размер: 23 KiB |
Двоичный файл не отображается.
|
После Ширина: | Высота: | Размер: 25 KiB |
Двоичный файл не отображается.
|
После Ширина: | Высота: | Размер: 14 KiB |
Двоичный файл не отображается.
|
После Ширина: | Высота: | Размер: 38 KiB |
Двоичный файл не отображается.
|
После Ширина: | Высота: | Размер: 33 KiB |
Двоичный файл не отображается.
|
После Ширина: | Высота: | Размер: 79 KiB |
Двоичный файл не отображается.
|
После Ширина: | Высота: | Размер: 30 KiB |
Двоичные данные
assets/images/help/settings/appearance-tab.png
Двоичные данные
assets/images/help/settings/appearance-tab.png
Двоичный файл не отображается.
|
До Ширина: | Высота: | Размер: 7.5 KiB После Ширина: | Высота: | Размер: 15 KiB |
|
|
@ -176,7 +176,7 @@ git tag -a -m "My first action release" v1
|
|||
git push --follow-tags
|
||||
```
|
||||
|
||||
As an alternative to checking in your `node_modules` directory you can use a tool called [`@vercel/ncc`](https://github.com/vercel/ncc) to compile your code and modules into one file used for distribution.
|
||||
Checking in your `node_modules` directory can cause problems. As an alternative, you can use a tool called [`@vercel/ncc`](https://github.com/vercel/ncc) to compile your code and modules into one file used for distribution.
|
||||
|
||||
1. Install `vercel/ncc` by running this command in your terminal.
|
||||
`npm i -g @vercel/ncc`
|
||||
|
|
|
|||
|
|
@ -117,6 +117,7 @@ runs:
|
|||
{% endraw %}
|
||||
|
||||
#### `outputs.<output_id>.value`
|
||||
|
||||
**Required** The value that the output parameter will be mapped to. You can set this to a `string` or an expression with context. For example, you can use the `steps` context to set the `value` of an output to the output value of a step.
|
||||
|
||||
For more information on how to use context and expression syntax, see "[Context and expression syntax for {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)".
|
||||
|
|
@ -205,7 +206,7 @@ For example, this `cleanup.js` will only run on Linux-based runners:
|
|||
|
||||
**Required** The run steps that you plan to run in this action.
|
||||
|
||||
##### `runs.steps.run`
|
||||
##### `runs.steps[*].run`
|
||||
|
||||
**Required** The command you want to run. This can be inline or a script in your action repository:
|
||||
```yaml
|
||||
|
|
@ -228,23 +229,23 @@ runs:
|
|||
|
||||
For more information, see "[`github context`](/actions/reference/context-and-expression-syntax-for-github-actions#github-context)".
|
||||
|
||||
##### `runs.steps.shell`
|
||||
##### `runs.steps[*].shell`
|
||||
|
||||
**Required** The shell where you want to run the command. You can use any of the shells listed [here](/actions/reference/workflow-syntax-for-github-actions#using-a-specific-shell).
|
||||
|
||||
##### `runs.steps.name`
|
||||
##### `runs.steps[*].name`
|
||||
|
||||
**Optional** The name of the composite run step.
|
||||
|
||||
##### `runs.steps.id`
|
||||
##### `runs.steps[*].id`
|
||||
|
||||
**Optional** A unique identifier for the step. You can use the `id` to reference the step in contexts. For more information, see "[Context and expression syntax for {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)".
|
||||
|
||||
##### `runs.steps.env`
|
||||
##### `runs.steps[*].env`
|
||||
|
||||
**Optional** Sets a `map` of environment variables for only that step. If you want to modify the environment variable stored in the workflow, use {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" %}`echo "{name}={value}" >> $GITHUB_ENV`{% else %}`echo "::set-env name={name}::{value}"`{% endif %} in a composite run step.
|
||||
|
||||
##### `runs.steps.working-directory`
|
||||
##### `runs.steps[*].working-directory`
|
||||
|
||||
**Optional** Specifies the working directory where the command is run.
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ Building and testing your code requires a server. You can build and test updates
|
|||
|
||||
### About continuous integration using {% data variables.product.prodname_actions %}
|
||||
|
||||
CI using {% data variables.product.prodname_actions %} offers workflows that can build the code in your repository and run your tests. Workflows can run on {% data variables.product.prodname_dotcom %}-hosted virtual machines, or on machines that you host yourself. For more information, see "[Virtual environments for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/automating-your-workflow-with-github-actions/virtual-environments-for-github-hosted-runners)," and "[About self-hosted runners](/actions/automating-your-workflow-with-github-actions/about-self-hosted-runners)."
|
||||
CI using {% data variables.product.prodname_actions %} offers workflows that can build the code in your repository and run your tests. Workflows can run on {% data variables.product.prodname_dotcom %}-hosted virtual machines, or on machines that you host yourself. For more information, see "[Virtual environments for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/automating-your-workflow-with-github-actions/virtual-environments-for-github-hosted-runners)" and "[About self-hosted runners](/actions/automating-your-workflow-with-github-actions/about-self-hosted-runners)."
|
||||
|
||||
You can configure your CI workflow to run when a {% data variables.product.product_name %} event occurs (for example, when new code is pushed to your repository), on a set schedule, or when an external event occurs using the repository dispatch webhook.
|
||||
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ jobs:
|
|||
with:
|
||||
java-version: 1.8
|
||||
- name: Build with Maven
|
||||
run: mvn -B package --file pom.xml
|
||||
run: mvn --batch-mode --update-snapshots verify
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
|
|
@ -85,7 +85,7 @@ steps:
|
|||
with:
|
||||
java-version: 1.8
|
||||
- name: Run the Maven verify phase
|
||||
run: mvn -B verify --file pom-ci.xml
|
||||
run: mvn --batch-mode --update-snapshots verify
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
|
|
@ -108,7 +108,7 @@ steps:
|
|||
key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }}
|
||||
restore-keys: ${{ runner.os }}-m2
|
||||
- name: Build with Maven
|
||||
run: mvn -B package --file pom.xml
|
||||
run: mvn --batch-mode --update-snapshots verify
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
|
|
@ -125,7 +125,7 @@ Maven will usually create output files like JARs, EARs, or WARs in the `target`
|
|||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- uses: actions/setup-java@v1
|
||||
- run: mvn -B package --file pom.xml
|
||||
- run: mvn --batch-mode --update-snapshots verify
|
||||
- run: mkdir staging && cp target/*.jar staging
|
||||
- uses: actions/upload-artifact@v2
|
||||
with:
|
||||
|
|
|
|||
|
|
@ -193,9 +193,9 @@ steps:
|
|||
|
||||
{% data reusables.github-actions.setup-node-intro %}
|
||||
|
||||
To authenticate to your private registry, you'll need to store your npm authentication token as a secret in your repository settings. For example, create a secret called `NPM_TOKEN`. For more information, see "[Creating and using encrypted secrets](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
|
||||
To authenticate to your private registry, you'll need to store your npm authentication token as a secret. For example, create a repository secret called `NPM_TOKEN`. For more information, see "[Creating and using encrypted secrets](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
|
||||
|
||||
In the example below, the secret `NPM_TOKEN` stores the npm authentication token. The `setup-node` action configures the *.npmrc* file to read the npm authentication token from the `NODE_AUTH_TOKEN` environment variable. When using the `setup-node` action to create an *.npmrc* file, you must set the `NPM_AUTH_TOKEN` environment variable with the secret that contains your npm authentication token.
|
||||
In the example below, the secret `NPM_TOKEN` stores the npm authentication token. The `setup-node` action configures the *.npmrc* file to read the npm authentication token from the `NODE_AUTH_TOKEN` environment variable. When using the `setup-node` action to create an *.npmrc* file, you must set the `NODE_AUTH_TOKEN` environment variable with the secret that contains your npm authentication token.
|
||||
|
||||
Before installing dependencies, use the `setup-node` action to create the *.npmrc* file. The action has two input parameters. The `node-version` parameter sets the Node.js version, and the `registry-url` parameter sets the default registry. If your package registry uses scopes, you must use the `scope` parameter. For more information, see [`npm-scope`](https://docs.npmjs.com/misc/scope).
|
||||
|
||||
|
|
|
|||
|
|
@ -214,7 +214,7 @@ The `always()` function configures the job to continue processing even if there
|
|||
|
||||
### Publishing to PowerShell Gallery
|
||||
|
||||
You can configure your workflow to publish your PowerShell module to the PowerShell Gallery when your CI tests pass. You can use repository secrets to store any tokens or credentials needed to publish your package. For more information, see "[Creating and using encrypted secrets](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
|
||||
You can configure your workflow to publish your PowerShell module to the PowerShell Gallery when your CI tests pass. You can use secrets to store any tokens or credentials needed to publish your package. For more information, see "[Creating and using encrypted secrets](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
|
||||
|
||||
The following example creates a package and uses `Publish-Module` to publish it to the PowerShell Gallery:
|
||||
|
||||
|
|
|
|||
|
|
@ -391,7 +391,7 @@ jobs:
|
|||
|
||||
You can configure your workflow to publish your Python package to any package registry you'd like when your CI tests pass.
|
||||
|
||||
You can store any access tokens or credentials needed to publish your package using repository secrets. The following example creates and publishes a package to PyPI using `twine` and `dist`. For more information, see "[Creating and using encrypted secrets](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
|
||||
You can store any access tokens or credentials needed to publish your package using secrets. The following example creates and publishes a package to PyPI using `twine` and `dist`. For more information, see "[Creating and using encrypted secrets](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ To push to Docker Hub, you will need to have a Docker Hub account, and have a Do
|
|||
|
||||
The `build-push-action` options required for Docker Hub are:
|
||||
|
||||
* `username` and `password`: This is your Docker Hub username and password. We recommend storing your Docker Hub username and password as encrypted secrets in your {% data variables.product.prodname_dotcom %} repository so they aren't exposed in your workflow file. For more information, see "[Creating and using encrypted secrets](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
|
||||
* `username` and `password`: This is your Docker Hub username and password. We recommend storing your Docker Hub username and password as secrets so they aren't exposed in your workflow file. For more information, see "[Creating and using encrypted secrets](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
|
||||
* `repository`: Your Docker Hub repository in the format `DOCKER-HUB-NAMESPACE/DOCKER-HUB-REPOSITORY`.
|
||||
|
||||
{% raw %}
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ jobs:
|
|||
server-username: MAVEN_USERNAME
|
||||
server-password: MAVEN_PASSWORD
|
||||
- name: Publish package
|
||||
run: mvn -B deploy
|
||||
run: mvn --batch-mode deploy
|
||||
env:
|
||||
MAVEN_USERNAME: ${{ secrets.OSSRH_USERNAME }}
|
||||
MAVEN_PASSWORD: ${{ secrets.OSSRH_TOKEN }}
|
||||
|
|
@ -143,7 +143,7 @@ jobs:
|
|||
with:
|
||||
java-version: 1.8
|
||||
- name: Publish package
|
||||
run: mvn -B deploy
|
||||
run: mvn --batch-mode deploy
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
```
|
||||
|
|
@ -182,7 +182,7 @@ jobs:
|
|||
server-username: MAVEN_USERNAME
|
||||
server-password: MAVEN_PASSWORD
|
||||
- name: Publish to the Maven Central Repository
|
||||
run: mvn -B deploy
|
||||
run: mvn --batch-mode deploy
|
||||
env:
|
||||
MAVEN_USERNAME: ${{ secrets.OSSRH_USERNAME }}
|
||||
MAVEN_PASSWORD: ${{ secrets.OSSRH_TOKEN }}
|
||||
|
|
@ -191,7 +191,7 @@ jobs:
|
|||
with:
|
||||
java-version: 1.8
|
||||
- name: Publish to GitHub Packages
|
||||
run: mvn -B deploy
|
||||
run: mvn --batch-mode deploy
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
```
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ If you add steps in your workflow to configure the `publishConfig` fields in you
|
|||
|
||||
Each time you create a new release, you can trigger a workflow to publish your package. The workflow in the example below runs when the `release` event triggers with type `created`. The workflow publishes the package to the npm registry if CI tests pass.
|
||||
|
||||
To perform authenticated operations against the npm registry in your workflow, you'll need to store your npm authentication token as a secret in your repository settings. For example, create a secret called `NPM_TOKEN`. For more information, see "[Creating and using encrypted secrets](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
|
||||
To perform authenticated operations against the npm registry in your workflow, you'll need to store your npm authentication token as a secret. For example, create a repository secret called `NPM_TOKEN`. For more information, see "[Creating and using encrypted secrets](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
|
||||
|
||||
By default, npm uses the `name` field of the *package.json* file to determine the npm registry. When publishing to a global namespace, you only need to include the package name. For example, you would publish a package named `npm-hello-world-test` to the `https://www.npmjs.com/package/npm-hello-world-test`.
|
||||
|
||||
|
|
|
|||
|
|
@ -25,18 +25,15 @@ featuredLinks:
|
|||
- /actions/reference/workflow-commands-for-github-actions
|
||||
- /actions/reference/environment-variables
|
||||
changelog:
|
||||
- title: Workflow visualization
|
||||
date: '2020-12-08'
|
||||
href: https://github.blog/changelog/2020-12-08-github-actions-workflow-visualization/
|
||||
- title: Removing set-env and add-path commands on November 16
|
||||
date: '2020-11-09'
|
||||
href: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/
|
||||
- title: Ubuntu-latest workflows will use Ubuntu-20.04
|
||||
date: '2020-10-29'
|
||||
href: https://github.blog/changelog/2020-10-29-github-actions-ubuntu-latest-workflows-will-use-ubuntu-20-04
|
||||
- title: MacOS Big Sur Preview
|
||||
date: '2020-10-29'
|
||||
href: https://github.blog/changelog/2020-10-29-github-actions-macos-big-sur-preview
|
||||
- title: Self-Hosted Runner Group Access Changes
|
||||
date: '2020-10-16'
|
||||
href: https://github.blog/changelog/2020-10-16-github-actions-self-hosted-runner-group-access-changes/
|
||||
|
||||
product_video: https://www.youtube-nocookie.com/embed/cP0I9w2coGU
|
||||
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ steps:
|
|||
|
||||
#### Using branches
|
||||
|
||||
Referring to a specific branch means that the action will always use include the latest updates on the target branch, but can create problems if those updates include breaking changes. This example targets a branch named `@main`:
|
||||
Referring to a specific branch means that the action will always use the latest updates on the target branch, but can create problems if those updates include breaking changes. This example targets a branch named `@main`:
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: Managing complex workflows
|
||||
shortTitle: Managing complex workflows
|
||||
intro: 'This guide shows you how to use the advanced features of {% data variables.product.prodname_actions %}, with secret management, dependent jobs, caching, build matrices, and labels.'
|
||||
intro: 'This guide shows you how to use the advanced features of {% data variables.product.prodname_actions %}, with secret management, dependent jobs, caching, build matrices,{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %} environments,{% endif %} and labels.'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=2.22'
|
||||
|
|
@ -148,6 +148,12 @@ jobs:
|
|||
|
||||
For more information, see ["Using labels with self-hosted runners](/actions/hosting-your-own-runners/using-labels-with-self-hosted-runners)."
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
|
||||
### Using environments
|
||||
|
||||
You can configure environments with protection rules and secrets. Each job in a workflow can reference a single environment. Any protection rules configured for the environment must pass before a job referencing the environment is sent to a runner. For more information, see "[Environments](/actions/reference/environments)."
|
||||
{% endif %}
|
||||
|
||||
### Next steps
|
||||
|
||||
To continue learning about {% data variables.product.prodname_actions %}, see "[Sharing workflows with your organization](/actions/learn-github-actions/sharing-workflows-with-your-organization)."
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ Jenkins uses directives to manage _Declarative Pipelines_. These directives defi
|
|||
|
||||
| Jenkins Directives | {% data variables.product.prodname_actions %} |
|
||||
| ------------- | ------------- |
|
||||
| [`environment`](https://jenkins.io/doc/book/pipeline/syntax/#environment) | [`jobs.<job_id>.env`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#env) <br> [`jobs.<job_id>.steps.env`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepsenv) |
|
||||
| [`environment`](https://jenkins.io/doc/book/pipeline/syntax/#environment) | [`jobs.<job_id>.env`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#env) <br> [`jobs.<job_id>.steps[*].env`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepsenv) |
|
||||
| [`options`](https://jenkins.io/doc/book/pipeline/syntax/#parameters) | [`jobs.<job_id>.strategy`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategy) <br> [`jobs.<job_id>.strategy.fail-fast`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategyfail-fast) <br> [`jobs.<job_id>.timeout-minutes`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes)|
|
||||
| [`parameters`](https://jenkins.io/doc/book/pipeline/syntax/#parameters) | [`inputs`](/actions/creating-actions/metadata-syntax-for-github-actions#inputs) <br> [`outputs`](/actions/creating-actions/metadata-syntax-for-github-actions#outputs) |
|
||||
| [`triggers`](https://jenkins.io/doc/book/pipeline/syntax/#triggers) | [`on`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#on) <br> [`on.<event_name>.types`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onevent_nametypes) <br> [<code>on.<push\|pull_request>.<branches\|tags></code>](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onpushpull_requestbranchestags) <br> [<code>on.<push\|pull_request>.paths</code>](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onpushpull_requestpaths) |
|
||||
|
|
|
|||
|
|
@ -176,7 +176,7 @@ When migrating from Travis CI, consider the following key features in {% data va
|
|||
|
||||
#### Storing secrets
|
||||
|
||||
{% data variables.product.prodname_actions %} allows you to store secrets and reference them in your jobs. {% data variables.product.prodname_actions %} also includes policies that allow you to limit access to secrets at the repository and organization level. For more information, see "[Encrypted secrets](/actions/reference/encrypted-secrets)."
|
||||
{% data variables.product.prodname_actions %} allows you to store secrets and reference them in your jobs. {% data variables.product.prodname_actions %} organizations can limit which repositories can access organization secrets. {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}Environment protection rules can require manual approval for a workflow to access environment secrets. {% endif %}For more information, see "[Encrypted secrets](/actions/reference/encrypted-secrets)."
|
||||
|
||||
#### Sharing files between jobs and workflows
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ This guide explains how to configure security hardening for certain {% data vari
|
|||
|
||||
### Using secrets
|
||||
|
||||
Sensitive values should never be stored as plaintext in workflow files, but rather as secrets. [Secrets](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets) can be configured at the organization or repository level, and allow you to store sensitive information in {% data variables.product.product_name %}.
|
||||
Sensitive values should never be stored as plaintext in workflow files, but rather as secrets. [Secrets](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets) can be configured at the organization{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}, repository, or environment{% else %} or repository{% endif %} level, and allow you to store sensitive information in {% data variables.product.product_name %}.
|
||||
|
||||
Secrets use [Libsodium sealed boxes](https://libsodium.gitbook.io/doc/public-key_cryptography/sealed_boxes), so that they are encrypted before reaching {% data variables.product.product_name %}. This occurs when the secret is submitted [using the UI](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets#creating-encrypted-secrets-for-a-repository) or through the [REST API](/rest/reference/actions#secrets). This client-side encryption helps the minimize risks related to accidental logging (for example, exception logs and request logs, among others) within {% data variables.product.product_name %}'s infrastructure. Once the secret is uploaded, {% data variables.product.product_name %} is then able to decrypt it so that it can be injected into the workflow runtime.
|
||||
|
||||
|
|
@ -38,6 +38,10 @@ To help prevent accidental disclosure, {% data variables.product.product_name %}
|
|||
- **Audit and rotate registered secrets**
|
||||
- Periodically review the registered secrets to confirm they are still required. Remove those that are no longer needed.
|
||||
- Rotate secrets periodically to reduce the window of time during which a compromised secret is valid.
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
|
||||
- **Consider requiring review for access to secrets**
|
||||
- You can use required reviewers to protect environment secrets. A workflow job cannot access environment secrets until approval is granted by a reviewer. For more information about storing secrets in environments or requiring reviews for environments, see "[Encrypted secrets](/actions/reference/encrypted-secrets)" and "[Environments](/actions/reference/environments)."
|
||||
{% endif %}
|
||||
|
||||
### Using third-party actions
|
||||
|
||||
|
|
@ -54,6 +58,8 @@ This means that a compromise of a single action within a workflow can be very si
|
|||
**Warning:** The short version of the commit SHA is insecure and should never be used for specifying an action's Git reference. Because of how repository networks work, any user can fork the repository and push a crafted commit to it that collides with the short SHA. This causes subsequent clones at that SHA to fail because it becomes an ambiguous commit. As a result, any workflows that use the shortened SHA will immediately fail.
|
||||
|
||||
{% endwarning %}
|
||||
|
||||
|
||||
* **Audit the source code of the action**
|
||||
|
||||
Ensure that the action is handling the content of your repository and secrets as expected. For example, check that secrets are not sent to unintended hosts, or are not inadvertently logged.
|
||||
|
|
@ -64,13 +70,13 @@ This means that a compromise of a single action within a workflow can be very si
|
|||
|
||||
### Considering cross-repository access
|
||||
|
||||
{% data variables.product.product_name %} is intentionally scoped for a single repository at a time. The `GITHUB_TOKEN` used in the workflow environment grants the same level of access as a write-access user, because any write-access user can access this token by creating or modifying workflow files. Users have specific permissions for each repository, so having the `GITHUB_TOKEN` for one repository grant access to another would impact the {% data variables.product.prodname_dotcom %} permission model if not implemented carefully. Similarly, caution must be taken when adding {% data variables.product.prodname_dotcom %} authentication tokens to the workflow environment, because this can also affect the {% data variables.product.prodname_dotcom %} permission model by inadvertently granting broad access to collaborators.
|
||||
{% data variables.product.product_name %} is intentionally scoped for a single repository at a time. The `GITHUB_TOKEN` grants the same level of access as a write-access user, because any write-access user can access this token by creating or modifying workflow files. Users have specific permissions for each repository, so having the `GITHUB_TOKEN` for one repository grant access to another would impact the {% data variables.product.prodname_dotcom %} permission model if not implemented carefully. Similarly, caution must be taken when adding {% data variables.product.prodname_dotcom %} authentication tokens to a workflow, because this can also affect the {% data variables.product.prodname_dotcom %} permission model by inadvertently granting broad access to collaborators.
|
||||
|
||||
We have [a plan on the {% data variables.product.prodname_dotcom %} roadmap](https://github.com/github/roadmap/issues/74) to support a flow that allows cross-repository access within {% data variables.product.product_name %}, but this is not yet a supported feature. Currently, the only way to perform privileged cross-repository interactions is to place a {% data variables.product.prodname_dotcom %} authentication token or SSH key as a secret within the workflow environment. Because many authentication token types do not allow for granular access to specific resources, there is significant risk in using the wrong token type, as it can grant much broader access than intended.
|
||||
We have [a plan on the {% data variables.product.prodname_dotcom %} roadmap](https://github.com/github/roadmap/issues/74) to support a flow that allows cross-repository access within {% data variables.product.product_name %}, but this is not yet a supported feature. Currently, the only way to perform privileged cross-repository interactions is to place a {% data variables.product.prodname_dotcom %} authentication token or SSH key as a secret within the workflow. Because many authentication token types do not allow for granular access to specific resources, there is significant risk in using the wrong token type, as it can grant much broader access than intended.
|
||||
|
||||
This list describes the recommended approaches for accessing repository data within a workflow, in descending order of preference:
|
||||
|
||||
1. **The `GITHUB_TOKEN` in the workflow environment**
|
||||
1. **The `GITHUB_TOKEN`**
|
||||
- This token is intentionally scoped to the single repository that invoked the workflow, and has the same level of access as a write-access user on the repository. The token is created before each job begins and expires when the job is finished. For more information, see "[Authenticating with the GITHUB_TOKEN](/actions/configuring-and-managing-workflows/authenticating-with-the-github_token)."
|
||||
- The `GITHUB_TOKEN` should be used whenever possible.
|
||||
2. **Repository deploy key**
|
||||
|
|
@ -92,10 +98,14 @@ This list describes the recommended approaches for accessing repository data wit
|
|||
|
||||
As a result, self-hosted runners should almost [never be used for public repositories](/actions/hosting-your-own-runners/about-self-hosted-runners#self-hosted-runner-security-with-public-repositories) on {% data variables.product.product_name %}, because any user can open pull requests against the repository and compromise the environment. Similarly, be cautious when using self-hosted runners on private repositories, as anyone who can fork the repository and open a PR (generally those with read-access to the repository) are able to compromise the self-hosted runner environment, including gaining access to secrets and the more privileged `GITHUB_TOKEN` which grants write-access permissions on the repository.
|
||||
|
||||
When a self-hosted runner is defined at the organization or enterprise level, {% data variables.product.product_name %} can schedule workflows from multiple repositories onto the same runner. Consequently, a security compromise of these environments can result in a wide impact. To help reduce the scope of a compromise, you can create boundaries by organizing your self-hosted runners into separate groups. For more information, see "[Managing access to self-hosted runners using groups](/actions/hosting-your-own-runners/managing-access-to-self-hosted-runners-using-groups)."
|
||||
|
||||
You should also consider the environment of the self-hosted runner machines:
|
||||
- What sensitive information resides on the machine configured as a self-hosted runner? For example, private SSH keys, API access tokens, among others.
|
||||
- Does the machine have network access to sensitive services? For example, Azure or AWS metadata services. The amount of sensitive information in this environment should be kept to a minimum, and you should always be mindful that any user capable of invoking workflows has access to this environment.
|
||||
|
||||
Some customers might attempt to partially mitigate these risks by implementing systems that automatically destroy the self-hosted runner after each job execution. However, this approach might not be as effective as intended, as there is no way to guarantee that a self-hosted runner only runs one job.
|
||||
|
||||
### Auditing {% data variables.product.prodname_actions %} events
|
||||
|
||||
You can use the audit log to monitor administrative tasks in an organization. The audit log records the type of action, when it was run, and which user account performed the action.
|
||||
|
|
@ -132,5 +142,3 @@ The following tables describe the {% data variables.product.prodname_actions %}
|
|||
| `action:org.runner_group_renamed` | Triggered when an organization admin renames a self-hosted runner group.
|
||||
| `action:org.runner_group_runners_added` | Triggered when an organization admin [adds a self-hosted runner to a group](/actions/hosting-your-own-runners/managing-access-to-self-hosted-runners-using-groups#moving-a-self-hosted-runner-to-a-group).
|
||||
| `action:org.runner_group_runners_removed` | Triggered when an organization admin removes a self-hosted runner from a group.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -13,6 +13,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.github-actions.permissions-statement-secrets-repository %}
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
|
||||
- {% data reusables.github-actions.permissions-statement-secrets-environment %}
|
||||
{% endif %}
|
||||
- {% data reusables.github-actions.permissions-statement-secrets-organization %}
|
||||
- {% data reusables.github-actions.permissions-statement-secrets-api %}
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: Managing workflow runs
|
||||
shortTitle: Managing workflow runs
|
||||
intro: 'You can view the status and results of each step in your workflow, cancel a pending workflow, view billable job execution minutes, debug and re-run a failed workflow, search and download logs, and download artifacts.'
|
||||
intro: 'You can view the status and results of each step in your workflow, cancel a pending workflow, {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}review deployments, {% endif %}view billable job execution minutes, debug and re-run a failed workflow, search and download logs, and download artifacts.'
|
||||
redirect_from:
|
||||
- /actions/configuring-and-managing-workflows/managing-a-workflow-run
|
||||
- /articles/viewing-your-repository-s-workflows
|
||||
|
|
@ -24,6 +24,7 @@ versions:
|
|||
{% link_in_list /manually-running-a-workflow %}
|
||||
{% link_in_list /re-running-a-workflow %}
|
||||
{% link_in_list /canceling-a-workflow %}
|
||||
{% link_in_list /reviewing-deployments %}
|
||||
{% link_in_list /disabling-and-enabling-a-workflow %}
|
||||
{% link_in_list /deleting-a-workflow-run %}
|
||||
{% link_in_list /viewing-job-execution-time %}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,27 @@
|
|||
---
|
||||
title: Reviewing deployments
|
||||
intro: You can approve or reject jobs awaiting review.
|
||||
product: '{% data reusables.gated-features.environments %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=3.1'
|
||||
---
|
||||
|
||||
{% data reusables.actions.environments-beta %}
|
||||
|
||||
### About required reviews in workflows
|
||||
|
||||
Jobs that reference an environment configured with required reviewers will wait for an approval before starting. While a job is awaiting approval, it has a status of "Waiting". If a job is not approved within 30 days, the workflow run will be automatically canceled.
|
||||
|
||||
For more information about environments and required approvals, see "[Environments](/actions/reference/environments)."
|
||||
|
||||
### Approving or rejecting a job
|
||||
|
||||
1. Navigate to the workflow run that requires review. For more information about navigating to a workflow run, see "[Viewing workflow run history](/actions/managing-workflow-runs/viewing-workflow-run-history)."
|
||||
2. Click **Review deployments**.
|
||||
|
||||
3. Select the job environment(s) to approve or reject. Optionally, leave a comment.
|
||||
|
||||
4. Approve or reject:
|
||||
- To approve the job, click **Approve and deploy**. Once a job is approved (and any other environment protection rules have passed), the job will proceed. At this point, the job can access any secrets stored in the environment.
|
||||
- To reject the job, click **Reject**. If a job is rejected, the workflow will fail.
|
||||
|
|
@ -14,8 +14,6 @@ versions:
|
|||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
Anyone with `write` access to a repository can create, read, and use secrets.
|
||||
|
||||
### About the `GITHUB_TOKEN` secret
|
||||
|
||||
{% data variables.product.prodname_dotcom %} automatically creates a `GITHUB_TOKEN` secret to use in your workflow. You can use the `GITHUB_TOKEN` to authenticate in a workflow run.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Encrypted secrets
|
||||
intro: Encrypted secrets allow you to store sensitive information in your repository or organization.
|
||||
intro: Encrypted secrets allow you to store sensitive information in your organization{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}, repository, or repository environments{% else %} or repository{% endif %}.
|
||||
product: '{% data reusables.gated-features.actions %}'
|
||||
redirect_from:
|
||||
- /github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
|
||||
|
|
@ -12,14 +12,19 @@ versions:
|
|||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.environments-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
### About encrypted secrets
|
||||
|
||||
Secrets are encrypted environment variables that you create in a repository or organization. The secrets 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 environment variables that you create in an organization{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}, repository, or repository environment{% else %} or repository{% endif %}. 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.github-actions.secrets-org-level-overview %}
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
|
||||
For secrets stored at the environment level, you can enable required reviewers to control access to the secrets. A workflow job cannot access environment secrets until approval is granted by required approvers.
|
||||
{% endif %}
|
||||
|
||||
#### Naming your secrets
|
||||
|
||||
The following rules apply to secret names:
|
||||
|
|
@ -27,7 +32,10 @@ The following rules apply to secret names:
|
|||
* Secret names can only contain alphanumeric characters (`[a-z]`, `[A-Z]`, `[0-9]`) or underscores (`_`). Spaces are not allowed.
|
||||
* Secret names must not start with the `GITHUB_` prefix.
|
||||
* Secret names must not start with a number.
|
||||
* Secret names must be unique at the level they are created at. For example, a secret created at the organization-level must have a unique name at that level, and a secret created at the repository-level must have a unique name in that repository. If an organization-level secret has the same name as a repository-level secret, then the repository-level secret takes precedence.
|
||||
* Secret names are not case-sensitive.
|
||||
* Secret names must be unique at the level they are created at. For example, {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}a secret created at the environment level must have a unique name in that environment, {% endif %}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.
|
||||
|
||||
If a secret with the same name exists at multiple levels, the secret at the lower level takes precedence. For example, if an organization-level secret has the same name as a repository-level secret, then the repository-level secret takes precedence.{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %} Similarly, if an organization, repository, and environment all have a secret with the same name, the environment-level secret takes precedence.{% endif %}
|
||||
|
||||
To help ensure that {% data variables.product.prodname_dotcom %} redacts your secret in logs, avoid using structured data as the values of secrets. For example, avoid creating secrets that contain JSON or encoded Git blobs.
|
||||
|
||||
|
|
@ -43,6 +51,10 @@ You can use and read encrypted secrets in a workflow file if you have access to
|
|||
|
||||
{% endwarning %}
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
|
||||
Organization and repository secrets are read when a workflow run is queued, and environment secrets are read when a job referencing the environment starts.
|
||||
{% endif %}
|
||||
|
||||
You can also manage secrets using the REST API. For more information, see "[Secrets](/rest/reference/actions#secrets)."
|
||||
|
||||
#### Limiting credential permissions
|
||||
|
|
@ -56,12 +68,27 @@ When generating credentials, we recommend that you grant the minimum permissions
|
|||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% data reusables.github-actions.sidebar-secret %}
|
||||
1. Click **Add a new secret**.
|
||||
1. Click **New repository secret**.
|
||||
1. Type a name for your secret in the **Name** input box.
|
||||
1. Enter the value for your secret.
|
||||
1. Click **Add secret**.
|
||||
|
||||
If your repository can access secrets from the parent organization, then those secrets are also listed on this page.
|
||||
If your repository {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}has environment secrets or {% endif %}can access secrets from the parent organization, then those secrets are also listed on this page.
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
|
||||
### Creating encrypted secrets for an environment
|
||||
|
||||
{% data reusables.github-actions.permissions-statement-secrets-environment %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% data reusables.github-actions.sidebar-environment %}
|
||||
1. Click on the environment that you want to add a secret to.
|
||||
1. Under **Environment secrets**, click **Add secret**.
|
||||
1. Type a name for your secret in the **Name** input box.
|
||||
1. Enter the value for your secret.
|
||||
1. Click **Add secret**.
|
||||
{% endif %}
|
||||
|
||||
### Creating encrypted secrets for an organization
|
||||
|
||||
|
|
@ -72,7 +99,7 @@ When creating a secret in an organization, you can use a policy to limit which r
|
|||
{% data reusables.organizations.navigate-to-org %}
|
||||
{% data reusables.organizations.org_settings %}
|
||||
{% data reusables.github-actions.sidebar-secret %}
|
||||
1. Click **New secret**.
|
||||
1. Click **New organization 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.
|
||||
|
|
@ -151,7 +178,7 @@ steps:
|
|||
|
||||
### Limits for secrets
|
||||
|
||||
Your workflow can have up to 100 secrets. The names of secret environment variables must be unique in a repository.
|
||||
You can store up to 1,000 secrets per organization{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}, 100 secrets per repository, and 100 secrets per environment{% else %} and 100 secrets per repository{% endif %}. A workflow may use up to 100 organization secrets and 100 repository secrets.{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %} Additionally, a job referencing an environment may use up to 100 environment secrets.{% endif %}
|
||||
|
||||
Secrets are limited to 64 KB in size. To use secrets that are larger than 64 KB, you can store encrypted secrets in your repository and save the decryption passphrase as a secret on {% data variables.product.prodname_dotcom %}. For example, you can use `gpg` to encrypt your credentials locally before checking the file in to your repository on {% data variables.product.prodname_dotcom %}. For more information, see the "[gpg manpage](https://www.gnupg.org/gph/de/manual/r1023.html)."
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ versions:
|
|||
|
||||
{% data variables.product.prodname_dotcom %} sets default environment variables that are available to every step in a workflow run. Environment variables are case-sensitive. Commands run in actions or steps can create, read, and modify environment variables.
|
||||
|
||||
To set custom environment variables, you need to specify the variables in the workflow file. You can define environment variables for a step, job, or entire workflow using the [`jobs.<job_id>.steps.env`](/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepsenv), [`jobs.<job_id>.env`](/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idenv), and [`env`](/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#env) keywords. For more information, see "[Workflow syntax for {% data variables.product.prodname_dotcom %}](/articles/workflow-syntax-for-github-actions/#jobsjob_idstepsenv)."
|
||||
To set custom environment variables, you need to specify the variables in the workflow file. You can define environment variables for a step, job, or entire workflow using the [`jobs.<job_id>.steps[*].env`](/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepsenv), [`jobs.<job_id>.env`](/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idenv), and [`env`](/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#env) keywords. For more information, see "[Workflow syntax for {% data variables.product.prodname_dotcom %}](/articles/workflow-syntax-for-github-actions/#jobsjob_idstepsenv)."
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
|
|
@ -51,8 +51,8 @@ We strongly recommend that actions use environment variables to access the files
|
|||
| `GITHUB_WORKSPACE` | The {% data variables.product.prodname_dotcom %} workspace directory path. The workspace directory is a copy of your repository if your workflow uses the [actions/checkout](https://github.com/actions/checkout) action. If you don't use the `actions/checkout` action, the directory will be empty. For example, `/home/runner/work/my-repo-name/my-repo-name`. |
|
||||
| `GITHUB_SHA` | The commit SHA that triggered the workflow. For example, `ffac537e6cbbf934b08745a378932722df287a53`. |
|
||||
| `GITHUB_REF` | The branch or tag ref that triggered the workflow. For example, `refs/heads/feature-branch-1`. If neither a branch or tag is available for the event type, the variable will not exist. |
|
||||
| `GITHUB_HEAD_REF` | Only set for forked repositories. The branch of the head repository.
|
||||
| `GITHUB_BASE_REF` | Only set for forked repositories. The branch of the base repository.
|
||||
| `GITHUB_HEAD_REF` | Only set for pull request events. The name of the head branch.
|
||||
| `GITHUB_BASE_REF` | Only set for pull request events. The name of the base branch.
|
||||
| `GITHUB_SERVER_URL`| Returns the URL of the {% data variables.product.product_name %} server. For example: `https://{% data variables.product.product_url %}`.
|
||||
| `GITHUB_API_URL` | Returns the API URL. For example: `{% data variables.product.api_url_code %}`.
|
||||
| `GITHUB_GRAPHQL_URL` | Returns the GraphQL API URL. For example: `{% data variables.product.graphql_url_code %}`.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,69 @@
|
|||
---
|
||||
title: Environments
|
||||
intro: You can configure environments with protection rules and secrets. A workflow job can reference an environment to use the environment's protection rules and secrets.
|
||||
product: '{% data reusables.gated-features.environments %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '>=3.1'
|
||||
---
|
||||
|
||||
{% data reusables.actions.environments-beta %}
|
||||
|
||||
### About environments
|
||||
|
||||
You can configure environments with protection rules and secrets. When a workflow job references an environment, the job won't start until all of the environment's protection rules pass. A job also cannot access secrets that are defined in an environment until all the environment protection rules pass.
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
Environment protection rules and environment secrets are only available on public repositories. If you convert a repository from public to private, any configured protection rules or environment secrets will be ignored, and you will not be able to configure any environments. If you convert your repository back to public, you will have access to any previously configured protection rules and environment secrets.
|
||||
{% endif %}
|
||||
|
||||
#### Environment protection rules
|
||||
|
||||
Environment protection rules require specific conditions to pass before a job referencing the environment can proceed. You can use environment protection rules to require a manual approval or to delay a job.
|
||||
|
||||
##### Required reviewers
|
||||
|
||||
Use required reviewers to require a specific person or team to approve workflow jobs that reference the environment. You can list up to six users or teams as reviewers. The reviewers must have at least read access to the repository. Only one of the required reviewers needs to approve the job for it to proceed.
|
||||
|
||||
For more information on reviewing jobs that reference an environment with required reviewers, see "[Reviewing deployments](/actions/managing-workflow-runs/reviewing-deployments)."
|
||||
|
||||
##### Wait timer
|
||||
|
||||
Use a wait timer to delay a job for a specific amount of time after the job is initially triggered. The time (in minutes) must be an integer between 0 and 43,200 (30 days).
|
||||
|
||||
#### Environment secrets
|
||||
|
||||
Secrets stored in an environment are only available to workflow jobs that reference the environment. If the environment requires approval, a job cannot access environment secrets until one of the required reviewers approves it. For more information about secrets, see "[Encrypted secrets](/actions/reference/encrypted-secrets)."
|
||||
|
||||
### Creating an environment
|
||||
|
||||
{% data reusables.github-actions.permissions-statement-environment %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% data reusables.github-actions.sidebar-environment %}
|
||||
1. Click **New environment**.
|
||||
1. Enter a name for the environment, then click **Configure environment**. Environment names are not case sensitive. An environment name may not exceed 255 characters and must be unique within the repository.
|
||||
1. Configure any environment protection rules or environment secrets.
|
||||
|
||||
Running a workflow that references an environment that does not exist will create an environment with the referenced name. The newly created environment will not have any protection rules or secrets configured. Anyone that can edit workflows in the repository can create environments via a workflow file, but only repository admins can configure the environment.
|
||||
|
||||
### Referencing an environment
|
||||
|
||||
Each job in a workflow can reference a single environment. Any protection rules configured for the environment must pass before a job referencing the environment is sent to a runner. When the job is sent to the runner, the job can access the environment's secrets.
|
||||
|
||||
For more information on syntax to reference environments in workflows, see "[Workflow syntax for GitHub Actions](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idenvironment)." For more information on reviewing jobs that reference an environment with required reviewers, see "[Reviewing deployments](/actions/managing-workflow-runs/reviewing-deployments)."
|
||||
|
||||
When a workflow references an environment, the environment will appear in the repository's deployments. For more information about viewing current and previous deployments, see "[Viewing deployment history](/developers/overview/viewing-deployment-history)."
|
||||
|
||||
### Deleting an environment
|
||||
|
||||
{% data reusables.github-actions.permissions-statement-environment %}
|
||||
|
||||
Deleting an environment will delete all secrets and protection rules associated with the environment. Any jobs currently waiting because of protection rules from the deleted environment will automatically fail.
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% data reusables.github-actions.sidebar-environment %}
|
||||
1. Next the the environment that you want to delete, click {% octicon "trashcan" aria-label="The trashcan icon" %}.
|
||||
2. Click **I understand, delete this environment**.
|
||||
|
|
@ -139,7 +139,7 @@ jobs:
|
|||
|
||||
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
|
||||
| ------------------ | ------------ | ------------ | ------------------|
|
||||
| [repository_dispatch](/webhooks/event-payloads/#repository_dispatch) | n/a | Last commit on the `GITHUB_REF` branch | Branch that received dispatch |
|
||||
| [repository_dispatch](/webhooks/event-payloads/#repository_dispatch) | n/a | Last commit on default branch | Default branch |
|
||||
|
||||
{% data reusables.github-actions.branch-requirement %}
|
||||
|
||||
|
|
@ -530,6 +530,12 @@ on:
|
|||
types: [assigned, opened, synchronize, reopened]
|
||||
```
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** In order to protect public repositories from malicious users, all pull request workflows raised from repository forks run with a read-only token and no access to secrets.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{% data reusables.developer-site.pull_request_forked_repos_link %}
|
||||
|
||||
#### `pull_request_review`
|
||||
|
|
@ -576,7 +582,19 @@ on:
|
|||
|
||||
#### `pull_request_target`
|
||||
|
||||
This event is similar to `pull_request`, except that it runs in the context of the base repository of the pull request, rather than in the merge commit. This means that you can more safely make your secrets available to the workflows triggered by the pull request, because only workflows defined in the commit on the base repository are run. For example, this event allows you to create workflows that label and comment on pull requests, based on the contents of the event payload.
|
||||
{% warning %}
|
||||
|
||||
**Warning:** The `pull_request_target` event is granted a read/write repository token and access to secrets, even from a fork. (The `pull_request` event does not grant read/write or secret access from a repository fork.) Do not check out and build or run untrusted code from pull request with this event.
|
||||
|
||||
{% endwarning %}
|
||||
|
||||
This event runs in the context of the base repository of the pull request, rather than in the merge commit as `pull_request` does. This is by design to prevent you from executing unsafe code that could alter your repository or steal any secrets you use in your workflow. For example, this event allows you to create workflows that label and comment on pull requests, based on the contents of the event payload.
|
||||
|
||||
{% warning %}
|
||||
|
||||
**Warning**: When using the `pull_request_target` event, be aware that it runs in the context of the base repository. This means that the `GITHUB_TOKEN` has write access to the repository, and the cache shares the same scope as the base branch. As a result, do not run untrusted code in the same context, as there is a risk that it may access sensitive information and unexpectedly manipulate the workflow environment. In addition, to help prevent cache poisoning, do not save the cache if there is a possibility that the cache contents were altered.
|
||||
|
||||
{% endwarning %}
|
||||
|
||||
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
|
||||
| --------------------- | -------------- | ------------ | -------------|
|
||||
|
|
@ -699,6 +717,8 @@ on:
|
|||
|
||||
{% data reusables.webhooks.workflow_run_desc %}
|
||||
|
||||
{% data reusables.github-actions.branch-requirement %}
|
||||
|
||||
| Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
|
||||
| --------------------- | -------------- | ------------ | -------------|
|
||||
| [`workflow_run`](/webhooks/event-payloads/#workflow_run) | - n/a | Last commit on default branch | Default branch |
|
||||
|
|
@ -723,4 +743,4 @@ on:
|
|||
|
||||
{% data reusables.github-actions.actions-do-not-trigger-workflows %} For more information, see "[Authenticating with the GITHUB_TOKEN](/actions/configuring-and-managing-workflows/authenticating-with-the-github_token)."
|
||||
|
||||
If you would like to trigger a workflow from a workflow run, you can trigger the event using a personal access token. You'll need to create a personal access token and store it as a secret. To minimize your {% data variables.product.prodname_actions %} usage costs, ensure that you don't create recursive or unintended workflow runs. For more information, see "[Creating and storing encrypted secrets](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)."
|
||||
If you would like to trigger a workflow from a workflow run, you can trigger the event using a personal access token. You'll need to create a personal access token and store it as a secret. To minimize your {% data variables.product.prodname_actions %} usage costs, ensure that you don't create recursive or unintended workflow runs. For more information on storing a personal access token as a secret, see "[Creating and storing encrypted secrets](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)."
|
||||
|
|
|
|||
|
|
@ -27,11 +27,19 @@ You can configure workflows to run when specific GitHub events occur, at a sched
|
|||
|
||||
### Authentication and secrets
|
||||
|
||||
{% data variables.product.prodname_dotcom %} provides a token that you can use to authenticate on behalf of {% data variables.product.prodname_actions %}. You can also store sensitive information as a secret in your organization or repository. {% data variables.product.prodname_dotcom %} encrypts all secrets.
|
||||
{% data variables.product.prodname_dotcom %} provides a token that you can use to authenticate on behalf of {% data variables.product.prodname_actions %}. You can also store sensitive information as a secret in your organization{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}, repository, or environments{% else %} or repository{% endif %}. {% data variables.product.prodname_dotcom %} encrypts all secrets.
|
||||
|
||||
{% link_in_list /authentication-in-a-workflow %}
|
||||
{% link_in_list /encrypted-secrets %}
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
|
||||
### Environments
|
||||
|
||||
Workflow jobs can reference environments that have protection rules or environment-specific secrets.
|
||||
|
||||
{% link_in_list /environments %}
|
||||
{% endif %}
|
||||
|
||||
### {% data variables.product.prodname_dotcom %}-hosted runners
|
||||
|
||||
GitHub offers hosted virtual machines to run workflows. The virtual machine contains an environment with tools, packages, and environment variables for GitHub Actions to use.
|
||||
|
|
|
|||
|
|
@ -187,7 +187,7 @@ For more information about cron syntax, see "[Events that trigger workflows](/ac
|
|||
|
||||
### `env`
|
||||
|
||||
A `map` of environment variables that are available to all jobs and steps in the workflow. You can also set environment variables that are only available to a job or step. For more information, see [`jobs.<job_id>.env`](#jobsjob_idenv) and [`jobs.<job_id>.steps.env`](#jobsjob_idstepsenv).
|
||||
A `map` of environment variables that are available to all jobs and steps in the workflow. You can also set environment variables that are only available to a job or step. For more information, see [`jobs.<job_id>.env`](#jobsjob_idenv) and [`jobs.<job_id>.steps[*].env`](#jobsjob_idstepsenv).
|
||||
|
||||
{% data reusables.repositories.actions-env-var-note %}
|
||||
|
||||
|
|
@ -223,7 +223,7 @@ defaults:
|
|||
|
||||
A workflow run is made up of one or more jobs. Jobs run in parallel by default. To run jobs sequentially, you can define dependencies on other jobs using the `jobs.<job_id>.needs` keyword.
|
||||
|
||||
Each job runs in an environment specified by `runs-on`.
|
||||
Each job runs in a runner environment specified by `runs-on`.
|
||||
|
||||
You can run an unlimited number of jobs as long as you are within the workflow usage limits. For more information, see "[Usage limits and billing](/actions/reference/usage-limits-billing-and-administration)" for {% data variables.product.prodname_dotcom %}-hosted runners and "[About self-hosted runners](/actions/hosting-your-own-runners/about-self-hosted-runners/#usage-limits)" for self-hosted runner usage limits.
|
||||
|
||||
|
|
@ -249,9 +249,9 @@ The name of the job displayed on {% data variables.product.prodname_dotcom %}.
|
|||
|
||||
### `jobs.<job_id>.needs`
|
||||
|
||||
Identifies any jobs that must complete successfully before this job will run. It can be a string or array of strings. If a job fails, all jobs that need it are skipped unless the jobs use a conditional statement that causes the job to continue.
|
||||
Identifies any jobs that must complete successfully before this job will run. It can be a string or array of strings. If a job fails, all jobs that need it are skipped unless the jobs use a conditional expression that causes the job to continue.
|
||||
|
||||
#### Example
|
||||
#### Example requiring dependent jobs to be successful
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
|
|
@ -270,6 +270,20 @@ The jobs in this example run sequentially:
|
|||
2. `job2`
|
||||
3. `job3`
|
||||
|
||||
#### Example not requiring dependent jobs to be successful
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
job1:
|
||||
job2:
|
||||
needs: job1
|
||||
job3:
|
||||
if: always()
|
||||
needs: [job1, job2]
|
||||
```
|
||||
|
||||
In this example, `job3` uses the `always()` conditional expression so that it always runs after `job1` and `job2` have completed, regardless of whether they were successful. For more information, see "[Context and expression syntax](/actions/reference/context-and-expression-syntax-for-github-actions#job-status-check-functions)."
|
||||
|
||||
### `jobs.<job_id>.runs-on`
|
||||
|
||||
**Required** The type of machine to run the job on. The machine can be either a {% data variables.product.prodname_dotcom %}-hosted runner or a self-hosted runner.
|
||||
|
|
@ -306,6 +320,39 @@ runs-on: [self-hosted, linux]
|
|||
|
||||
For more information, see "[About self-hosted runners](/github/automating-your-workflow-with-github-actions/about-self-hosted-runners)" and "[Using self-hosted runners in a workflow](/github/automating-your-workflow-with-github-actions/using-self-hosted-runners-in-a-workflow)."
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
|
||||
### `jobs.<job_id>.environment`
|
||||
|
||||
The environment that the job references. All environment protection rules must pass before a job referencing the environment is sent to a runner. For more information, see "[Environments](/actions/reference/environments)."
|
||||
|
||||
You can provide the environment as only the environment `name`, or as an environment object with the `name` and `url`. The URL maps to `environment_url` in the deployments API. For more information about the deployments API, see "[Deployments](/rest/reference/repos#deployments)."
|
||||
|
||||
##### Example using a single environment name
|
||||
|
||||
```yaml
|
||||
environment: staging_environment
|
||||
```
|
||||
|
||||
##### Example using environment name and URL
|
||||
|
||||
```yaml
|
||||
environment:
|
||||
name: production_environment
|
||||
url: https://github.com
|
||||
```
|
||||
|
||||
The URL can be an expression and can use any context except for the `secrets` context. For more information about expressions, see "[Context and expression syntax for {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)."
|
||||
|
||||
#### Example
|
||||
{% raw %}
|
||||
```yaml
|
||||
environment:
|
||||
name: production_environment
|
||||
url: ${{ steps.step_name.outputs.url_output }}
|
||||
```
|
||||
{% endraw %}
|
||||
{% endif %}
|
||||
|
||||
### `jobs.<job_id>.outputs`
|
||||
|
||||
A `map` of outputs for a job. Job outputs are available to all downstream jobs that depend on this job. For more information on defining job dependencies, see [`jobs.<job_id>.needs`](#jobsjob_idneeds).
|
||||
|
|
@ -340,7 +387,7 @@ jobs:
|
|||
|
||||
### `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 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).
|
||||
|
||||
{% data reusables.repositories.actions-env-var-note %}
|
||||
|
||||
|
|
@ -415,11 +462,11 @@ jobs:
|
|||
```
|
||||
{% endraw %}
|
||||
|
||||
### `jobs.<job_id>.steps.id`
|
||||
### `jobs.<job_id>.steps[*].id`
|
||||
|
||||
A unique identifier for the step. You can use the `id` to reference the step in contexts. For more information, see "[Context and expression syntax for {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)."
|
||||
|
||||
### `jobs.<job_id>.steps.if`
|
||||
### `jobs.<job_id>.steps[*].if`
|
||||
|
||||
You can use the `if` conditional to prevent a step from running unless a condition is met. You can use any supported context and expression to create a conditional.
|
||||
|
||||
|
|
@ -449,11 +496,11 @@ steps:
|
|||
uses: actions/heroku@1.0.0
|
||||
```
|
||||
|
||||
### `jobs.<job_id>.steps.name`
|
||||
### `jobs.<job_id>.steps[*].name`
|
||||
|
||||
A name for your step to display on {% data variables.product.prodname_dotcom %}.
|
||||
|
||||
### `jobs.<job_id>.steps.uses`
|
||||
### `jobs.<job_id>.steps[*].uses`
|
||||
|
||||
Selects an action to run as part of a step in your job. An action is a reusable unit of code. You can use an action defined in the same repository as the workflow, a public repository, or in a [published Docker container image](https://hub.docker.com/).
|
||||
|
||||
|
|
@ -556,7 +603,7 @@ jobs:
|
|||
uses: docker://gcr.io/cloud-builders/gradle
|
||||
```
|
||||
|
||||
### `jobs.<job_id>.steps.run`
|
||||
### `jobs.<job_id>.steps[*].run`
|
||||
|
||||
Runs command-line programs using the operating system's shell. If you do not provide a `name`, the step name will default to the text specified in the `run` command.
|
||||
|
||||
|
|
@ -661,7 +708,7 @@ For built-in shell keywords, we provide the following defaults that are executed
|
|||
- There doesn't seem to be a way to fully opt into fail-fast behavior other than writing your script to check each error code and respond accordingly. Because we can't actually provide that behavior by default, you need to write this behavior into your script.
|
||||
- `cmd.exe` will exit with the error level of the last program it executed, and it will return the error code to the runner. This behavior is internally consistent with the previous `sh` and `pwsh` default behavior and is the `cmd.exe` default, so this behavior remains intact.
|
||||
|
||||
### `jobs.<job_id>.steps.with`
|
||||
### `jobs.<job_id>.steps[*].with`
|
||||
|
||||
A `map` of the input parameters defined by the action. Each input parameter is a key/value pair. Input parameters are set as environment variables. The variable is prefixed with `INPUT_` and converted to upper case.
|
||||
|
||||
|
|
@ -681,7 +728,7 @@ jobs:
|
|||
last_name: Octocat
|
||||
```
|
||||
|
||||
### `jobs.<job_id>.steps.with.args`
|
||||
### `jobs.<job_id>.steps[*].with.args`
|
||||
|
||||
A `string` that defines the inputs for a Docker container. {% data variables.product.prodname_dotcom %} passes the `args` to the container's `ENTRYPOINT` when the container starts up. An `array of strings` is not supported by this parameter.
|
||||
|
||||
|
|
@ -704,7 +751,7 @@ The `args` are used in place of the `CMD` instruction in a `Dockerfile`. If you
|
|||
1. Use defaults that allow using the action without specifying any `args`.
|
||||
1. If the action exposes a `--help` flag, or something similar, use that as the default to make your action self-documenting.
|
||||
|
||||
### `jobs.<job_id>.steps.with.entrypoint`
|
||||
### `jobs.<job_id>.steps[*].with.entrypoint`
|
||||
|
||||
Overrides the Docker `ENTRYPOINT` in the `Dockerfile`, or sets it if one wasn't already specified. Unlike the Docker `ENTRYPOINT` instruction which has a shell and exec form, `entrypoint` keyword accepts only a single string defining the executable to be run.
|
||||
|
||||
|
|
@ -720,7 +767,7 @@ steps:
|
|||
|
||||
The `entrypoint` keyword is meant to be used with Docker container actions, but you can also use it with JavaScript actions that don't define any inputs.
|
||||
|
||||
### `jobs.<job_id>.steps.env`
|
||||
### `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).
|
||||
|
||||
|
|
@ -741,11 +788,11 @@ steps:
|
|||
```
|
||||
{% endraw %}
|
||||
|
||||
### `jobs.<job_id>.steps.continue-on-error`
|
||||
### `jobs.<job_id>.steps[*].continue-on-error`
|
||||
|
||||
Prevents a job from failing when a step fails. Set to `true` to allow a job to pass when this step fails.
|
||||
|
||||
### `jobs.<job_id>.steps.timeout-minutes`
|
||||
### `jobs.<job_id>.steps[*].timeout-minutes`
|
||||
|
||||
The maximum number of minutes to run the step before killing the process.
|
||||
|
||||
|
|
@ -755,7 +802,7 @@ The maximum number of minutes to let a job run before {% data variables.product.
|
|||
|
||||
### `jobs.<job_id>.strategy`
|
||||
|
||||
A strategy creates a build matrix for your jobs. You can define different variations of an environment to run each job in.
|
||||
A strategy creates a build matrix for your jobs. You can define different variations to run each job in.
|
||||
|
||||
### `jobs.<job_id>.strategy.matrix`
|
||||
|
||||
|
|
|
|||
|
|
@ -18,6 +18,7 @@ Notification emails are sent if there is activity on a repository a user is watc
|
|||
Your dedicated technical account manager in {% data variables.contact.github_support %} can configure email for notifications to be sent through your SMTP server. Make sure you include the following details in your support request.
|
||||
|
||||
- Your SMTP server address
|
||||
- Login information to authenticate to the server: username and password
|
||||
- The port your SMTP server uses to send email
|
||||
- The domain name that your SMTP server will send with a HELO response, if any
|
||||
- The type of encryption used by your SMTP server
|
||||
|
|
|
|||
|
|
@ -93,7 +93,7 @@ For urgent issues, we can help you in English 24 hours per day, 7 days per week,
|
|||
| Day after Thanksgiving | Fourth Friday in November |
|
||||
| Christmas Eve | December 24 |
|
||||
| Christmas Day | December 25 |
|
||||
| Day after Christmas | December 26 |
|
||||
| Day after Christmas | December 28 |
|
||||
| New Year's Eve | December 31 |
|
||||
|
||||
#### Holidays in Japan
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ We offer support for {% data variables.product.prodname_advanced_security %} in
|
|||
|
||||
{% data variables.contact.enterprise_support %} observes these U.S. holidays.
|
||||
|
||||
| U.S. holiday | Date observed in 2018 |
|
||||
| U.S. holiday | Date observed |
|
||||
| --- | --- |
|
||||
| New Year's Day | January 1 |
|
||||
| Martin Luther King, Jr. Day | Third Monday in January |
|
||||
|
|
@ -57,7 +57,7 @@ We offer support for {% data variables.product.prodname_advanced_security %} in
|
|||
| Day after Thanksgiving | Fourth Friday in November |
|
||||
| Christmas Eve | December 24 |
|
||||
| Christmas Day | December 25 |
|
||||
| Day after Christmas | December 26 |
|
||||
| Day after Christmas | December 28 |
|
||||
| New Year's Eve | December 31 |
|
||||
|
||||
### Installing {% data variables.product.prodname_advanced_security %} updates
|
||||
|
|
|
|||
|
|
@ -28,3 +28,5 @@ versions:
|
|||
{% link_with_intro /packages %}
|
||||
|
||||
{% link_with_intro /enterprise-support %}
|
||||
|
||||
{% link_with_intro /release-notes %}
|
||||
|
|
|
|||
|
|
@ -51,6 +51,7 @@ GitHub Desktop keyboard shortcuts on macOS
|
|||
|<kbd>⌘</kbd><kbd>2</kbd> | Show your commit history
|
||||
|<kbd>⌘</kbd><kbd>B</kbd> | Show all your branches
|
||||
|<kbd>⌘</kbd><kbd>G</kbd> | Go to the commit summary field
|
||||
|<kbd>⌘</kbd><kbd>Enter</kbd> | Commit changes when summary or description field is active
|
||||
|<kbd>space</kbd>| Select or deselect all highlighted files
|
||||
|<kbd>⇧</kbd><kbd>⌘</kbd><kbd>N</kbd> | Create a new branch
|
||||
|<kbd>⇧</kbd><kbd>⌘</kbd><kbd>R</kbd> | Rename the current branch
|
||||
|
|
@ -104,6 +105,7 @@ GitHub Desktop keyboard shortcuts on Windows
|
|||
|<kbd>Ctrl</kbd><kbd>2</kbd> | Show your commit history
|
||||
|<kbd>Ctrl</kbd><kbd>B</kbd> | Show all your branches
|
||||
|<kbd>Ctrl</kbd><kbd>G</kbd> | Go to the commit summary field
|
||||
|<kbd>Ctrl</kbd><kbd>Enter</kbd> | Commit changes when summary or description field is active
|
||||
|<kbd>space</kbd>| Select or deselect all highlighted files
|
||||
|<kbd>Ctrl</kbd><kbd>Shift</kbd><kbd>N</kbd> | Create a new branch
|
||||
|<kbd>Ctrl</kbd><kbd>Shift</kbd><kbd>R</kbd> | Rename the current branch
|
||||
|
|
|
|||
|
|
@ -272,7 +272,9 @@ The optional `redirect_uri` parameter can also be used for localhost URLs. If th
|
|||
|
||||
For the `http://localhost/path` callback URL, you can use this `redirect_uri`:
|
||||
|
||||
http://localhost:1234/path
|
||||
```
|
||||
http://localhost:1234/path
|
||||
```
|
||||
|
||||
### Creating multiple tokens for OAuth Apps
|
||||
|
||||
|
|
|
|||
|
|
@ -79,8 +79,8 @@ Permission | Description
|
|||
[`single_file`](/rest/reference/permissions-required-for-github-apps/#permission-on-single-file) | Grants access to the [Contents API](/rest/reference/repos#contents). Can be one of: `none`, `read`, or `write`.
|
||||
[`starring`](/rest/reference/permissions-required-for-github-apps/#permission-on-starring) | Grants access to the [Starring API](/rest/reference/activity#starring). Can be one of: `none`, `read`, or `write`.
|
||||
[`statuses`](/rest/reference/permissions-required-for-github-apps/#permission-on-statuses) | Grants access to the [Statuses API](/rest/reference/repos#statuses). Can be one of: `none`, `read`, or `write`.
|
||||
[`team_discussions`](/rest/reference/permissions-required-for-github-apps/#permission-on-team-discussions) | Grants access to the [Team Discussions API](/rest/reference/teams#discussions) and the [Team Discussion Comments API](/rest/reference/teams#discussion-comments). Can be one of: `none`, `read`, or `write`.
|
||||
`vulnerability_alerts`| Grants access to receive security alerts for vulnerable dependencies in a repository. See "[About security alerts for vulnerable dependencies](/articles/about-security-alerts-for-vulnerable-dependencies)" to learn more. Can be one of: `none` or `read`.
|
||||
[`team_discussions`](/rest/reference/permissions-required-for-github-apps/#permission-on-team-discussions) | Grants access to the [Team Discussions API](/rest/reference/teams#discussions) and the [Team Discussion Comments API](/rest/reference/teams#discussion-comments). Can be one of: `none`, `read`, or `write`.{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@1.19" %}
|
||||
`vulnerability_alerts`| Grants access to receive security alerts for vulnerable dependencies in a repository. See "[About security alerts for vulnerable dependencies](/articles/about-security-alerts-for-vulnerable-dependencies)" to learn more. Can be one of: `none` or `read`.{% endif %}
|
||||
`watching` | Grants access to list and change repositories a user is subscribed to. Can be one of: `none`, `read`, or `write`.
|
||||
|
||||
### {% data variables.product.prodname_github_app %} webhook events
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ If the user accepts your request, GitHub redirects back to your site with a temp
|
|||
|
||||
{% endnote %}
|
||||
|
||||
Exchange this `code` for an access token. {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.21" or currentVersion == "github-ae@latest" %} When expiring tokens are enabled, the access token expires in 8 hours and the refresh token expires in 6 months. Every time you refresh the token, you get a new refresh token. For more information, see "[Refreshing user-to-server access tokens](/developers/apps/refreshing-user-to-server-access-tokens)."
|
||||
Exchange this `code` for an access token. {% if currentVersion == "free-pro-team@latest" %} When expiring tokens are enabled, the access token expires in 8 hours and the refresh token expires in 6 months. Every time you refresh the token, you get a new refresh token. For more information, see "[Refreshing user-to-server access tokens](/developers/apps/refreshing-user-to-server-access-tokens)."
|
||||
|
||||
Expiring user tokens are currently part of the user-to-server token expiration beta and subject to change. To opt-in to the user-to-server token expiration beta feature, see "[Activating beta features for apps](/developers/apps/activating-beta-features-for-apps)."{% endif %}
|
||||
|
||||
|
|
|
|||
|
|
@ -7,13 +7,11 @@ versions:
|
|||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.21" %}
|
||||
{% note %}
|
||||
|
||||
**Note:** {% data reusables.pre-release-program.suspend-installation-beta %}
|
||||
|
||||
{% endnote %}
|
||||
{% endif %}
|
||||
|
||||
### Suspending a GitHub App
|
||||
|
||||
|
|
|
|||
|
|
@ -166,7 +166,7 @@ To create a Probot App, follow these steps:
|
|||
}
|
||||
```
|
||||
|
||||
4. [Run the GitHub App locally](https://probot.github.io/docs/development/#running-the-app-locally). Navigate to [localhost:3000](http://localhost:3000), and click the **Register GitHub App** button:
|
||||
4. [Run the GitHub App locally](https://probot.github.io/docs/development/#running-the-app-locally). Navigate to `http://localhost:3000`, and click the **Register GitHub App** button:
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ Customers can start a free trial for any paid plan on a Marketplace listing that
|
|||
|
||||
Free trials have a fixed length of 14 days. Customers are notified 4 days before the end of their trial period (on day 11 of the free trial) that their plan will be upgraded. At the end of a free trial, customers will be auto-enrolled into the plan they are trialing if they do not cancel.
|
||||
|
||||
For more information, see: "[Handling new purchases and free trials](/developers/github-marketplace/integrating-with-the-github-marketplace-api/handling-new-purchases-and-free-trials/)."
|
||||
For more information, see: "[Handling new purchases and free trials](/developers/github-marketplace/handling-new-purchases-and-free-trials/)."
|
||||
|
||||
{% note %}
|
||||
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ In addition to the requirements for all apps above, each app that you offer as a
|
|||
- {% data variables.product.prodname_github_app %}s should have a minimum of 100 installations.
|
||||
- {% data variables.product.prodname_oauth_app %}s should have a minimum of 200 users.
|
||||
- All paid apps must handle {% data variables.product.prodname_marketplace %} purchase events for new purchases, upgrades, downgrades, cancellations, and free trials. For more information, see "[Billing requirements for paid apps](#billing-requirements-for-paid-apps)" below.
|
||||
- Publishing organizations must have a verified domain and must enable two-factor authentication. For more information, see "[Requiring two-factor authentication in your organization](/github/setting-up-and-managing-organizations-and-teams/requiring-two-factor-authentication-in-your-organization.")
|
||||
- Publishing organizations must have a verified domain and must enable two-factor authentication. For more information, see "[Requiring two-factor authentication in your organization](/github/setting-up-and-managing-organizations-and-teams/requiring-two-factor-authentication-in-your-organization)."
|
||||
|
||||
When you are ready to publish the app on {% data variables.product.prodname_marketplace %} you must request verification for the listing.
|
||||
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@ versions:
|
|||
|
||||
{% link_in_list /about-githubs-apis %}
|
||||
{% link_in_list /managing-deploy-keys %}
|
||||
{% link_in_list /viewing-deployment-history %}
|
||||
{% link_in_list /using-ssh-agent-forwarding %}
|
||||
{% link_in_list /secret-scanning %}
|
||||
{% link_in_list /replacing-github-services %}
|
||||
|
|
|
|||
|
|
@ -44,7 +44,9 @@ If you don't want to use SSH keys, you can use [HTTPS with OAuth tokens][git-aut
|
|||
* Users don't have to change their local SSH settings.
|
||||
* Multiple tokens (one for each user) are not needed; one token per server is enough.
|
||||
* A token can be revoked at any time, turning it essentially into a one-use password.
|
||||
{% if enterpriseServerVersions contains currentVersion %}
|
||||
* Generating new tokens can be easily scripted using [the OAuth API](/rest/reference/oauth-authorizations#create-a-new-authorization).
|
||||
{% endif %}
|
||||
|
||||
##### Cons
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
title: Viewing deployment history
|
||||
intro: View current and previous deployments for your repository.
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
github-ae: '*'
|
||||
---
|
||||
|
||||
{% data reusables.actions.environments-beta %}
|
||||
|
||||
You can deliver deployments through {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}{% data variables.product.prodname_actions %} and environments or with {% endif %}the REST API and third party apps. {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}For more information about {% data variables.product.prodname_actions %}, see "[{% data variables.product.prodname_actions %}](/actions)." {% endif %}For more information about deployments with the REST API, see "[Repositories](/rest/reference/repos#deployments)."
|
||||
|
||||
To view current and past deployments, click **Environments** on the home page of your repository. 
|
||||
|
||||
The deployments page displays the last active deployment of each environment for your repository. If the deployment includes an environment URL, a "View deployment" button that links to the URL is shown next to the deployment.
|
||||
|
||||
The activity log shows the deployment history for your environments. By default, only the most recent deployment for an environment has an `Active` status; all previously active deployments have an `Inactive` status. For more information on automatic inactivation of deployments, see "[Inactive deployments](/rest/reference/repos#inactive-deployments)."
|
||||
|
||||
You can also use the REST API to get information about deployments. For more information, see "[Repositories](/rest/reference/repos#deployments)."
|
||||
|
|
@ -91,7 +91,7 @@ The base reference branch of the pull request changed.
|
|||
|:----------|:----------------:|:-----------------:|
|
||||
| <ul><li>Pull requests</li></ul> | **X** | |
|
||||
|
||||
### Event object properties
|
||||
#### Event object properties
|
||||
|
||||
{% data reusables.issue-events.issue-event-common-properties %}
|
||||
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ end
|
|||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" or currentVersion == "github-ae@latest" %}
|
||||
def verify_signature(payload_body)
|
||||
signature = 'sha256=' + OpenSSL::HMAC.hexdigest(OpenSSL::Digest.new('sha256'), ENV['SECRET_TOKEN'], payload_body)
|
||||
return halt 500, "Signatures didn't match!" unless Rack::Utils.secure_compare(signature, request.env['HTTP_X_HUB_SIGNATURE_2'])
|
||||
return halt 500, "Signatures didn't match!" unless Rack::Utils.secure_compare(signature, request.env['HTTP_X_HUB_SIGNATURE_256'])
|
||||
end{% elsif currentVersion ver_lt "enterprise-server@2.23" %}
|
||||
def verify_signature(payload_body)
|
||||
signature = 'sha1=' + OpenSSL::HMAC.hexdigest(OpenSSL::Digest.new('sha1'), ENV['SECRET_TOKEN'], payload_body)
|
||||
|
|
|
|||
|
|
@ -430,7 +430,7 @@ Key | Type | Description
|
|||
|
||||
{% endnote %}
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.21" or currentVersion == "github-ae@latest" %}
|
||||
{% if currentVersion == "free-pro-team@latest" %}
|
||||
{% note %}
|
||||
|
||||
**Note:** {% data reusables.pre-release-program.suspend-installation-beta %} For more information, see "[Suspending a {% data variables.product.prodname_github_app %} installation](/apps/managing-github-apps/suspending-a-github-app-installation/)."
|
||||
|
|
@ -445,7 +445,7 @@ Key | Type | Description
|
|||
#### Webhook payload object
|
||||
|
||||
{% data reusables.webhooks.installation_properties %}
|
||||
{% data reusables.webhooks.app_desc %}
|
||||
{% data reusables.webhooks.app_always_desc %}
|
||||
{% data reusables.webhooks.sender_desc %}
|
||||
|
||||
#### Webhook payload example
|
||||
|
|
@ -469,7 +469,7 @@ Key | Type | Description
|
|||
#### Webhook payload object
|
||||
|
||||
{% data reusables.webhooks.installation_repositories_properties %}
|
||||
{% data reusables.webhooks.app_desc %}
|
||||
{% data reusables.webhooks.app_always_desc %}
|
||||
{% data reusables.webhooks.sender_desc %}
|
||||
|
||||
#### Webhook payload example
|
||||
|
|
@ -715,7 +715,7 @@ Key | Type | Description
|
|||
|
||||
### package
|
||||
|
||||
Activity related to {% data variables.product.prodname_registry %}. {% data reusables.webhooks.action_type_desc %} For more information, see the "[blocking organization users](/rest/reference/orgs#blocking)" REST API. For more information, see "[Managing packages with {% data variables.product.prodname_registry %}](/github/managing-packages-with-github-packages)" to learn more about {% data variables.product.prodname_registry %}.
|
||||
Activity related to {% data variables.product.prodname_registry %}. {% data reusables.webhooks.action_type_desc %} For more information, see "[Managing packages with {% data variables.product.prodname_registry %}](/github/managing-packages-with-github-packages)" to learn more about {% data variables.product.prodname_registry %}.
|
||||
|
||||
#### Availability
|
||||
|
||||
|
|
@ -1124,9 +1124,11 @@ Key | Type | Description
|
|||
{{ webhookPayloadsForCurrentVersion.secret_scanning_alert.reopened }}
|
||||
{% endif %}
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@1.19" %}
|
||||
### security_advisory
|
||||
|
||||
Activity related to a security advisory. A security advisory provides information about security-related vulnerabilities in software on GitHub. The security advisory dataset also powers the GitHub security alerts, see "[About security alerts for vulnerable dependencies](/articles/about-security-alerts-for-vulnerable-dependencies/)."
|
||||
{% endif %}
|
||||
|
||||
#### Availability
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ versions:
|
|||
### Finding discussions
|
||||
|
||||
1. Navigate to {% data variables.product.prodname_dotcom_the_website %}.
|
||||
1. In the top-right corner of {% data variables.product.prodname_dotcom_the_website %}, click your profile photo, then click **Your enterprises**.
|
||||
1. In the top-right corner of {% data variables.product.prodname_dotcom_the_website %}, click your profile photo, then click **Your discussions**.
|
||||
|
||||
1. Toggle between **Created** and **Commented** to see the discussions you've created or participated in.
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ To be eligible for the {% data variables.product.prodname_student_pack %}, you m
|
|||
- Have a [{% data variables.product.prodname_dotcom %} user account](/articles/signing-up-for-a-new-github-account)
|
||||
- Be at least 13 years old
|
||||
|
||||
Documents that prove your current student status include a picture of your school ID, class schedule, transcript, and affiliation or enrollment verification letter.
|
||||
Documents that prove your current student status include a picture of your school ID with current enrollment date, class schedule, transcript, and affiliation or enrollment verification letter.
|
||||
|
||||
During your tenure as a student, you may be prompted to periodically re-verify your current academic status.
|
||||
|
||||
|
|
|
|||
|
|
@ -11,12 +11,16 @@ versions:
|
|||
github-ae: '*'
|
||||
---
|
||||
|
||||
### About protected branches
|
||||
|
||||
{% data reusables.pull_requests.about-protected-branches %} You can choose to enforce restrictions on how a pull request is merged into your repository.
|
||||
|
||||
Repository owners and people with admin permissions for a repository can enforce certain workflows or requirements, before a collaborator can merge a branch in your repository by creating protected branch rules.
|
||||
|
||||
{% data reusables.repositories.branch-rules-example %} For more information, see "[Configuring protected branches](/articles/configuring-protected-branches/)."
|
||||
|
||||
{% data reusables.pull_requests.you-can-auto-merge %}
|
||||
|
||||
### Prioritization of protected branch rules
|
||||
|
||||
If a repository has multiple protected branch rules that affect the same branches, the rules that include a specific branch name have the highest priority. If there is more than one protected branch rule that references the same specific branch name, then the branch rule created first will have higher priority.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Configuring pull request merges
|
||||
intro: 'You can configure pull request merges on {% data variables.product.product_location %} to match your workflow and preferences for managing Git history by enabling, disabling, or enforcing standard merge commits, squashed commits, or rebased commits on all pull requests in your repository.'
|
||||
intro: 'You can configure pull request merges on {% data variables.product.product_location %} to match your workflow and preferences for managing Git history.'
|
||||
mapTopic: true
|
||||
redirect_from:
|
||||
- /articles/configuring-pull-request-merges
|
||||
|
|
|
|||
|
|
@ -39,6 +39,7 @@ versions:
|
|||
{% link_in_list /about-merge-methods-on-github %}
|
||||
{% link_in_list /configuring-commit-squashing-for-pull-requests %}
|
||||
{% link_in_list /configuring-commit-rebasing-for-pull-requests %}
|
||||
{% link_in_list /managing-auto-merge-for-pull-requests-in-your-repository %}
|
||||
{% link_in_list /managing-the-automatic-deletion-of-branches %}
|
||||
{% topic_link_in_list /defining-the-mergeability-of-pull-requests %}
|
||||
{% link_in_list /about-protected-branches %}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
title: Managing auto-merge for pull requests in your repository
|
||||
intro: "You can allow or disallow auto-merge for pull requests in your repository."
|
||||
product: '{% data reusables.gated-features.auto-merge %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
permissions: People with maintainer permissions can manage auto-merge for pull requests in a repository.
|
||||
---
|
||||
|
||||
{% data reusables.pull_requests.auto-merge-release-phase %}
|
||||
|
||||
If you allow auto-merge for pull requests in your repository, people can configure individual pull requests in the repository to merge automatically when all merge requirements are met. For more information, see "[Automatically merging a pull request](/github/collaborating-with-issues-and-pull-requests/automatically-merging-a-pull-request)."
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
1. Under "Merge button", select or deselect **Allow auto-merge**.
|
||||
|
||||
|
|
@ -40,6 +40,12 @@ To replace all text listed in `passwords.txt` wherever it can be found in your r
|
|||
$ bfg --replace-text passwords.txt
|
||||
```
|
||||
|
||||
After the sensitive data is removed, you must force push your changes to {% data variables.product.product_name %}.
|
||||
|
||||
```shell
|
||||
$ git push --force
|
||||
```
|
||||
|
||||
See the [BFG Repo-Cleaner](http://rtyley.github.io/bfg-repo-cleaner/)'s documentation for full usage and download instructions.
|
||||
|
||||
#### Using filter-branch
|
||||
|
|
|
|||
|
|
@ -0,0 +1,43 @@
|
|||
---
|
||||
title: Automatically merging a pull request
|
||||
intro: 'You can increase development velocity by enabling auto-merge for a pull request so that the pull request will merge automatically when all merge requirements are met.'
|
||||
product: '{% data reusables.gated-features.auto-merge %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
{% data reusables.pull_requests.auto-merge-release-phase %}
|
||||
|
||||
### About auto-merge
|
||||
|
||||
If you enable auto-merge for a pull request, the pull request will merge automatically when all required reviews are met and status checks have passed. Auto-merge prevents you from waiting around for requirements to be met, so you can move on to other tasks.
|
||||
|
||||
Before you can use auto-merge with a pull request, auto-merge must be enabled for the repository. For more information, see "[Managing auto-merge for pull requests in your repository](/github/administering-a-repository/managing-auto-merge-for-pull-requests-in-your-repository)."
|
||||
|
||||
You can provide feedback about auto-merge by [contacting us](https://support.github.com/contact/feedback?category=prs-and-code-review&subject=Pull%20request%20auto-merge%20feedback).
|
||||
|
||||
### Enabling auto-merge
|
||||
|
||||
People with write permissions to a repository can enable auto-merge for a pull request.
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-pr %}
|
||||
1. In the "Pull Requests" list, click the pull request you'd like to auto-merge.
|
||||
1. Optionally, to choose a merge method, select the **Enable auto-merge** drop-down menu, then click a merge method. For more information, see "[About pull request merges](/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges)."
|
||||
|
||||
1. Click **Enable auto-merge**.
|
||||
|
||||
1. If you chose the merge or squash and merge methods, type a commit message and description and choose the email address you want to author the merge commit.
|
||||
|
||||
1. Click **Confirm auto-merge**.
|
||||
|
||||
|
||||
### Disabling auto-merge
|
||||
|
||||
People with write permissions to a repository and pull request authors can disable auto-merge for a pull request.
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-pr %}
|
||||
1. In the "Pull Requests" list, click the pull request you'd like to disable auto-merge for.
|
||||
1. In the merge box, click **Disable auto-merge**.
|
||||
|
||||
|
|
@ -60,5 +60,6 @@ versions:
|
|||
{% topic_link_in_list /incorporating-changes-from-a-pull-request %}
|
||||
{% link_in_list /about-pull-request-merges %}
|
||||
{% link_in_list /merging-a-pull-request %}
|
||||
{% link_in_list /automatically-merging-a-pull-request %}
|
||||
{% link_in_list /closing-a-pull-request %}
|
||||
{% link_in_list /reverting-a-pull-request %}
|
||||
|
|
|
|||
|
|
@ -14,6 +14,8 @@ versions:
|
|||
|
||||
In a pull request, you propose that changes you've made on a head branch should be merged into a base branch. {% data reusables.pull_requests.about-protected-branches %} However, there may be restrictions on when you can merge a pull request into a specific branch. For example, you may only be able to merge a pull request into the default branch if required status checks are passing. For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches)."
|
||||
|
||||
{% data reusables.pull_requests.you-can-auto-merge %}
|
||||
|
||||
If the pull request has merge conflicts, or if you'd like to test the changes before merging, you can [check out the pull request locally](/articles/checking-out-pull-requests-locally) and merge it using the command line.
|
||||
|
||||
You can't merge a draft pull request. For more information about draft pull requests, see "[About pull requests](/articles/about-pull-requests#draft-pull-requests)."
|
||||
|
|
|
|||
|
|
@ -39,9 +39,9 @@ For code owners to receive review requests, the CODEOWNERS file must be on the b
|
|||
|
||||
### CODEOWNERS syntax
|
||||
|
||||
A CODEOWNERS file uses a pattern that follows the same rules used in [gitignore](https://git-scm.com/docs/gitignore#_pattern_format) files. The pattern is followed by one or more {% data variables.product.prodname_dotcom %} usernames or team names using the standard `@username` or `@org/team-name` format. You can also refer to a user by an email address that has been added to their {% data variables.product.product_name %} account, for example `user@example.com`.
|
||||
A CODEOWNERS file uses a pattern that follows most of the same rules used in [gitignore](https://git-scm.com/docs/gitignore#_pattern_format) files, with [some exceptions](#syntax-exceptions). The pattern is followed by one or more {% data variables.product.prodname_dotcom %} usernames or team names using the standard `@username` or `@org/team-name` format. You can also refer to a user by an email address that has been added to their {% data variables.product.product_name %} account, for example `user@example.com`.
|
||||
|
||||
If any line in your CODEOWNERS file contains invalid syntax, the file will not be detected and will not be used to request reviews. Invalid syntax includes inline comments and user or team names that do not exist on {% data variables.product.product_name %}.
|
||||
If any line in your CODEOWNERS file contains invalid syntax, the file will not be detected and will not be used to request reviews.
|
||||
#### Example of a CODEOWNERS file
|
||||
```
|
||||
# This is a comment.
|
||||
|
|
@ -83,6 +83,13 @@ apps/ @octocat
|
|||
# subdirectories.
|
||||
/docs/ @doctocat
|
||||
```
|
||||
#### Syntax exceptions
|
||||
There are some syntax rules for gitignore files that do not work in CODEOWNERS files:
|
||||
- Escaping a pattern starting with `#` using `\` so it is treated as a pattern and not a comment
|
||||
- Using `!` to negate a pattern
|
||||
- Using `[ ]` to define a character range
|
||||
|
||||
|
||||
|
||||
### Further reading
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ versions:
|
|||
|
||||
{% data reusables.codespaces.about-configuration %}
|
||||
|
||||
If you don't define a configuration in your repository, {% data variables.product.prodname_dotcom %} creates a codespace with a base Linux image. The base Linux image includes tools for Node.js, JavaScript, TypeScript, Python, C++, Java, C#, .NET Core, PHP, and PowerShell. For more information about the base Linux image, see the [`microsoft/vscode-dev-containers`](https://github.com/microsoft/vscode-dev-containers/tree/master/containers/codespaces-linux) repository.
|
||||
If you don't define a configuration in your repository, {% data variables.product.prodname_dotcom %} creates a codespace with a base Linux image. The base Linux image includes tools for Python, Node.js, JavaScript, TypeScript, C++, Java, C#, F#, .NET Core, PHP, PowerShell, Go, Ruby, and Rust. For more information about the base Linux image, see the [`microsoft/vscode-dev-containers`](https://github.com/microsoft/vscode-dev-containers/tree/master/containers/codespaces-linux) repository.
|
||||
|
||||
{% data reusables.codespaces.about-personalization %} {% data reusables.codespaces.codespace-config-order %} For more information, see "[Personalizing {% data variables.product.prodname_codespaces %} for your account](/github/developing-online-with-codespaces/personalizing-codespaces-for-your-account)."
|
||||
|
||||
|
|
|
|||
|
|
@ -296,7 +296,7 @@ You can quickly analyze small portions of a monorepo when you modify code in spe
|
|||
|
||||
### Accessing private repositories
|
||||
|
||||
If your workflow for {% data variables.product.prodname_code_scanning %} accesses a private repository, other than the repository that contains the workflow, you'll need to configure Git to authenticate with a personal access token. Define the secret in the runner environment by using `jobs.<job_id>.steps.env` in your workflow before any {% data variables.product.prodname_codeql %} actions. For more information, see "[Creating a personal access token for the command line](/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line)" and "[Creating and storing encrypted secrets](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)."
|
||||
If your workflow for {% data variables.product.prodname_code_scanning %} accesses a private repository, other than the repository that contains the workflow, you'll need to configure Git to authenticate with a personal access token. Define the secret in the runner environment by using `jobs.<job_id>.steps[*].env` in your workflow before any {% data variables.product.prodname_codeql %} actions. For more information, see "[Creating a personal access token for the command line](/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line)" and "[Creating and storing encrypted secrets](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)."
|
||||
|
||||
For example, the following configuration has Git replace the full URLs to the `ghost/foo`, `ghost/bar`, and `ghost/baz` repositories on {% data variables.product.prodname_dotcom_the_website %} with URLs that include the personal access token that you store in the `ACCESS_TOKEN` environment variable.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,8 +10,8 @@ versions:
|
|||
---
|
||||
|
||||
{% for term in site.data.glossaries.external %}
|
||||
### {{term.term}}
|
||||
{{term.description}}
|
||||
### {% data glossaries.external[forloop.index0].term %}
|
||||
{% data glossaries.external[forloop.index0].description %}
|
||||
---
|
||||
{% endfor %}
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,9 @@ versions:
|
|||
|
||||
### About billing for {% data variables.product.prodname_actions %}
|
||||
|
||||
{% data reusables.github-actions.actions-billing %} {% data reusables.github-actions.actions-spending-limit %}
|
||||
{% data reusables.github-actions.actions-billing %}
|
||||
|
||||
{% data reusables.github-actions.actions-spending-limit-brief %} For more information, see "[About spending limits](#about-spending-limits)."
|
||||
|
||||
Minutes reset every month, while storage usage does not.
|
||||
|
||||
|
|
@ -69,8 +71,8 @@ Your {% data variables.product.prodname_actions %} usage shares your account's e
|
|||
|
||||
### About spending limits
|
||||
|
||||
By default, your account will have a spending limit of $0 for {% data variables.product.prodname_actions %} usage. To enable using minutes and storage for private repositories beyond the amounts included with your account, you can increase the spending limit or allow unlimited spending. For more information, see "[Managing your spending limit for {% data variables.product.prodname_actions %}](/github/setting-up-and-managing-billing-and-payments-on-github/managing-your-spending-limit-for-github-actions)."
|
||||
{% data reusables.github-actions.actions-spending-limit-detailed %}
|
||||
|
||||
{% data reusables.github-actions.spending-limit-enterprise-account %}
|
||||
For information on managing and changing your account's spending limit, see "[Managing your spending limit for {% data variables.product.prodname_actions %}](/github/setting-up-and-managing-billing-and-payments-on-github/managing-your-spending-limit-for-github-actions)."
|
||||
|
||||
{% data reusables.dotcom_billing.actions-packages-unpaid-account %}
|
||||
|
|
|
|||
|
|
@ -10,6 +10,8 @@ versions:
|
|||
|
||||
{% data reusables.package_registry.packages-billing %}
|
||||
|
||||
{% data reusables.package_registry.packages-spending-limit-brief %} For more information, see "[About spending limits](#about-spending-limits)."
|
||||
|
||||
{% data reusables.package_registry.container-registry-beta-billing-note %}
|
||||
|
||||
Data transfer resets every month, while storage usage does not.
|
||||
|
|
@ -50,8 +52,8 @@ Your {% data variables.product.prodname_registry %} usage shares your account's
|
|||
|
||||
### About spending limits
|
||||
|
||||
By default, your account will have a spending limit of $0 for {% data variables.product.prodname_registry %} usage. To enable storage and data transfer for private packages beyond the amounts included with your account, you can increase the spending limit or allow unlimited spending. For more information, see "[Managing your spending limit for {% data variables.product.prodname_registry %}](/github/setting-up-and-managing-billing-and-payments-on-github/managing-your-spending-limit-for-github-packages)."
|
||||
{% data reusables.package_registry.packages-spending-limit-detailed %}
|
||||
|
||||
{% data reusables.package_registry.spending-limit-enterprise-account %}
|
||||
For information on managing and changing your account's spending limit, see "[Managing your spending limit for {% data variables.product.prodname_registry %}](/github/setting-up-and-managing-billing-and-payments-on-github/managing-your-spending-limit-for-github-packages)."
|
||||
|
||||
{% data reusables.dotcom_billing.actions-packages-unpaid-account %}
|
||||
|
|
|
|||
|
|
@ -8,13 +8,15 @@ versions:
|
|||
|
||||
### About spending limits for {% data variables.product.prodname_actions %}
|
||||
|
||||
{% data reusables.github-actions.actions-billing %} {% data reusables.github-actions.actions-spending-limit %}
|
||||
{% data reusables.github-actions.actions-billing %}
|
||||
|
||||
You can set a higher spending limit or, for some accounts, allow unlimited spending. If you pay for your organization or enterprise account by invoice, you can prepay for overages to set a higher spending limit. The spending limit applies to your combined overages for {% data variables.product.prodname_actions %} and {% data variables.product.prodname_registry %}. For more information about pricing for {% data variables.product.prodname_actions %} usage, see "[About billing for {% data variables.product.prodname_actions %}](/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-actions)."
|
||||
{% data reusables.github-actions.actions-spending-limit-brief %}
|
||||
|
||||
As soon as you set a spending limit above $0, you will be responsible for any overages that occurred in the past. For example, if your organization uses {% data variables.product.prodname_team %}, does not allow overages, and creates workflow artifacts that increase your storage usage for the month from 1.9GB to 2.1GB, you will use slightly more storage than the 2GB your product includes.
|
||||
{% data reusables.actions.actions-packages-set-spending-limit %} For more information about pricing for {% data variables.product.prodname_actions %} usage, see "[About billing for {% data variables.product.prodname_actions %}](/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-actions)."
|
||||
|
||||
Because you have not enabled overages, your next attempt to publish a version of the package will fail. You will not receive a bill for the 0.1GB overage that month. However, if you enable overages in a future month, your first bill will include the 0.1GB of overage from the past in addition to any overages for the current billing cycle.
|
||||
As soon as you set a spending limit other than $0, you will be responsible for any existing overages in the current billing period. For example, if your organization uses {% data variables.product.prodname_team %}, does not allow overages, and creates workflow artifacts that increase your storage usage for the month from 1.9GB to 2.1GB, you will use slightly more storage than the 2GB your product includes.
|
||||
|
||||
Because you have not enabled overages, your next attempt to create a workflow artifact will fail. You will not receive a bill for the 0.1GB overage that month. However, if you enable overages, your first bill will include the 0.1GB of existing overage for the current billing cycle, as well as any additional overages you accrue.
|
||||
|
||||
### Managing the spending limit for {% data variables.product.prodname_actions %} for your user account
|
||||
|
||||
|
|
@ -30,8 +32,6 @@ Anyone can manage the spending limit for {% data variables.product.prodname_acti
|
|||
|
||||
Organizations owners and billing managers can manage the spending limit for {% data variables.product.prodname_actions %} for an organization.
|
||||
|
||||
If you pay for your organization account by invoice, you cannot manage the spending limit for your enterprise account on {% data variables.product.product_name %}. If you want to allow repositories owned by your organization to use {% data variables.product.prodname_actions %} beyond the storage or data transfer included for each repository, you can prepay for overages. Because overages must prepaid, you cannot enable unlimited spending on accounts paid by invoice. Your spending limit will be 150% of the amount you prepaid. If you have any questions, [contact our account management team](https://enterprise.github.com/contact).
|
||||
|
||||
{% data reusables.profile.access_profile %}
|
||||
{% data reusables.profile.access_org %}
|
||||
{% data reusables.organizations.org_settings %}
|
||||
|
|
@ -44,8 +44,6 @@ If you pay for your organization account by invoice, you cannot manage the spend
|
|||
|
||||
Enterprise owners and billing managers can manage the spending limit for {% data variables.product.prodname_actions %} for an enterprise account.
|
||||
|
||||
{% data reusables.github-actions.spending-limit-enterprise-account %}
|
||||
|
||||
{% data reusables.enterprise-accounts.access-enterprise %}
|
||||
{% data reusables.enterprise-accounts.settings-tab %}
|
||||
{% data reusables.enterprise-accounts.billing-tab %}
|
||||
|
|
|
|||
|
|
@ -10,11 +10,13 @@ versions:
|
|||
|
||||
{% data reusables.package_registry.packages-billing %}
|
||||
|
||||
You can set a higher spending limit or, for some accounts, allow unlimited spending. If you pay for your organization or enterprise account by invoice, you can prepay for overages to set a higher spending limit. The spending limit applies to your combined overages for {% data variables.product.prodname_registry %} and {% data variables.product.prodname_actions %}. For more information about pricing for {% data variables.product.prodname_registry %} usage, see "[About billing for {% data variables.product.prodname_registry %}](/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-packages)."
|
||||
{% data reusables.package_registry.packages-spending-limit-brief %}
|
||||
|
||||
As soon as you set a spending limit above $0, you will be responsible for any overages that occurred in the past. For example, if your organization uses {% data variables.product.prodname_team %}, does not allow overages, and publishes a new version of a private package that increases your storage usage for the month from 1.9GB to 2.1GB, publishing the version will use slightly more than the 2GB your product includes.
|
||||
{% data reusables.actions.actions-packages-set-spending-limit %} For more information about pricing for {% data variables.product.prodname_registry %} usage, see "[About billing for {% data variables.product.prodname_registry %}](/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-packages)."
|
||||
|
||||
Because you have not enabled overages, your next attempt to publish a version of the package will fail. You will not receive a bill for the 0.1GB overage that month. However, if you enable overages in a future month, your first bill will include the 0.1GB of overage from the past in addition to any overages for the current billing cycle.
|
||||
As soon as you set a spending limit other than $0, you will be responsible for any existing overages in the current billing period. For example, if your organization uses {% data variables.product.prodname_team %}, does not allow overages, and publishes a new version of a private package that increases your storage usage for the month from 1.9GB to 2.1GB, publishing the version will use slightly more than the 2GB your product includes.
|
||||
|
||||
Because you have not enabled overages, your next attempt to publish a version of the package will fail. You will not receive a bill for the 0.1GB overage that month. However, if you enable overages, your first bill will include the 0.1GB of existing overage for the current billing cycle, as well as any additional overages you accrue.
|
||||
|
||||
### Managing the spending limit for {% data variables.product.prodname_registry %} for your user account
|
||||
|
||||
|
|
@ -30,8 +32,6 @@ Anyone can manage the spending limit for {% data variables.product.prodname_regi
|
|||
|
||||
Organizations owners and billing managers can manage the spending limit for {% data variables.product.prodname_registry %} for an organization.
|
||||
|
||||
If you pay for your organization account by invoice, you cannot manage the spending limit for your enterprise account on {% data variables.product.product_name %}. If you want to allow repositories owned by your organization to use {% data variables.product.prodname_registry %} beyond the storage or data transfer included for each repository, you can prepay for overages. Because overages must prepaid, you cannot enable unlimited spending on accounts paid by invoice. Your spending limit will be 150% of the amount you prepaid. If you have any questions, [contact our account management team](https://enterprise.github.com/contact).
|
||||
|
||||
{% data reusables.profile.access_profile %}
|
||||
{% data reusables.profile.access_org %}
|
||||
{% data reusables.organizations.org_settings %}
|
||||
|
|
@ -44,8 +44,6 @@ If you pay for your organization account by invoice, you cannot manage the spend
|
|||
|
||||
Enterprise owners and billing managers can manage the spending limit for {% data variables.product.prodname_registry %} for an enterprise account.
|
||||
|
||||
{% data reusables.package_registry.spending-limit-enterprise-account %}
|
||||
|
||||
{% data reusables.enterprise-accounts.access-enterprise %}
|
||||
{% data reusables.enterprise-accounts.settings-tab %}
|
||||
{% data reusables.enterprise-accounts.billing-tab %}
|
||||
|
|
|
|||
|
|
@ -39,6 +39,7 @@ Organization members can have *owner*{% if currentVersion == "free-pro-team@late
|
|||
| Access the organization audit log | **X** | | |
|
||||
| Edit the organization's profile page (see "[About your organization's profile](/articles/about-your-organization-s-profile)" for details) | **X** | | |
|
||||
| Verify the organization's domains (see "[Verifying your organization's domain](/articles/verifying-your-organization-s-domain)" for details) | **X** | | |
|
||||
| Restrict email notifications to verified domains (see "[Restricting email notifications to an approved domain](/github/setting-up-and-managing-organizations-and-teams/restricting-email-notifications-to-an-approved-domain)" for details) | **X** | | |
|
||||
| Delete **all teams** | **X** | | |
|
||||
| Delete the organization account, including all repositories | **X** | | |
|
||||
| Create teams (see "[Setting team creation permissions in your organization](/articles/setting-team-creation-permissions-in-your-organization)" for details) | **X** | **X** | |
|
||||
|
|
|
|||
|
|
@ -60,7 +60,8 @@ In addition to managing organization-level settings, organization owners have ad
|
|||
| [Report abusive or spammy content](/articles/reporting-abuse-or-spam) | **X** | **X** | **X** | **X** | **X** |{% endif %}
|
||||
| Apply labels | | **X** | **X** | **X** | **X** |
|
||||
| Create, edit, delete labels | | | **X** | **X** | **X** |
|
||||
| Close, reopen, and assign all issues and pull requests | | **X** | **X** | **X** | **X** |
|
||||
| Close, reopen, and assign all issues and pull requests | | **X** | **X** | **X** | **X** |{% if currentVersion == "free-pro-team@latest" %}
|
||||
| [Enable and disable auto-merge on a pull request](/github/administering-a-repository/managing-auto-merge-for-pull-requests-in-your-repository) | | | **X** | **X** | **X** |{% endif %}
|
||||
| Apply milestones | | **X** | **X** | **X** | **X** |
|
||||
| Mark [duplicate issues and pull requests](/articles/about-duplicate-issues-and-pull-requests)| | **X** | **X** | **X** | **X** |
|
||||
| Request [pull request reviews](/articles/requesting-a-pull-request-review) | | **X** | **X** | **X** | **X** |
|
||||
|
|
|
|||
|
|
@ -9,14 +9,19 @@ versions:
|
|||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
When restricted email notifications are enabled in an organization, members can only receive email notifications about organization activity at an email address associated with the organization's verified domain. For more information, see "[Verifying your organization's domain](/articles/verifying-your-organization-s-domain)."
|
||||
### About email restrictions
|
||||
|
||||
When restricted email notifications are enabled in an organization, members can only use an email address associated with the organization's verified domains to receive email notifications about organization activity. For more information, see "[Verifying your organization's domain](/articles/verifying-your-organization-s-domain)."
|
||||
|
||||
Outside collaborators are not subject to restrictions on email notifications for verified domains. For more information on outside collaborators, see "[Permission levels for an organization](/github/setting-up-and-managing-organizations-and-teams/permission-levels-for-an-organization#outside-collaborators)."
|
||||
|
||||
If your organization is owned by an enterprise account, organization members will be able to receive notifications from any domains verified for the enterprise account, in addition to any domains verified for the organization. For more information, see "[Verifying your enterprise account's domain](/github/setting-up-and-managing-your-enterprise/verifying-your-enterprise-accounts-domain)."
|
||||
|
||||
### Restricting email notifications to an approved domain
|
||||
|
||||
{% data reusables.profile.access_profile %}
|
||||
{% data reusables.profile.access_org %}
|
||||
{% data reusables.organizations.org_settings %}
|
||||
{% data reusables.organizations.verified-domains %}
|
||||
5. Under "Enforcement preferences", select **Restrict email notifications to domain email**.
|
||||
|
||||
{% data reusables.organizations.restrict-email-notifications %}
|
||||
6. Click **Save**.
|
||||
|
|
|
|||
|
|
@ -8,46 +8,34 @@ versions:
|
|||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
### About domain verification
|
||||
|
||||
To verify domains on {% data variables.product.product_name %}, you must have owner permissions in the organization. For more information, see "[Permission levels for an organization](/articles/permission-levels-for-an-organization)." You will also need access to modify domain records with your domain hosting service.
|
||||
|
||||
After verifying ownership of your organization's domains, a "Verified" badge will display on the organization's profile. If your organization is on {% data variables.product.prodname_ghe_cloud %} and has agreed to the Corporate Terms of Service, organization owners will be able to verify the identity of organization members by viewing each member's email address within the verified domain. For more information, see "[About your organization's profile page](/articles/about-your-organization-s-profile/)" and "[Upgrading to the Corporate Terms of Service](/articles/upgrading-to-the-corporate-terms-of-service)."
|
||||
|
||||
To display a "Verified" badge, the website and email information shown on your organization's profile must match the verified domain or domains. If the website and email address shown on your organization's profile are hosted on different domains, you must verify both domains.
|
||||
If your organization is owned by an enterprise account, a "Verified" badge will display on your organization's profile for any domains verified for the enterprise account, in addition to any domains verified for the organization. For more information, see "[Verifying your enterprise account's domain](/github/setting-up-and-managing-your-enterprise/verifying-your-enterprise-accounts-domain)."
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** If the email address and website shown on your organization's profile use variants of the same domain, you must verify both variants. For example, if your organization's profile shows the website `www.example.com` and the email address `info@example.com`, you would need to verify both `www.example.com` and `example.com`.
|
||||
|
||||
{% endnote %}
|
||||
{% data reusables.organizations.verified-domains-details %}
|
||||
|
||||
On {% data variables.product.prodname_ghe_cloud %}, after verifying ownership of your organization's domain, you can restrict email notifications for the organization to that domain. For more information, see "[Restricting email notifications to an approved domain](/articles/restricting-email-notifications-to-an-approved-domain)."
|
||||
|
||||
### Verifying your organization's domain
|
||||
|
||||
{% data reusables.profile.access_profile %}
|
||||
{% data reusables.profile.access_org %}
|
||||
{% data reusables.organizations.org_settings %}
|
||||
{% data reusables.organizations.verified-domains %}
|
||||
5. Click **Add a domain**.
|
||||
|
||||
6. In the domain field, type the domain you'd like to verify, then click **Add domain**.
|
||||
|
||||
7. Follow the instructions under **Add a DNS TXT record** to create a DNS TXT record with your domain hosting service. It may take up to 72 hours for your DNS configuration to change. Once your DNS configuration has changed, continue to the next step.
|
||||
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Tip:** You can confirm your DNS configuration has changed by running the `dig` command on the command line. In the example command, replace `ORGANIZATION` with the name of your organization, and `example.com` with the domain you'd like to verify. You should see your new TXT record listed in the command output.
|
||||
|
||||
{% data reusables.organizations.add-domain %}
|
||||
{% data reusables.organizations.add-dns-txt-record %}
|
||||
1. Wait for your DNS configuration to change, which may take up to 72 hours. You can confirm your DNS configuration has changed by running the `dig` command on the command line, replacing `ORGANIZATION` with the name of your organization and `example.com` with the domain you'd like to verify. You should see your new TXT record listed in the command output.
|
||||
```shell
|
||||
$ dig _github-challenge-<em>ORGANIZATION</em>.<em>example.com</em> +nostats +nocomments +nocmd TXT
|
||||
```
|
||||
|
||||
{% endtip %}
|
||||
|
||||
8. After confirming your TXT record is added to your DNS, navigate to the Verified domains tab in your organization's settings. You can follow steps one through four above to locate the Verified domains tab.
|
||||
|
||||
9. Next to the domain that's pending verification, click {% octicon "kebab-horizontal" aria-label="The horizontal kebab icon" %}, then click **Continue verifying**.
|
||||
|
||||
10. Click **Verify domain**.
|
||||
|
||||
{% data reusables.organizations.continue-verifying-domain %}
|
||||
11. Optionally, once the "Verified" badge is visible on your organization's profile page, you can delete the TXT entry from the DNS record at your domain hosting service.
|
||||
|
||||
|
|
|
|||
|
|
@ -34,6 +34,8 @@ versions:
|
|||
{% link_in_list /enforcing-team-policies-in-your-enterprise-account %}
|
||||
{% link_in_list /enforcing-security-settings-in-your-enterprise-account %}
|
||||
{% link_in_list /configuring-saml-single-sign-on-and-scim-for-your-enterprise-account-using-okta %}
|
||||
{% link_in_list /verifying-your-enterprise-accounts-domain %}
|
||||
{% link_in_list /restricting-email-notifications-for-your-enterprise-account-to-approved-domains %}
|
||||
{% link_in_list /enforcing-a-policy-on-dependency-insights-in-your-enterprise-account %}
|
||||
{% link_in_list /enforcing-github-actions-policies-in-your-enterprise-account %}
|
||||
{% link_in_list /configuring-the-retention-period-for-github-actions-artifacts-and-logs-in-your-enterprise-account %}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
title: Restricting email notifications for your enterprise account to approved domains
|
||||
intro: "You can prevent your enterprise's information from leaking into personal accounts by restricting email notifications about activity in organizations owned by your enterprise account to verified domains."
|
||||
product: '{% data reusables.gated-features.enterprise-accounts %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
permissions: Enterprise owners can restrict email notifications for an enterprise account.
|
||||
---
|
||||
|
||||
{% data reusables.enterprise-accounts.verifying-domains-release-phase %}
|
||||
|
||||
### About email restrictions for your enterprise account
|
||||
|
||||
When you restrict email notifications to verified domains, enterprise members can only use an email address associated with a verified domain to receive email notifications about activity in organizations owned by your enterprise account. The domains can be inherited from the enterprise account or configured for the specific organization. For more information about email restrictions for organizations, see "[Restricting email notifications to an approved domain](/github/setting-up-and-managing-organizations-and-teams/restricting-email-notifications-to-an-approved-domain)."
|
||||
|
||||
If email restrictions are enabled for an enterprise account, organization owners cannot disable email restrictions for any organization owned by the enterprise account. If changes occur that result in an organization having no verified domains, either inherited from an enterprise account that owns the organization or for the specific organization, email restrictions will be disabled for the organization.
|
||||
|
||||
### Restricting email notifications for your enterprise account
|
||||
|
||||
Before you can restrict email notifications for your enterprise account, you must verify at least one domain for the enterprise account. For more information, see "[Verifying your enterprise account's domain](/github/setting-up-and-managing-your-enterprise/verifying-your-enterprise-accounts-domain)."
|
||||
|
||||
{% data reusables.enterprise-accounts.access-enterprise %}
|
||||
{% data reusables.enterprise-accounts.settings-tab %}
|
||||
{% data reusables.enterprise-accounts.verified-domains-tab %}
|
||||
{% data reusables.organizations.restrict-email-notifications %}
|
||||
1. Click **Save**.
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
---
|
||||
title: Verifying your enterprise account's domain
|
||||
intro: 'You can confirm the identity of organizations owned by your enterprise account by verifying ownership of your domain names with {% data variables.product.company_short %}.'
|
||||
product: '{% data reusables.gated-features.enterprise-accounts %}'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
permissions: Enterprise owners can verify an enterprise account's domain.
|
||||
redirect_from:
|
||||
- /github/articles/verifying-your-enterprise-accounts-domain
|
||||
- /early-access/github/articles/verifying-your-enterprise-accounts-domain
|
||||
---
|
||||
|
||||
{% data reusables.enterprise-accounts.verifying-domains-release-phase %}
|
||||
|
||||
### About domain verification
|
||||
|
||||
You can confirm that the websites and email addresses listed on the profiles of any organization owned by your enterprise account are controlled by your enterprise by verifying the domains. Verified domains for an enterprise account apply to every organization owned by the enterprise account, and organization owners can verify additional domains for their organizations. For more information, see "[Verifying your organization's domain](/github/setting-up-and-managing-organizations-and-teams/verifying-your-organizations-domain)."
|
||||
|
||||
After you verify ownership of your enterprise account's domains, a "Verified" badge will display on the profile of each organization that has the domain listed on its profile. {% data reusables.organizations.verified-domains-details %}
|
||||
|
||||
Organization owners will be able to verify the identity of organization members by viewing each member's email address within the verified domain.
|
||||
|
||||
After you verify domains for your enterprise account, you can restrict email notifications to verified domains for all the organizations owned by your enterprise account. For more information, see "[Restricting email notifications for your enterprise account to approved domains](/github/setting-up-and-managing-your-enterprise/restricting-email-notifications-for-your-enterprise-account-to-approved-domains)."
|
||||
|
||||
Even if you don't restrict email notifications for the enterprise account, if an organization owner has restricted email notifications for the organization, organization members will be able to receive notifications from any domains verified for the enterprise account, in addition to any domains verified for the organization. For more information about restricting notifications for an organization, see "[Restricting email notifications to an approved domain](/github/setting-up-and-managing-organizations-and-teams/restricting-email-notifications-to-an-approved-domain)."
|
||||
|
||||
### Verifying your enterprise account's domain
|
||||
|
||||
To verify your enterprise account's domain, you must have access to modify domain records with your domain hosting service.
|
||||
|
||||
{% data reusables.enterprise-accounts.access-enterprise %}
|
||||
{% data reusables.enterprise-accounts.settings-tab %}
|
||||
{% data reusables.enterprise-accounts.verified-domains-tab %}
|
||||
1. Click **Add a domain**.
|
||||
|
||||
{% data reusables.organizations.add-domain %}
|
||||
{% data reusables.organizations.add-dns-txt-record %}
|
||||
1. Wait for your DNS configuration to change, which may take up to 72 hours. You can confirm your DNS configuration has changed by running the `dig` command on the command line, replacing `ENTERPRISE-ACCOUNT` with the name of your enterprise account, and `example.com` with the domain you'd like to verify. You should see your new TXT record listed in the command output.
|
||||
```shell
|
||||
dig _github-challenge-<em>ENTERPRISE-ACCOUNT</em>.<em>example.com</em> +nostats +nocomments +nocmd TXT
|
||||
```
|
||||
{% data reusables.organizations.continue-verifying-domain %}
|
||||
1. Optionally, after the "Verified" badge is visible on your organizations' profiles, delete the TXT entry from the DNS record at your domain hosting service.
|
||||
|
||||
|
|
@ -11,7 +11,7 @@ versions:
|
|||
github-ae: '*'
|
||||
---
|
||||
|
||||
{% if currentVersion == "free-pro-team@latest" or enterpriseServerVersions contains currentVersion %}Your contribution graph shows activity from public repositories. {% endif %}You can choose to show activity from {% if currentVersion == "free-pro-team@latest" or enterpriseServerVersions contains currentVersion %}both public and{% endif %}private repositories, with specific details of your activity in private repositories anonymized. For more information, see "[Publicizing or hiding your private contributions on your profile](/articles/publicizing-or-hiding-your-private-contributions-on-your-profile)."
|
||||
{% if currentVersion == "free-pro-team@latest" or enterpriseServerVersions contains currentVersion %}Your contribution graph shows activity from public repositories. {% endif %}You can choose to show activity from {% if currentVersion == "free-pro-team@latest" or enterpriseServerVersions contains currentVersion %}both public and {% endif %}private repositories, with specific details of your activity in private repositories anonymized. For more information, see "[Publicizing or hiding your private contributions on your profile](/articles/publicizing-or-hiding-your-private-contributions-on-your-profile)."
|
||||
|
||||
{% note %}
|
||||
|
||||
|
|
|
|||
|
|
@ -44,7 +44,8 @@ The repository owner has full control of the repository. In addition to the acti
|
|||
| Define code owners for the repository | "[About code owners](/github/creating-cloning-and-archiving-repositories/about-code-owners)" |
|
||||
| Archive the repository | "[About archiving repositories](/github/creating-cloning-and-archiving-repositories/about-archiving-repositories)" |{% if currentVersion == "free-pro-team@latest" %}
|
||||
| Create security advisories | "[About {% data variables.product.prodname_security_advisories %}](/github/managing-security-vulnerabilities/about-github-security-advisories)" |
|
||||
| Display a sponsor button | "[Displaying a sponsor button in your repository](/github/administering-a-repository/displaying-a-sponsor-button-in-your-repository)" |{% endif %}
|
||||
| Display a sponsor button | "[Displaying a sponsor button in your repository](/github/administering-a-repository/displaying-a-sponsor-button-in-your-repository)" |
|
||||
| Allow or disallow auto-merge for pull requests | "[Managing auto-merge for pull requests in your repository](/github/administering-a-repository/managing-auto-merge-for-pull-requests-in-your-repository)" | {% endif %}
|
||||
|
||||
### Collaborator access for a repository owned by a user account
|
||||
|
||||
|
|
@ -66,7 +67,8 @@ Collaborators can also perform the following actions.
|
|||
| Manage labels for issues and pull requests in the repository | "[Labeling issues and pull requests](/github/managing-your-work-on-github/labeling-issues-and-pull-requests)" |
|
||||
| Manage milestones for issues and pull requests in the repository | "[Creating and editing milestones for issues and pull requests](/github/managing-your-work-on-github/creating-and-editing-milestones-for-issues-and-pull-requests)" |
|
||||
| Mark an issue or pull request in the repository as a duplicate | "[About duplicate issues and pull requests](/github/managing-your-work-on-github/about-duplicate-issues-and-pull-requests)" |
|
||||
| Create, merge, and close pull requests in the repository | "[Proposing changes to your work with pull requests](/github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests)" |
|
||||
| Create, merge, and close pull requests in the repository | "[Proposing changes to your work with pull requests](/github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests)" |{% if currentVersion == "free-pro-team@latest" %}
|
||||
| Enable and disable auto-merge for a pull request | "[Automatically merging a pull request](/github/collaborating-with-issues-and-pull-requests/automatically-merging-a-pull-request)"{% endif %}
|
||||
| Apply suggested changes to pull requests in the repository |"[Incorporating feedback in your pull request](/github/collaborating-with-issues-and-pull-requests/incorporating-feedback-in-your-pull-request)" |
|
||||
| Create a pull request from a fork of the repository | "[Creating a pull request from a fork](/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request-from-a-fork)" |
|
||||
| Submit a review on a pull request that affects the mergeability of the pull request | "[Reviewing proposed changes in a pull request](/github/collaborating-with-issues-and-pull-requests/reviewing-proposed-changes-in-a-pull-request)" |
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ versions:
|
|||
free-pro-team: '*'
|
||||
---
|
||||
|
||||
Version Effective Date: December 7, 2020
|
||||
Version Effective Date: December 14, 2020
|
||||
|
||||
When you create an Account, you're given access to lots of different features and products that are all a part of the Service. Because many of these features and products offer different functionality, they may require additional terms and conditions specific to that feature or product. Below, we've listed those features and products, along with the corresponding additional terms that apply to your use of them.
|
||||
|
||||
|
|
@ -46,13 +46,11 @@ GitHub Pages are subject to some specific bandwidth and usage limits, and may no
|
|||
### 5. Actions and Packages
|
||||
|
||||
#### a. Actions Usage
|
||||
GitHub Actions enables you to create custom software development lifecycle workflows directly in your GitHub repository. Each Account comes with included compute and storage quantities for use with Actions, depending on your Account plan, which can be found in the [Actions documentation](/actions). Your Actions compute usage is displayed within [your account settings](https://github.com/settings/billing), and you will be notified by email in advance of reaching the limit of your included quantities. If you want to use Actions beyond your included quantities, then you may [enable overages](/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-actions).
|
||||
GitHub Actions is billed on a usage basis. The [Actions documentation](/actions) includes details, including compute and storage quantities (depending on your Account plan), and how to monitor your Actions minutes usage and set usage limits.
|
||||
|
||||
Compute usage for included and paid quantities is calculated in minutes based on the type of Actions you execute (e.g. Linux, Windows, macOS). The minutes used for each Action's job or task will be rounded up to the nearest minute. For included quantities and depending on the type of Action, a multiplier may be applied to the amount of time used to execute each job or task, prior to being rounded up to the nearest minute. Overage minutes are charged at the [stated per minute price](https://github.com/features/actions) based on the type of Actions you execute. Actions and Packages share storage, and your storage usage is displayed within your [account settings](https://github.com/settings/billing). For additional details about included quantity usage calculations, see the [Actions documentation](/actions).
|
||||
|
||||
Actions and any elements of the Action service may not be used in violation of the Agreement, the [Acceptable Use Policy](/github/site-policy/github-acceptable-use-policies), or the GitHub Actions [service limitations](/actions/reference/usage-limits-billing-and-administration/#usage-limits). Additionally, Actions should not be used for:
|
||||
Actions and any elements of the Actions service may not be used in violation of the Agreement, the [GitHub Acceptable Use Polices](/github/site-policy/github-acceptable-use-policies), or the GitHub Actions service limitations set forth in the [Actions documentation](/actions). Additionally, Actions should not be used for:
|
||||
- cryptomining;
|
||||
- using our servers to disrupt, or to gain or to attempt to gain unauthorized access to, any service, device, data, account or network (other than those authorized by the [GitHub Bug Bounty program](https://bounty.github.com))
|
||||
- using our servers to disrupt, or to gain or to attempt to gain unauthorized access to, any service, device, data, account, or network (other than those authorized by the [GitHub Bug Bounty program](https://bounty.github.com));
|
||||
- the provision of a stand-alone or integrated application or service offering Actions or any elements of Actions for commercial purposes;
|
||||
- any activity that places a burden on our servers, where that burden is disproportionate to the benefits provided to users (for example, don't use Actions as a content delivery network or as part of a serverless application, but a low benefit Action could be ok if it’s also low burden); or
|
||||
- any other activity unrelated to the production, testing, deployment, or publication of the software project associated with the repository where GitHub Actions are used.
|
||||
|
|
@ -60,16 +58,7 @@ Actions and any elements of the Action service may not be used in violation of t
|
|||
In order to prevent violations of these limitations and abuse of GitHub Actions, GitHub may monitor your use of GitHub Actions. Misuse of GitHub Actions may result in termination of jobs, or restrictions in your ability to use GitHub Actions.
|
||||
|
||||
#### b. Packages Usage
|
||||
GitHub Packages may be used to download, publish, and manage packages of Content. Each Account plan comes with included bandwidth and storage quantities for use with Packages, which can be found in the [Packages documentation](/github/managing-packages-with-github-package-registry/about-github-package-registry). Actions and Packages share storage between the two Service features. Storage and bandwidth usage are displayed within your [account settings](https://github.com/settings/billing), and you will be notified by email in advance of reaching the limit of your included quantities. If you want to use Packages beyond your included bandwidth and storage quantities, then you may [enable overages](/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-packages).
|
||||
|
||||
Bandwidth usage is calculated based on the amount of data transferred out of your repositories through Packages, but package transfers through Actions will not count toward your included or paid quantities. Packages bandwidth usage is limited by the [Acceptable Use Policy](/github/site-policy/github-acceptable-use-policies#7-excessive-bandwidth-use), and included bandwidth quantities are determined by your [account plan](https://github.com/pricing).
|
||||
|
||||
Actions and Packages storage usage is shared between the two Service features. Storage usage is calculated as a weighted average over the course of the month and does not reset each month. Public and private repositories have different included storage quantities, and the included quantities for private repositories depend on your [account plan](https://github.com/pricing).
|
||||
|
||||
#### c. Payment and Billing for Actions and Packages
|
||||
Billing for Actions and Packages is usage-based. Additional quantities of Actions or Packages cannot be purchased separately. For monthly-billed customers, you must have a payment method on file to choose to pay for additional quantities of these Service features. You will be charged on a monthly, recurring basis based on your usage in the preceding month, unless you are billed by invoice. For invoiced customers, you must pay the fees within thirty (30) days of the GitHub invoice date. For customers paying for Service feature overages in advance, unused prepaid minutes will not roll over to the next billing period and will not be refunded.
|
||||
|
||||
You can set a monthly spending limit in your [account settings](https://github.com/settings/billing/cost_management). You will be notified by email in advance of reaching the limit of your included quantities and the designated spending limit of your paid additional quantities.
|
||||
GitHub Packages is billed on a usage basis. The [Packages documentation](/packages) includes details, including bandwidth and storage quantities (depending on your Account plan), and how to monitor your Packages usage and set usage limits. Packages bandwidth usage is limited by the [GitHub Acceptable Use Polices](/github/site-policy/github-acceptable-use-policies).
|
||||
|
||||
### 6. Learning Lab
|
||||
|
||||
|
|
|
|||
|
|
@ -169,7 +169,7 @@ UNDER NO CIRCUMSTANCES AND UNDER NO LEGAL THEORY (WHETHER IN CONTRACT, TORT, NEG
|
|||
|
||||
**10.3** GitHub may terminate this Agreement at any time if (a) you have breached any provision of this Agreement or (b) GitHub is required to do so by law.
|
||||
|
||||
**10.4** Effects of Termination by Developer. Upon receiving forty-five (45) days’ advanced written notice of termination from Developer, Developer will be disabled from taking on new customers via Marketplace. Any outstanding fees shall be remitted upon termination and removal of the Developer Product from Marketplace. If termination is initiated as a result of a GitHub modication to these terms (Section 11), the terms in effect immediately prior to such modification shall govern for the duration of the 45-day notice period until the date of actual termination.
|
||||
**10.4** Effects of Termination by Developer. Upon receiving forty-five (45) days’ advanced written notice of termination from Developer, Developer will be disabled from taking on new customers via Marketplace. Any outstanding fees shall be remitted upon termination and removal of the Developer Product from Marketplace. If termination is initiated as a result of a GitHub modification to these terms (Section 11), the terms in effect immediately prior to such modification shall govern for the duration of the 45-day notice period until the date of actual termination.
|
||||
|
||||
**10.5** The obligations in Sections 2, 3, 4, 5, 8, 9 and 12-18 will survive any expiration or termination of this Agreement.
|
||||
|
||||
|
|
|
|||
|
|
@ -40,7 +40,9 @@ To set up a `www` or custom subdomain, such as `www.example.com` or `blog.exampl
|
|||
{% data reusables.pages.navigate-site-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% data reusables.pages.save-custom-domain %}
|
||||
5. Navigate to your DNS provider and create a `CNAME` record that points your subdomain to the default domain for your site. For example, if you want to use the subdomain `www.example.com` for your user site, create a `CNAME` record that points `www.example.com` to `<user>.github.io`. If you want to use the subdomain `www.anotherexample.com` for your organization site, create a `CNAME` record that points `www.anotherexample.com` to `<organization>.github.io`. The `CNAME` file should always point to `<user>.github.io` or `<organization>.github.io`, excluding the repository name. {% data reusables.pages.contact-dns-provider %} {% data reusables.pages.default-domain-information %}
|
||||
5. Navigate to your DNS provider and create a `CNAME` record that points your subdomain to the default domain for your site. For example, if you want to use the subdomain `www.example.com` for your user site, create a `CNAME` record that points `www.example.com` to `<user>.github.io`. If you want to use the subdomain `www.anotherexample.com` for your organization site, create a `CNAME` record that points `www.anotherexample.com` to `<organization>.github.io`. The `CNAME` record should always point to `<user>.github.io` or `<organization>.github.io`, excluding the repository name. {% data reusables.pages.contact-dns-provider %} {% data reusables.pages.default-domain-information %}
|
||||
|
||||
{% indented_data_reference site.data.reusables.pages.wildcard-dns-warning spaces=3 %}
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
6. To confirm that your DNS record configured correctly, use the `dig` command, replacing _WWW.EXAMPLE.COM_ with your subdomain.
|
||||
```shell
|
||||
|
|
@ -71,6 +73,8 @@ To set up an apex domain, such as `example.com`, you must configure a _CNAME_ fi
|
|||
185.199.110.153
|
||||
185.199.111.153
|
||||
```
|
||||
|
||||
{% indented_data_reference site.data.reusables.pages.wildcard-dns-warning spaces=3 %}
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
6. To confirm that your DNS record configured correctly, use the `dig` command, replacing _EXAMPLE.COM_ with your apex domain. Confirm that the results match the IP addresses for {% data variables.product.prodname_pages %} above.
|
||||
```shell
|
||||
|
|
|
|||
|
|
@ -39,11 +39,7 @@ Make sure your site does not:
|
|||
- Use more than one `www` subdomain. For example, both `www.example.com` and `www.anotherexample.com`.
|
||||
- Use both an apex domain and custom subdomain. For example, both `example.com` and `docs.example.com`.
|
||||
|
||||
{% warning %}
|
||||
|
||||
**Warning:** We strongly recommend not using wildcard DNS records, such as `*.example.com`. A wildcard DNS record will allow anyone to host a {% data variables.product.prodname_pages %} site at one of your subdomains.
|
||||
|
||||
{% endwarning %}
|
||||
{% data reusables.pages.wildcard-dns-warning %}
|
||||
|
||||
For a list of supported custom domains, see "[About custom domains and {% data variables.product.prodname_pages %}](/articles/about-custom-domains-and-github-pages/#supported-custom-domains)."
|
||||
|
||||
|
|
|
|||
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче