jprdonnelly/docs
1
0
Fork 0
mirror of synced 2025-12-22 11:26:57 -05:00
Code Issues Projects Releases Wiki Activity

Merge branch 'main' into 3059-remove-send-from-author

Browse Source
This commit is contained in:
mc
2021-01-19 15:44:58 +00:00
committed by GitHub
parent f759b3db66 c2375f1c08
commit 8cec20ec12
176 changed files with 1676 additions and 1739 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
.github/workflows/triage-unallowed-contributions.yml vendored
View File

@@ -104,6 +104,7 @@ jobs:
body: reviewMessage,
event: 'REQUEST_CHANGES'
})
exit 1 # prevents further steps from running and fails workflow
# 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

12
.github/workflows/workflow-lint.yml vendored
View File

@@ -2,12 +2,12 @@ name: Lint workflows
on:
workflow_dispatch:
push:
branches:
- main
pull_request:
branches-ignore:
- translations
# push:
# branches:
# - main
# pull_request:
# branches-ignore:
# - translations
jobs:
lint:

BIN
assets/images/help/repository/delete-branch-protection-rule.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 9.5 KiB

BIN
assets/images/help/repository/edit-branch-protection-rule.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 9.6 KiB

BIN
assets/images/help/repository/save-branch-protection-rule.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.0 KiB

15
content/README.md
View File

@@ -24,6 +24,7 @@ See the [contributing docs](/CONTRIBUTING.md) for general information about work
- [Escaping single quotes](#escaping-single-quotes)
- [Autogenerated mini TOCs](#autogenerated-mini-tocs)
- [Versioning](#versioning)
- [Free-pro-team vs. GitHub.com versioning](#free-pro-team-vs.-github.com-versioning)
- [Filenames](#filenames)
- [Whitespace control](#whitespace-control)
- [Links and image paths](#links-and-image-paths)
@@ -213,6 +214,12 @@ A content file can have **two** types of versioning:
* Liquid statements in content (**optional**)
* Conditionally render content depending on the current version being viewed. See [contributing/liquid-helpers](../contributing/liquid-helpers.md) for more info. Note Liquid conditionals can also appear in `data` and `include` files.
### Free-pro-team vs. GitHub.com versioning
As of early 2021, the `free-pro-team@latest` version is **only** supported in content files (in both frontmatter and Liquid versioning) and throughout the docs site backend. It is **not** user facing. A helper function called `lib/remove-fpt-from-path.js` removes the version from URLs. Users now select `GitHub.com` in the Article Versions dropdown instead of `Free, Pro, Team`.
The convenience function allows us to continue supporting a consistent versioning structure under-the-hood while not displaying plan information to users that may be potentially confusing.
## Filenames
When adding a new article, make sure the filename is a [kebab-cased](https://en.wikipedia.org/wiki/Letter_case#Special_case_styles) version of the title you use in the article's [`title`](#title) frontmatter. This can get tricky when a title has punctuation (such as "GitHub's Billing Plans"). A test will flag any discrepancies between title and filename. To override this requirement for a given article, you can add [`allowTitleToDifferFromFilename`](#allowtitletodifferfromfilename) frontmatter.
@@ -224,7 +231,7 @@ When using Liquid conditionals in lists or tables, you can use [whitespace contr
Just add a hyphen on either the left, right, or both sides to indicate that there should be no newline on that side. For example, this statement removes a newline on the left side:
```
{%- if page.version == 'dotcom' %}
{%- if currentVersion == 'free-pro-team@latest' %}
```
These characters are especially important in [index pages](#index-pages) comprised of list items.
@@ -238,9 +245,9 @@ For example, if you include the following link in a content file:
```
/github/writing-on-github/creating-a-saved-reply
```
When viewed on GitHub.com docs, the link gets rendered with the language code and version:
When viewed on GitHub.com docs, the link gets rendered with the language code:
```
/en/free-pro-team@latest/github/writing-on-github/creating-a-saved-reply
/en/github/writing-on-github/creating-a-saved-reply
```
and when viewed on GitHub Enterprise Server docs, the version is included as well:
```
@@ -262,7 +269,7 @@ https://github-images.s3.amazonaws.com/enterprise/2.20/assets/images/help/profil
Sometimes you want to link to a Dotcom-only article in Enterprise content and you don't want the link to be Enterprise-ified. To prevent the transformation, write the link using HTML and add a class of `dotcom-only`. For example:
```
```html
<a href="/github/site-policy/github-terms-of-service" class="dotcom-only">GitHub's Terms of Service</a>
```

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

@@ -48,20 +48,21 @@ The Docker `ENTRYPOINT` instruction has a _shell_ form and _exec_ form. The Dock
If you configure your container to use the _exec_ form of the `ENTRYPOINT` instruction, the `args` configured in the action's metadata file won't run in a command shell. If the action's `args` contain an environment variable, the variable will not be substituted. For example, using the following _exec_ format will not print the value stored in `$GITHUB_SHA`, but will instead print `"$GITHUB_SHA"`.
```
```dockerfile
ENTRYPOINT ["echo $GITHUB_SHA"]
```
If you want variable substitution, then either use the _shell_ form or execute a shell directly. For example, using the following _exec_ format, you can execute a shell to print the value stored in the `GITHUB_SHA` environment variable.
```
```dockerfile
ENTRYPOINT ["sh", "-c", "echo $GITHUB_SHA"]
````
```
To supply `args` defined in the action's metadata file to a Docker container that uses the _exec_ form in the `ENTRYPOINT`, we recommend creating a shell script called `entrypoint.sh` that you call from the `ENTRYPOINT` instruction:
##### Example *Dockerfile*
```
```dockerfile
# Container image that runs your code
FROM debian:9.5-slim

2
content/actions/creating-actions/setting-exit-codes-for-actions.md
View File

@@ -41,11 +41,13 @@ For more information, see "[Creating a JavaScript action](/articles/creating-a-j
If you are creating a Docker container action, you can set a failure exit code in your `entrypoint.sh` script. For example:
{% raw %}
```
if <condition> ; then
echo "Game over!"
exit 1
fi
```
{% endraw %}
For more information, see "[Creating a Docker container action](/articles/creating-a-docker-container-action)."

2
content/actions/guides/building-and-testing-nodejs.md
View File

@@ -220,7 +220,7 @@ steps:
The example above creates an *.npmrc* file with the following contents:
```
```ini
//registry.npmjs.org/:_authToken=${NODE_AUTH_TOKEN}
@octocat:registry=https://registry.npmjs.org/
always-auth=true

8
content/actions/guides/caching-dependencies-to-speed-up-workflows.md
View File

@@ -124,14 +124,14 @@ A cache key can include any of the contexts, functions, literals, and operators
Using expressions to create a `key` allows you to automatically create a new cache when dependencies have changed. For example, you can create a `key` using an expression that calculates the hash of an npm `package-lock.json` file.
{% raw %}
```
```yaml
npm-${{ hashFiles('package-lock.json') }}
```
{% endraw %}
{% data variables.product.prodname_dotcom %} evaluates the expression `hash "package-lock.json"` to derive the final `key`.
```
```yaml
npm-d5ea0750
```
@@ -144,7 +144,7 @@ You can provide a list of restore keys to use when there is a cache miss on `key
#### Example using multiple restore keys
{% raw %}
```
```yaml
restore-keys: |
npm-foobar-${{ hashFiles('package-lock.json') }}
npm-foobar-
@@ -155,7 +155,7 @@ restore-keys: |
The runner evaluates the expressions, which resolve to these `restore-keys`:
{% raw %}
```
```yaml
restore-keys: |
npm-foobar-d5ea0750
npm-foobar-

1
content/actions/guides/deploying-to-amazon-elastic-container-service.md
View File

@@ -5,6 +5,7 @@ product: '{% data reusables.gated-features.actions %}'
versions:
free-pro-team: '*'
enterprise-server: '>=2.22'
type: 'tutorial'
---
{% data reusables.actions.enterprise-beta %}

1
content/actions/guides/deploying-to-azure-app-service.md
View File

@@ -5,6 +5,7 @@ product: '{% data reusables.gated-features.actions %}'
versions:
free-pro-team: '*'
enterprise-server: '>=2.22'
type: 'tutorial'
---
{% data reusables.actions.enterprise-beta %}

1
content/actions/guides/deploying-to-google-kubernetes-engine.md
View File

@@ -5,6 +5,7 @@ product: '{% data reusables.gated-features.actions %}'
versions:
free-pro-team: '*'
enterprise-server: '>=2.22'
type: 'tutorial'
---
{% data reusables.actions.enterprise-beta %}

4
content/actions/guides/publishing-nodejs-packages.md
View File

@@ -78,7 +78,7 @@ jobs:
In the example above, the `setup-node` action creates an *.npmrc* file on the runner with the following contents:
```
```ini
//registry.npmjs.org/:_authToken=${NODE_AUTH_TOKEN}
registry=https://registry.npmjs.org/
always-auth=true
@@ -140,7 +140,7 @@ jobs:
The `setup-node` action creates an *.npmrc* file on the runner. When you use the `scope` input to the `setup-node` action, the *.npmrc* file includes the scope prefix. By default, the `setup-node` action sets the scope in the *.npmrc* file to the account that contains that workflow file.
```
```ini
//npm.pkg.github.com/:_authToken=${NODE_AUTH_TOKEN}
@octocat:registry=https://npm.pkg.github.com
always-auth=true

2
content/actions/guides/storing-workflow-data-as-artifacts.md
View File

@@ -114,7 +114,7 @@ jobs:
You can define a custom retention period for individual artifacts created by a workflow. When using a workflow to create a new artifact, you can use `retention-days` with the `upload-artifact` action. This example demonstrates how to set a custom retention period of 5 days for the artifact named `my-artifact`:
```
```yaml
- name: 'Upload Artifact'
uses: actions/upload-artifact@v2
with:

2
content/actions/hosting-your-own-runners/using-a-proxy-server-with-self-hosted-runners.md
View File

@@ -38,7 +38,7 @@ If setting environment variables is not practical, you can set the proxy configu
An example _.env_ proxy configuration is shown below:
```
```ini
https_proxy=http://proxy.local:8080
no_proxy=example.com,myserver.local:443
```

2
content/actions/index.md
View File

@@ -72,7 +72,7 @@ versions:
{% render 'code-example-card' for actionsCodeExamples as example %}
</div>
<button class="js-filter-card-show-more btn btn-outline float-right">Show more {% octicon "arrow-right" %}</button>
<button class="js-filter-card-show-more btn btn-outline float-right" data-js-filter-card-max="6">Show more {% octicon "arrow-right" %}</button>
<div class="js-filter-card-no-results d-none py-4 text-center text-gray font-mktg">
<div class="mb-3">{% octicon "search" width="24" %}</div>

2
content/actions/learn-github-actions/introduction-to-github-actions.md
View File

@@ -147,7 +147,7 @@ To help you understand how YAML syntax is used to create a workflow file, this s
```
</td>
<td>
Groups together all the steps that run in the <code>check-bats-version</code> job. Each line nested under this section is a separate action.
Groups together all the steps that run in the <code>check-bats-version</code> job. Each item nested under this section is a separate action or shell command.
</td>
</tr>
<tr>

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

@@ -62,16 +62,16 @@ Azure Pipelines
{% raw %}
```yaml
jobs:
- job: scripts
pool:
vmImage: 'windows-latest'
steps:
- script: echo "This step runs in the default shell"
- bash: echo "This step runs in bash"
- pwsh: Write-Host "This step runs in PowerShell Core"
- task: PowerShell@2
inputs:
script: Write-Host "This step runs in PowerShell"
- job: scripts
pool:
vmImage: 'windows-latest'
steps:
- script: echo "This step runs in the default shell"
- bash: echo "This step runs in bash"
- pwsh: Write-Host "This step runs in PowerShell Core"
- task: PowerShell@2
inputs:
script: Write-Host "This step runs in PowerShell"
```
{% endraw %}
</td>
@@ -82,13 +82,13 @@ jobs:
scripts:
runs-on: windows-latest
steps:
- run: echo "This step runs in the default shell"
- run: echo "This step runs in bash"
shell: bash
- run: Write-Host "This step runs in PowerShell Core"
shell: pwsh
- run: Write-Host "This step runs in PowerShell"
shell: powershell
- run: echo "This step runs in the default shell"
- run: echo "This step runs in bash"
shell: bash
- run: Write-Host "This step runs in PowerShell Core"
shell: pwsh
- run: Write-Host "This step runs in PowerShell"
shell: powershell
```
{% endraw %}
</td>
@@ -123,11 +123,11 @@ Azure Pipelines
{% raw %}
```yaml
jobs:
- job: run_command
pool:
vmImage: 'windows-latest'
steps:
- script: echo "This step runs in CMD on Windows by default"
- job: run_command
pool:
vmImage: 'windows-latest'
steps:
- script: echo "This step runs in CMD on Windows by default"
```
{% endraw %}
</td>
@@ -138,9 +138,9 @@ jobs:
run_command:
runs-on: windows-latest
steps:
- run: echo "This step runs in PowerShell on Windows by default"
- run: echo "This step runs in CMD on Windows explicitly"
shell: cmd
- run: echo "This step runs in PowerShell on Windows by default"
- run: echo "This step runs in CMD on Windows explicitly"
shell: cmd
```
{% endraw %}
</td>
@@ -171,12 +171,12 @@ Azure Pipelines
{% raw %}
```yaml
jobs:
- job: conditional
pool:
vmImage: 'ubuntu-latest'
steps:
- script: echo "This step runs with str equals 'ABC' and num equals 123"
condition: and(eq(variables.str, 'ABC'), eq(variables.num, 123))
- job: conditional
pool:
vmImage: 'ubuntu-latest'
steps:
- script: echo "This step runs with str equals 'ABC' and num equals 123"
condition: and(eq(variables.str, 'ABC'), eq(variables.num, 123))
```
{% endraw %}
</td>
@@ -187,8 +187,8 @@ jobs:
conditional:
runs-on: ubuntu-latest
steps:
- run: echo "This step runs with str equals 'ABC' and num equals 123"
if: ${{ env.str == 'ABC' && env.num == 123 }}
- run: echo "This step runs with str equals 'ABC' and num equals 123"
if: ${{ env.str == 'ABC' && env.num == 123 }}
```
{% endraw %}
</td>
@@ -217,29 +217,29 @@ Azure Pipelines
{% raw %}
```yaml
jobs:
- job: initial
pool:
vmImage: 'ubuntu-latest'
steps:
- script: echo "This job will be run first."
- job: fanout1
pool:
vmImage: 'ubuntu-latest'
dependsOn: initial
steps:
- script: echo "This job will run after the initial job, in parallel with fanout2."
- job: fanout2
pool:
vmImage: 'ubuntu-latest'
dependsOn: initial
steps:
- script: echo "This job will run after the initial job, in parallel with fanout1."
- job: fanin:
pool:
vmImage: 'ubuntu-latest'
dependsOn: [fanout1, fanout2]
steps:
- script: echo "This job will run after fanout1 and fanout2 have finished."
- job: initial
pool:
vmImage: 'ubuntu-latest'
steps:
- script: echo "This job will be run first."
- job: fanout1
pool:
vmImage: 'ubuntu-latest'
dependsOn: initial
steps:
- script: echo "This job will run after the initial job, in parallel with fanout2."
- job: fanout2
pool:
vmImage: 'ubuntu-latest'
dependsOn: initial
steps:
- script: echo "This job will run after the initial job, in parallel with fanout1."
- job: fanin:
pool:
vmImage: 'ubuntu-latest'
dependsOn: [fanout1, fanout2]
steps:
- script: echo "This job will run after fanout1 and fanout2 have finished."
```
{% endraw %}
</td>
@@ -250,22 +250,22 @@ jobs:
initial:
runs-on: ubuntu-latest
steps:
- run: echo "This job will be run first."
- run: echo "This job will be run first."
fanout1:
runs-on: ubuntu-latest
needs: initial
steps:
- run: echo "This job will run after the initial job, in parallel with fanout2."
- run: echo "This job will run after the initial job, in parallel with fanout2."
fanout2:
runs-on: ubuntu-latest
needs: initial
steps:
- run: echo "This job will run after the initial job, in parallel with fanout1."
- run: echo "This job will run after the initial job, in parallel with fanout1."
fanin:
runs-on: ubuntu-latest
needs: [fanout1, fanout2]
steps:
- run: echo "This job will run after fanout1 and fanout2 have finished."
- run: echo "This job will run after fanout1 and fanout2 have finished."
```
{% endraw %}
</td>
@@ -294,15 +294,15 @@ Azure Pipelines
{% raw %}
```yaml
jobs:
- job: run_python
pool:
vmImage: 'ubuntu-latest'
steps:
- task: UsePythonVersion@0
inputs:
versionSpec: '3.7'
architecture: 'x64'
- script: python script.py
- job: run_python
pool:
vmImage: 'ubuntu-latest'
steps:
- task: UsePythonVersion@0
inputs:
versionSpec: '3.7'
architecture: 'x64'
- script: python script.py
```
{% endraw %}
</td>
@@ -313,11 +313,11 @@ jobs:
run_python:
runs-on: ubuntu-latest
steps:
- uses: actions/setup-python@v2
with:
python-version: '3.7'
architecture: 'x64'
- run: python script.py
- uses: actions/setup-python@v2
with:
python-version: '3.7'
architecture: 'x64'
- run: python script.py
```
{% endraw %}
</td>

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

@@ -258,24 +258,24 @@ jobs:
POSTGRES_DB: ruby25
POSTGRES_PASSWORD: ""
ports:
- 5432:5432
- 5432:5432
# Add a health check
options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5
steps:
# This Docker file changes sets USER to circleci instead of using the default user, so we need to update file permissions for this image to work on GH Actions.
# See https://docs.github.com/actions/reference/virtual-environments-for-github-hosted-runners#docker-container-filesystem
- name: Setup file system permissions
run: sudo chmod -R 777 $GITHUB_WORKSPACE /github /__w/_temp
- uses: actions/checkout@v2
- name: Install dependencies
run: bundle install --path vendor/bundle
- name: Setup environment configuration
run: cp .sample.env .env
- name: Setup database
run: bundle exec rake db:setup
- name: Run tests
run: bundle exec rake
# This Docker file changes sets USER to circleci instead of using the default user, so we need to update file permissions for this image to work on GH Actions.
# See https://docs.github.com/actions/reference/virtual-environments-for-github-hosted-runners#docker-container-filesystem
- name: Setup file system permissions
run: sudo chmod -R 777 $GITHUB_WORKSPACE /github /__w/_temp
- uses: actions/checkout@v2
- name: Install dependencies
run: bundle install --path vendor/bundle
- name: Setup environment configuration
run: cp .sample.env .env
- name: Setup database
run: bundle exec rake db:setup
- name: Run tests
run: bundle exec rake
```
{% endraw %}
</td>
@@ -412,35 +412,35 @@ jobs:
POSTGRES_DB: ruby25
POSTGRES_PASSWORD: ""
ports:
- 5432:5432
- 5432:5432
# Add a health check
options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5
steps:
- uses: actions/checkout@v2
- name: Setup Ruby
uses: eregon/use-ruby-action@master
with:
ruby-version: ${{ matrix.ruby }}
- name: Cache dependencies
uses: actions/cache@v2
with:
path: vendor/bundle
key: administrate-${{ matrix.image }}-${{ hashFiles('Gemfile.lock') }}
- name: Install postgres headers
run: sudo apt-get install libpq-dev
- name: Install dependencies
run: bundle install --path vendor/bundle
- name: Setup environment configuration
run: cp .sample.env .env
- name: Setup database
run: bundle exec rake db:setup
- name: Run tests
run: bundle exec rake
- name: Install appraisal
run: bundle exec appraisal install
- name: Run appraisal
run: bundle exec appraisal rake
- uses: actions/checkout@v2
- name: Setup Ruby
uses: eregon/use-ruby-action@master
with:
ruby-version: ${{ matrix.ruby }}
- name: Cache dependencies
uses: actions/cache@v2
with:
path: vendor/bundle
key: administrate-${{ matrix.image }}-${{ hashFiles('Gemfile.lock') }}
- name: Install postgres headers
run: sudo apt-get install libpq-dev
- name: Install dependencies
run: bundle install --path vendor/bundle
- name: Setup environment configuration
run: cp .sample.env .env
- name: Setup database
run: bundle exec rake db:setup
- name: Run tests
run: bundle exec rake
- name: Install appraisal
run: bundle exec appraisal install
- name: Run appraisal
run: bundle exec appraisal rake
```
{% endraw %}
</td>

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

@@ -60,8 +60,8 @@ job1:
jobs:
job1:
steps:
- uses: actions/checkout@v2
- run: echo "Run your script here"
- uses: actions/checkout@v2
- run: echo "Run your script here"
```
{% endraw %}
</td>
@@ -257,24 +257,24 @@ jobs:
build_a:
runs-on: ubuntu-latest
steps:
- run: echo "This job will be run first."
- run: echo "This job will be run first."
build_b:
runs-on: ubuntu-latest
steps:
- run: echo "This job will be run first, in parallel with build_a"
- run: echo "This job will be run first, in parallel with build_a"
test_ab:
runs-on: ubuntu-latest
needs: [build_a,build_b]
steps:
- run: echo "This job will run after build_a and build_b have finished"
- run: echo "This job will run after build_a and build_b have finished"
deploy_ab:
runs-on: ubuntu-latest
needs: [test_ab]
steps:
- run: echo "This job will run after test_ab is complete"
- run: echo "This job will run after test_ab is complete"
```
{% endraw %}
</td>
@@ -335,12 +335,12 @@ test_async:
```yaml
jobs:
test_async:
- name: Cache node modules
uses: actions/cache@v2
with:
path: ~/.npm
key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}
restore-keys: v1-npm-deps-
- name: Cache node modules
uses: actions/cache@v2
with:
path: ~/.npm
key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}
restore-keys: v1-npm-deps-
```
{% endraw %}
</td>
@@ -371,7 +371,7 @@ GitLab CI/CD
script:
artifacts:
paths:
- math-homework.txt
- math-homework.txt
```
{% endraw %}
</td>
@@ -424,12 +424,12 @@ container-job:
services:
- postgres
script:
# Performs a clean installation of all dependencies
# in the `package.json` file
- npm ci
# Runs a script that creates a PostgreSQL client,
# populates the client with data, and retrieves data
- node client.js
# Performs a clean installation of all dependencies
# in the `package.json` file
- npm ci
# Runs a script that creates a PostgreSQL client,
# populates the client with data, and retrieves data
- node client.js
tags:
- docker
```

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

@@ -36,21 +36,20 @@ Jenkins lets you send builds to a single build agent, or you can distribute them
Similarly, {% data variables.product.prodname_actions %} can send jobs to {% data variables.product.prodname_dotcom %}-hosted or self-hosted runners, and you can use labels to classify runners according to various attributes. The following table compares how the distributed build concept is implemented for both Jenkins and {% data variables.product.prodname_actions %}.
| Jenkins | {% data variables.product.prodname_actions %} |
| Jenkins | {% data variables.product.prodname_actions %} |
| ------------- | ------------- |
| [`agents`](https://wiki.jenkins.io/display/JENKINS/Distributed+builds) | [`runners`](/actions/learn-github-actions/introduction-to-github-actions#runners) <br> [`self-hosted runners`](/actions/hosting-your-own-runners/about-self-hosted-runners)|
| [`agents`](https://wiki.jenkins.io/display/JENKINS/Distributed+builds) | [`runners`](/actions/learn-github-actions/introduction-to-github-actions#runners) <br> [`self-hosted runners`](/actions/hosting-your-own-runners/about-self-hosted-runners) |
#### Using sections to organize pipelines
Jenkins splits its Declarative Pipelines into multiple sections. Similarly, {% data variables.product.prodname_actions %} organizes its workflows into separate sections. The table below compares Jenkins sections with the {% data variables.product.prodname_actions %} workflow.
|Jenkins Directives | {% data variables.product.prodname_actions %} |
| Jenkins Directives | {% data variables.product.prodname_actions %} |
| ------------- | ------------- |
| [`agent`](https://jenkins.io/doc/book/pipeline/syntax/#agent) | [`jobs.<job_id>.runs-on`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idruns-on) <br> [`jobs.<job_id>.container`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idcontainer)|
| [`post`](https://jenkins.io/doc/book/pipeline/syntax/#post) | |
| [`stages`](https://jenkins.io/doc/book/pipeline/syntax/#stages) | [`jobs`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobs) |
| [`steps`](https://jenkins.io/doc/book/pipeline/syntax/#steps) | [`jobs.<job_id>.steps`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idsteps) |
| [`agent`](https://jenkins.io/doc/book/pipeline/syntax/#agent) | [`jobs.<job_id>.runs-on`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idruns-on) <br> [`jobs.<job_id>.container`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idcontainer) |
| [`post`](https://jenkins.io/doc/book/pipeline/syntax/#post) | |
| [`stages`](https://jenkins.io/doc/book/pipeline/syntax/#stages) | [`jobs`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobs) |
| [`steps`](https://jenkins.io/doc/book/pipeline/syntax/#steps) | [`jobs.<job_id>.steps`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idsteps) |
### Using directives
@@ -58,17 +57,16 @@ 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) |
| [`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) |
| [`triggers { upstreamprojects() }`](https://jenkins.io/doc/book/pipeline/syntax/#triggers) | [`jobs.<job_id>.needs`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idneeds) |
| [Jenkins cron syntax](https://jenkins.io/doc/book/pipeline/syntax/#cron-syntax) | [`on.schedule`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onschedule) |
| [`stage`](https://jenkins.io/doc/book/pipeline/syntax/#stage) | [`jobs.<job_id>`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_id) <br> [`jobs.<job_id>.name`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idname)|
| [`tools`](https://jenkins.io/doc/book/pipeline/syntax/#tools) | [Specifications for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/reference/specifications-for-github-hosted-runners/#supported-software) |
| [`input`](https://jenkins.io/doc/book/pipeline/syntax/#input) | [`inputs`](/actions/automating-your-workflow-with-github-actions/metadata-syntax-for-github-actions#inputs) |
| [`when`](https://jenkins.io/doc/book/pipeline/syntax/#when) | [`jobs.<job_id>.if`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idif) |
| [`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) |
| [`triggers { upstreamprojects() }`](https://jenkins.io/doc/book/pipeline/syntax/#triggers) | [`jobs.<job_id>.needs`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idneeds) |
| [Jenkins cron syntax](https://jenkins.io/doc/book/pipeline/syntax/#cron-syntax) | [`on.schedule`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onschedule) |
| [`stage`](https://jenkins.io/doc/book/pipeline/syntax/#stage) | [`jobs.<job_id>`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_id) <br> [`jobs.<job_id>.name`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idname) |
| [`tools`](https://jenkins.io/doc/book/pipeline/syntax/#tools) | [Specifications for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/reference/specifications-for-github-hosted-runners/#supported-software) |
| [`input`](https://jenkins.io/doc/book/pipeline/syntax/#input) | [`inputs`](/actions/automating-your-workflow-with-github-actions/metadata-syntax-for-github-actions#inputs) |
| [`when`](https://jenkins.io/doc/book/pipeline/syntax/#when) | [`jobs.<job_id>.if`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idif) |
### Using sequential stages
@@ -84,19 +82,19 @@ Jenkins can run the `stages` and `steps` in parallel, while {% data variables.pr
Both {% data variables.product.prodname_actions %} and Jenkins let you use a build matrix to define various system combinations.
| Jenkins | {% data variables.product.prodname_actions %} |
| Jenkins | {% data variables.product.prodname_actions %} |
| ------------- | ------------- |
| [`axis`](https://jenkins.io/doc/book/pipeline/syntax/#matrix-axes) | [`strategy/matrix`](/actions/learn-github-actions/managing-complex-workflows/#using-a-build-matrix) <br> [`context`](/actions/reference/context-and-expression-syntax-for-github-actions) |
| [`stages`](https://jenkins.io/doc/book/pipeline/syntax/#matrix-stages) | [`steps-context`](/actions/reference/context-and-expression-syntax-for-github-actions#steps-context) |
| [`excludes`](https://jenkins.io/doc/book/pipeline/syntax/#matrix-stages) | |
| [`axis`](https://jenkins.io/doc/book/pipeline/syntax/#matrix-axes) | [`strategy/matrix`](/actions/learn-github-actions/managing-complex-workflows/#using-a-build-matrix) <br> [`context`](/actions/reference/context-and-expression-syntax-for-github-actions) |
| [`stages`](https://jenkins.io/doc/book/pipeline/syntax/#matrix-stages) | [`steps-context`](/actions/reference/context-and-expression-syntax-for-github-actions#steps-context) |
| [`excludes`](https://jenkins.io/doc/book/pipeline/syntax/#matrix-stages) | |
#### Using steps to execute tasks
Jenkins groups `steps` together in `stages`. Each of these steps can be a script, function, or command, among others. Similarly, {% data variables.product.prodname_actions %} uses `jobs` to execute specific groups of `steps`.
| Jenkins steps | {% data variables.product.prodname_actions %} |
| Jenkins steps | {% data variables.product.prodname_actions %} |
| ------------- | ------------- |
| [`script`](https://jenkins.io/doc/book/pipeline/syntax/#script) | [`jobs.<job_id>.steps`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idsteps) |
| [`script`](https://jenkins.io/doc/book/pipeline/syntax/#script) | [`jobs.<job_id>.steps`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idsteps) |
### Examples of common tasks
@@ -114,23 +112,23 @@ Jenkins Pipeline
<tr>
<td>
```yaml
pipeline {
agent any
triggers {
cron('H/15 * * * 1-5')
}
}
```
```yaml
pipeline {
agent any
triggers {
cron('H/15 * * * 1-5')
}
}
```
</td>
<td>
```yaml
on:
```yaml
on:
schedule:
- cron: '*/15 * * * 1-5'
```
- cron: '*/15 * * * 1-5'
```
</td>
</tr>
@@ -150,25 +148,24 @@ Jenkins Pipeline
<tr>
<td>
```yaml
pipeline {
agent any
environment {
MAVEN_PATH = '/usr/local/maven'
}
```yaml
pipeline {
agent any
environment {
MAVEN_PATH = '/usr/local/maven'
}
```
}
```
</td>
<td>
```yaml
jobs:
maven-build:
```yaml
jobs:
maven-build:
env:
MAVEN_PATH: '/usr/local/maven'
```
```
</td>
</tr>
@@ -188,30 +185,28 @@ Jenkins Pipeline
<tr>
<td>
```yaml
pipeline {
triggers {
upstream(
upstreamProjects: 'job1,job2',
threshold: hudson.model.Result.SUCCESS)
}
}
```yaml
pipeline {
triggers {
upstream(
upstreamProjects: 'job1,job2',
threshold: hudson.model.Result.SUCCESS
)
}
```
}
```
</td>
<td>
```yaml
jobs:
job1:
job2:
needs: job1
job3:
needs: [job1, job2]
```
```yaml
jobs:
job1:
job2:
needs: job1
job3:
needs: [job1, job2]
```
</td>
</tr>
@@ -231,26 +226,27 @@ Jenkins Pipeline
<tr>
<td>
```yaml
```yaml
pipeline {
agent none
stages {
stage('Run Tests') {
matrix {
axes {
axis {
name: 'PLATFORM'
values: 'macos', 'linux'
agent none
stages {
stage('Run Tests') {
matrix {
axes {
axis {
name: 'PLATFORM'
values: 'macos', 'linux'
}
}
}
agent { label "${PLATFORM}" }
stages {
stage('test') {
tools { nodejs "node-12" }
steps {
dir("scripts/myapp") {
sh(script: "npm install -g bats")
sh(script: "bats tests")
agent { label "${PLATFORM}" }
stages {
stage('test') {
tools { nodejs "node-12" }
steps {
dir("scripts/myapp") {
sh(script: "npm install -g bats")
sh(script: "bats tests")
}
}
}
}
@@ -258,33 +254,32 @@ stages {
}
}
}
}
```
```
</td>
<td>
{% raw %}
```yaml
name: demo-workflow
on:
push:
jobs:
test:
runs-on: ${{ matrix.os }}
strategy:
fail-fast: false
matrix:
os: [macos-latest, ubuntu-latest]
steps:
- uses: actions/checkout@v1
- uses: actions/setup-node@v1
with:
node-version: 12
- run: npm install -g bats
- run: bats tests
working-directory: scripts/myapp
```
```yaml
name: demo-workflow
on:
push:
jobs:
test:
runs-on: ${{ matrix.os }}
strategy:
fail-fast: false
matrix:
os: [macos-latest, ubuntu-latest]
steps:
- uses: actions/checkout@v1
- uses: actions/setup-node@v1
with:
node-version: 12
- run: npm install -g bats
- run: bats tests
working-directory: scripts/myapp
```
{% endraw %}
</td>

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

@@ -70,8 +70,8 @@ Travis CI
```yaml
matrix:
include:
- rvm: 2.5
- rvm: 2.6.3
- rvm: 2.5
- rvm: 2.6.3
```
{% endraw %}
</td>
@@ -110,8 +110,8 @@ Travis CI
```yaml
branches:
only:
- main
- 'mona/octocat'
- main
- 'mona/octocat'
```
{% endraw %}
</td>
@@ -156,9 +156,9 @@ git:
<td class="d-table-cell v-align-top">
{% raw %}
```yaml
- uses: actions/checkout@v2
with:
submodules: false
- uses: actions/checkout@v2
with:
submodules: false
```
{% endraw %}
</td>
@@ -208,10 +208,10 @@ When working with different languages in {% data variables.product.prodname_acti
For example:
```yaml
steps:
- name: Run build script
run: ./.github/scripts/build.sh
shell: bash
steps:
- name: Run build script
run: ./.github/scripts/build.sh
shell: bash
```
### Error handling in {% data variables.product.prodname_actions %}
@@ -276,11 +276,11 @@ jobs:
run_python:
runs-on: ubuntu-latest
steps:
- uses: actions/setup-python@v2
with:
python-version: '3.7'
architecture: 'x64'
- run: python script.py
- uses: actions/setup-python@v2
with:
python-version: '3.7'
architecture: 'x64'
- run: python script.py
```
{% endraw %}
</td>
@@ -346,20 +346,20 @@ Travis CI
<tr>
<td>
```yaml
```yaml
env:
- MAVEN_PATH="/usr/local/maven"
```
```
</td>
<td>
```yaml
jobs:
maven-build:
env:
MAVEN_PATH: '/usr/local/maven'
```
```yaml
jobs:
maven-build:
env:
MAVEN_PATH: '/usr/local/maven'
```
</td>
</tr>
@@ -379,24 +379,24 @@ Travis CI
<tr>
<td>
{% raw %}
```yaml
```yaml
install:
- npm install
- npm install
script:
- npm run build
- npm test
```
- npm run build
- npm test
```
{% endraw %}
</td>
<td>
{% raw %}
```yaml
```yaml
name: Node.js CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Use Node.js
uses: actions/setup-node@v1
@@ -405,13 +405,12 @@ jobs:
- run: npm install
- run: npm run build
- run: npm test
```
```
{% endraw %}
</td>
</tr>
</table>
### Next steps
To continue learning about the main features of {% data variables.product.prodname_actions %}, see "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)."

8
content/actions/managing-workflow-runs/adding-a-workflow-status-badge.md
View File

@@ -34,7 +34,7 @@ https://github.com/<OWNER>/<REPOSITORY>/workflows/<WORKFLOW_FILE_PATH>/badge.svg
This Markdown example adds a status badge for a workflow with the name "Greet Everyone." The `OWNER` of the repository is the `actions` organization and the `REPOSITORY` name is `hello-world`.
```
```markdown
![example workflow name](https://github.com/actions/hello-world/workflows/Greet%20Everyone/badge.svg)
```
@@ -42,7 +42,7 @@ This Markdown example adds a status badge for a workflow with the name "Greet Ev
This Markdown example adds a status badge for a workflow with the file path `.github/workflows/main.yml`. The `OWNER` of the repository is the `actions` organization and the `REPOSITORY` name is `hello-world`.
```
```markdown
![example workflow file path](https://github.com/actions/hello-world/workflows/.github/workflows/main.yml/badge.svg)
```
@@ -50,7 +50,7 @@ This Markdown example adds a status badge for a workflow with the file path `.gi
This Markdown example adds a status badge for a branch with the name `feature-1`.
```
```markdown
![example branch parameter](https://github.com/actions/hello-world/workflows/Greet%20Everyone/badge.svg?branch=feature-1)
```
@@ -58,6 +58,6 @@ This Markdown example adds a status badge for a branch with the name `feature-1`
This Markdown example adds a badge that displays the status of workflow runs triggered by the `pull_request` event.
```
```markdown
![example event parameter](https://github.com/actions/hello-world/workflows/Greet%20Everyone/badge.svg?event=pull_request)
```

2
content/actions/managing-workflow-runs/manually-running-a-workflow.md
View File

@@ -18,7 +18,7 @@ To run a workflow manually, the workflow must be configured to run on the `workf
To trigger the `workflow_dispatch` event on {% data variables.product.prodname_dotcom %}, your workflow must be in the default branch. Follow these steps to manually trigger a workflow run.
{% data reusables.repositories.permissions-statement-read %}
{% data reusables.repositories.permissions-statement-write %}
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.actions-tab %}

4
content/actions/reference/workflow-commands-for-github-actions.md
View File

@@ -253,7 +253,7 @@ During the execution of a workflow, the runner generates temporary files that ca
**Warning:** Powershell does not use UTF-8 by default. Make sure you write files using the correct encoding. For example, you need to set UTF-8 encoding when you set the path:
```
```yaml
steps:
- run: echo "mypath" | Out-File -FilePath $env:GITHUB_PATH -Encoding utf8 -Append
```
@@ -287,7 +287,7 @@ For multiline strings, you may use a delimiter with the following syntax.
##### Example
In this example, we use `EOF` as a delimiter and set the `JSON_RESPONSE` environment variable to the value of the curl response.
```
```yaml
steps:
- name: Set the value
id: step_one

2
content/actions/reference/workflow-syntax-for-github-actions.md
View File

@@ -705,7 +705,7 @@ You can set the `shell` value to a template string using `command […options] {
For built-in shell keywords, we provide the following defaults that are executed by {% data variables.product.prodname_dotcom %}-hosted runners. You should use these guidelines when running shell scripts.
- `bash`/`sh`:
- Fail-fast behavior using `set -e o pipefail`: Default for `bash` and built-in `shell`. It is also the default when you don't provide an option on non-Windows platforms.
- Fail-fast behavior using `set -eo pipefail`: Default for `bash` and built-in `shell`. It is also the default when you don't provide an option on non-Windows platforms.
- You can opt out of fail-fast and take full control by providing a template string to the shell options. For example, `bash {0}`.
- sh-like shells exit with the exit code of the last command executed in a script, which is also the default behavior for actions. The runner will report the status of the step as fail/succeed based on this exit code.

10
content/admin/enterprise-management/evacuating-a-cluster-node.md
View File

@@ -25,9 +25,11 @@ If you're taking a node offline that has any data services (like git, pages, or
ghe-spokes evac-status
```
For {% data variables.product.prodname_pages %}
{% raw %}
```
echo "select count(*) from pages_replicas where host = 'pages-server-<uuid>'" | ghe-dbconsole -y
```
{% endraw %}
For storage
```
ghe-storage evacuation-status
@@ -36,18 +38,26 @@ If you're taking a node offline that has any data services (like git, pages, or
3. After the copying is complete, you can evacuate the storage service. Run any of the following commands:
For Git
{% raw %}
```
ghe-spokes server evacuate git-server-<uuid>
```
{% endraw %}
For {% data variables.product.prodname_pages %}
{% raw %}
```
ghe-dpages evacuate pages-server-<uuid>
```
{% endraw %}
For storage, take the node offline
{% raw %}
```
ghe-storage offline storage-server-<uuid>
```
{% endraw %}
then evacuate
{% raw %}
```
ghe-storage evacuate storage-server-<uuid>
```
{% endraw %}

2
content/admin/enterprise-management/initializing-the-cluster.md
View File

@@ -46,7 +46,7 @@ The names of the nodes can be any valid hostname you choose. The names are set a
Specify the first cluster node you configured as the MySQL primary via `mysql-server` and `mysql-master`.
```
```ini
[cluster]
mysql-master = ghe-data-node-1
redis-master = ghe-data-node-1

2
content/admin/github-actions/manually-syncing-actions-from-githubcom.md
View File

@@ -63,7 +63,7 @@ This example demonstrates using the `actions-sync` tool to sync an individual ac
* You can sync multiple actions by replacing the `--repo-name` parameter with `--repo-name-list` or `--repo-name-list-file`. For more information, see the [`actions-sync` README](https://github.com/actions/actions-sync#actions-sync).
1. After the action repository is created on your enterprise instance, people in your enterprise can use the destination repository to reference the action in their workflows. For the example action shown above:
```
```yaml
uses: synced-actions/docker-build-push-action@v1
```

40
content/admin/policies/creating-a-pre-receive-hook-script.md
View File

@@ -94,30 +94,30 @@ You can test a pre-receive hook script locally before you create or update it on
2. Create a file called `Dockerfile.dev` containing:
```
FROM gliderlabs/alpine:3.3
RUN \
apk add --no-cache git openssh bash && \
ssh-keygen -A && \
sed -i "s/#AuthorizedKeysFile/AuthorizedKeysFile/g" /etc/ssh/sshd_config && \
adduser git -D -G root -h /home/git -s /bin/bash && \
passwd -d git && \
su git -c "mkdir /home/git/.ssh && \
ssh-keygen -t ed25519 -f /home/git/.ssh/id_ed25519 -P '' && \
mv /home/git/.ssh/id_ed25519.pub /home/git/.ssh/authorized_keys && \
mkdir /home/git/test.git && \
git --bare init /home/git/test.git"
```dockerfile
FROM gliderlabs/alpine:3.3
RUN \
apk add --no-cache git openssh bash && \
ssh-keygen -A && \
sed -i "s/#AuthorizedKeysFile/AuthorizedKeysFile/g" /etc/ssh/sshd_config && \
adduser git -D -G root -h /home/git -s /bin/bash && \
passwd -d git && \
su git -c "mkdir /home/git/.ssh && \
ssh-keygen -t ed25519 -f /home/git/.ssh/id_ed25519 -P '' && \
mv /home/git/.ssh/id_ed25519.pub /home/git/.ssh/authorized_keys && \
mkdir /home/git/test.git && \
git --bare init /home/git/test.git"
VOLUME ["/home/git/.ssh", "/home/git/test.git/hooks"]
WORKDIR /home/git
VOLUME ["/home/git/.ssh", "/home/git/test.git/hooks"]
WORKDIR /home/git
CMD ["/usr/sbin/sshd", "-D"]
```
CMD ["/usr/sbin/sshd", "-D"]
```
3. Create a test pre-receive script called `always_reject.sh`. This example script will reject all pushes, which is useful for locking a repository:
3. Create a test pre-receive script called `always_reject.sh`. This example script will reject all pushes, which is useful for locking a repository:
```
#!/usr/bin/env bash
```shell
#!/usr/bin/env bash
echo "error: rejecting all pushes"
exit 1

4
content/admin/user-management/migrating-to-internal-repositories.md
View File

@@ -33,11 +33,11 @@ If you don't have private mode enabled, the migration script will have no effect
1. Connect to the administrative shell. For more information, see "[Accessing the administrative shell (SSH)](/enterprise/admin/installation/accessing-the-administrative-shell-ssh)."
2. Navigate to the `/data/github/current` directory.
```
```shell
cd /data/github/current
```
3. Run the migration command.
```
```shell
sudo bin/safe-ruby lib/github/transitions/20191210220630_convert_public_ghes_repos_to_internal.rb --verbose -w | tee -a /tmp/convert_public_ghes_repos_to_internal.log
```

4
content/developers/apps/creating-a-github-app-from-a-manifest.md
View File

@@ -80,7 +80,7 @@ Name | Type | Description
This example uses a form on a web page with a button that triggers the `POST` request for a user account:
```
```html
<form action="https://github.com/settings/apps/new?state=abc123" method="post">
Create a GitHub App Manifest: <input type="text" name="manifest" id="manifest"><br>
<input type="submit" value="Submit">
@@ -111,7 +111,7 @@ This example uses a form on a web page with a button that triggers the `POST` re
```
This example uses a form on a web page with a button that triggers the `POST` request for an organization account. Replace `ORGANIZATION` with the name of the organization account where you want to create the app.
```
```html
<form action="https://github.com/organizations/<em>ORGANIZATION</em>/settings/apps/new?state=abc123" method="post">
Create a GitHub App Manifest: <input type="text" name="manifest" id="manifest"><br>
<input type="submit" value="Submit">

4
content/developers/apps/creating-ci-tests-with-the-checks-api.md
View File

@@ -24,7 +24,7 @@ A CI server hosts code that runs CI tests such as code linters (which check styl
The [Checks API](/rest/reference/checks) allows you to set up CI tests that are automatically run against each code commit in a repository. The Checks API reports detailed information about each check on GitHub in the pull request's **Checks** tab. With the Checks API, you can create annotations with additional details for specific lines of code. Annotations are visible in the **Checks** tab. When you create an annotation for a file that is part of the pull request, the annotations are also shown in the **Files changed** tab.
A _check suite_ is a group of _check runs_ (individual CI tests). Both the suite and the runs contain _statuses_ that are visible in a pull request on GitHub. You can use statuses to determine when a code commit introduces errors. Using these statuses with [protected branches](/rest/reference/repos#branches) can prevent people from merging pull requests prematurely. See "[Enabling required status checks](/articles/enabling-required-status-checks/)" for more details.
A _check suite_ is a group of _check runs_ (individual CI tests). Both the suite and the runs contain _statuses_ that are visible in a pull request on GitHub. You can use statuses to determine when a code commit introduces errors. Using these statuses with [protected branches](/rest/reference/repos#branches) can prevent people from merging pull requests prematurely. See "[About protected branches](/github/administering-a-repository/about-protected-branches#require-status-checks-before-merging)" for more details.
The Checks API sends the [`check_suite` webhook event](/webhooks/event-payloads/#check_suite) to all GitHub Apps installed on a repository each time new code is pushed to the repository. To receive all Checks API event actions, the app must have the `checks:write` permission. GitHub automatically creates `check_suite` events for new code commits in a repository using the default flow, although [Update repository preferences for check suites](/rest/reference/checks#update-repository-preferences-for-check-suites) if you'd like. Here's how the default flow works:
@@ -724,7 +724,7 @@ To push to a repository, your app must have write permissions for "Repository co
In order to commit files, Git must know which [username](/articles/setting-your-username-in-git/) and [email](/articles/setting-your-commit-email-address-in-git/) to associate with the commit. Add two more environment variables in your `.env` file to store the name (`GITHUB_APP_USER_NAME`) and email (`GITHUB_APP_USER_EMAIL`) settings. Your name can be the name of your app and the email can be any email you'd like for this example. For example:
```
```ini
GITHUB_APP_USER_NAME=Octoapp
GITHUB_APP_USER_EMAIL=octoapp@octo-org.com
```

2
content/developers/apps/identifying-and-authorizing-users-for-github-apps.md
View File

@@ -89,7 +89,7 @@ Name | Type | Description
By default, the response takes the following form. The response parameters `expires_in`, `refresh_token`, and `refresh_token_expires_in` are only returned when you enable the beta for expiring user-to-server access tokens.
```
```json
{
"access_token": "e72e16c7e42f292c6912e7710c838347ae178b4a",
"expires_in": "28800",

77
content/developers/overview/secret-scanning.md
View File

@@ -1,6 +1,7 @@
---
title: Secret scanning
intro: 'As a service provider, you can partner with {% data variables.product.prodname_dotcom %} to have your secret token formats secured through secret scanning, which searches for accidental commits of your secret format and can be sent to a service provider''s verify endpoint.'
miniTocMaxHeadingLevel: 4
redirect_from:
- /partnerships/token-scanning/
- /partnerships/secret-scanning
@@ -8,52 +9,52 @@ versions:
free-pro-team: '*'
---
{% data variables.product.prodname_dotcom %} scans repositories for known secret formats to prevent fraudulent use of credentials that were committed accidentally. Secret scanning happens by default on public repositories, and can be enabled on private repositories by repository administrators or organization owners. As a service provider, you can partner with {% data variables.product.prodname_dotcom %} so that your secret formats are included in our secret scanning.
{% data variables.product.prodname_dotcom %} scans repositories for known secret formats to prevent fraudulent use of credentials that were committed accidentally. {% data variables.product.prodname_secret_scanning_caps %} happens by default on public repositories, and can be enabled on private repositories by repository administrators or organization owners. As a service provider, you can partner with {% data variables.product.prodname_dotcom %} so that your secret formats are included in our {% data variables.product.prodname_secret_scanning %}.
When a match of your secret format is found in a public repository, a payload is sent to an HTTP endpoint of your choice.
When a match of your secret format is found in a private repository configured for secret scanning, then repository admins are alerted and can view and manage the secret scanning results on {% data variables.product.prodname_dotcom %}. For more information, see "[Managing alerts from secret scanning](/github/administering-a-repository/managing-alerts-from-secret-scanning)".
When a match of your secret format is found in a private repository configured for {% data variables.product.prodname_secret_scanning %}, then repository admins are alerted and can view and manage the {% data variables.product.prodname_secret_scanning %} results on {% data variables.product.prodname_dotcom %}. For more information, see "[Managing alerts from {% data variables.product.prodname_secret_scanning %}](/github/administering-a-repository/managing-alerts-from-secret-scanning)."
{% note %}
**Note:** Secret scanning for private repositories is currently in beta.
**Note:** {% data variables.product.prodname_secret_scanning_caps %} for private repositories is currently in beta.
{% endnote %}
This article describes how you can partner with {% data variables.product.prodname_dotcom %} as a service provider and join the secret scanning program.
This article describes how you can partner with {% data variables.product.prodname_dotcom %} as a service provider and join the {% data variables.product.prodname_secret_scanning %} program.
### The secret scanning process
### The {% data variables.product.prodname_secret_scanning %} process
##### How secret scanning works in a public repository
##### How {% data variables.product.prodname_secret_scanning %} works in a public repository
The following diagram summarizes the secret scanning process for public repositories, with any matches sent to a service provider's verify endpoint.
The following diagram summarizes the {% data variables.product.prodname_secret_scanning %} process for public repositories, with any matches sent to a service provider's verify endpoint.
![Flow diagram showing the process of scanning for a secret and sending matches to a service provider's verify endpoint](/assets/images/secret-scanning-flow.png "Secret scanning flow")
![Flow diagram showing the process of scanning for a secret and sending matches to a service provider's verify endpoint](/assets/images/secret-scanning-flow.png "{% data variables.product.prodname_secret_scanning_caps %} flow")
### Joining the secret scanning program on {% data variables.product.prodname_dotcom %}
### Joining the {% data variables.product.prodname_secret_scanning %} program on {% data variables.product.prodname_dotcom %}
1. Contact {% data variables.product.prodname_dotcom %} to get the process started.
1. Identify the relevant secrets you want to scan for and create regular expressions to capture them.
1. For secret matches found in public repositories, create a secret alert service which accepts webhooks from {% data variables.product.prodname_dotcom %} that contain the secret scanning message payload.
1. For secret matches found in public repositories, create a secret alert service which accepts webhooks from {% data variables.product.prodname_dotcom %} that contain the {% data variables.product.prodname_secret_scanning %} message payload.
1. Implement signature verification in your secret alert service.
1. Implement secret revocation and user notification in your secret alert service.
1. Provide feedback for false positives (optional).
#### Contact {% data variables.product.prodname_dotcom %} to get the process started
To get the enrollment process started, email secret-scanning@github.com.
To get the enrollment process started, email <a href="mailto:secret-scanning@github.com">secret-scanning@github.com</a>.
You will receive details on the secret scanning program, and you will need to agree to {% data variables.product.prodname_dotcom %}'s terms of participation before proceeding.
You will receive details on the {% data variables.product.prodname_secret_scanning %} program, and you will need to agree to {% data variables.product.prodname_dotcom %}'s terms of participation before proceeding.
#### Identify your secrets and create regular expressions
To scan for your secrets, {% data variables.product.prodname_dotcom %} needs the following pieces of information for each secret that you want included in the secret scanning program:
To scan for your secrets, {% data variables.product.prodname_dotcom %} needs the following pieces of information for each secret that you want included in the {% data variables.product.prodname_secret_scanning %} program:
* A unique, human readable name for the secret type. We'll use this to generate the `Type` value in the message payload later.
* A regular expression which finds the secret type. Be as precise as possible, because this will reduce the number of false positives.
* The URL of the endpoint that receives messages from {% data variables.product.prodname_dotcom %}. This does not have to be unique for each secret type.
Send this information to secret-scanning@github.com.
Send this information to <a href="mailto:secret-scanning@github.com">secret-scanning@github.com</a>.
#### Create a secret alert service
@@ -61,7 +62,7 @@ Create a public, internet accessible HTTP endpoint at the URL you provided to us
##### Example POST sent to your endpoint
```
```http
POST / HTTP/1.1
Host: HOST
Accept: */*
@@ -95,7 +96,7 @@ Assuming you receive the following message, the code snippets below demonstrate
content-type: application/json
GITHUB-PUBLIC-KEY-IDENTIFIER: 90a421169f0a406205f1563a953312f0be898d3c7b6c06b681aa86a874555f4a
GITHUB-PUBLIC-KEY-SIGNATURE: MEUCICxTWEpKo7BorLKutFZDS6ie+YFg6ecU7kEA6rUUSJqsAiEA9bK0Iy6vk2QpZOOg2IpBhZ3JRVdwXx1zmgmNAR7Izpc=
```
Content-Length: 0000
```
@@ -279,4 +280,44 @@ puts openssl_key.verify(OpenSSL::Digest::SHA256.new, Base64.decode64(signature),
When we report secrets to you, we send a JSON array with each element containing the token, type identifier, and commit URL. When you send us feedback, you send us information about whether the detected token was a real or false credential. We accept feedback in the following formats.
For secret scanning in public repositories, you can enhance your secret alert service to revoke the exposed secrets and notify the affected users. How you implement this in your secret alert service is up to you, but we recommend considering any secrets that {% data variables.product.prodname_dotcom %} sends you messages about as public and compromised.
You can send us the raw token:
```
[
{
"token_raw": "The raw token",
"token_type": "ACompany_API_token",
"label": "true_positive"
}
]
```
You may also provide the token in hashed form after performing a one way cryptographic hash of the raw token using SHA-256:
```
[
{
"token_hash": "The SHA-256 hashed form of the raw token",
"token_type": "ACompany_API_token",
"label": "false_positive"
}
]
```
A few important points:
- You should only send us either the raw form of the token ("token_raw"), or the hashed form ("token_hash"), but not both.
- For the hashed form of the raw token, you can only use SHA-256 to hash the token, not any other hashing algorithm.
- The label indicates whether the token is a true ("true_positive") or a false positive ("false_positive"). Only these two lowercased literal strings are allowed.
{% note %}
**Note:** Our request timeout is set to be higher (that is, 30 seconds) for partners who provide data about false positives. If you require a timeout higher than 30 seconds, email us at <a href="mailto:secret-scanning@github.com">secret-scanning@github.com</a>.
{% endnote %}
- The label indicates whether the token is a true ("true_positive") or a false positive ("false_positive"). Only these two lowercased literal strings are allowed.
{% note %}
**Note:** Our request timeout is set to be higher (that is, 30 seconds) for partners who provide data about false positives. If you require a timeout higher than 30 seconds, email us at <a href="mailto:secret-scanning@github.com">secret-scanning@github.com</a>.
{% endnote %}

2
content/discussions/index.md
View File

@@ -43,7 +43,7 @@ versions:
{% render 'discussions-community-card' for discussionsCommunityExamples as example %}
</div>
{% if discussionsCommunityExamples.length > 6 %}
<button class="js-filter-card-show-more btn btn-outline float-right">Show more {% octicon "arrow-right" %}</button>
<button class="js-filter-card-show-more btn btn-outline float-right" data-js-filter-card-max="6">Show more {% octicon "arrow-right" %}</button>
{% endif %}
<div class="js-filter-card-no-results d-none py-4 text-center text-gray font-mktg">
<div class="mb-3">{% octicon "search" width="24" %}</div>

30
content/github/administering-a-repository/about-branch-restrictions.md
View File

@@ -1,30 +0,0 @@
---
title: About branch restrictions
intro: 'Branches within repositories that belong to organizations can be configured so that only certain users, teams, or apps can push to the branch.'
product: '{% data reusables.gated-features.branch-restrictions %}'
redirect_from:
- /articles/about-branch-restrictions
versions:
free-pro-team: '*'
enterprise-server: '*'
github-ae: '*'
---
When you enable branch restrictions, only users, teams, or apps that have been given permission can push to the protected branch. For more information, see "[Enabling branch restrictions](/articles/enabling-branch-restrictions)" and "[About protected branches](/articles/about-protected-branches)." You can view and edit the users, teams, or apps with push access to a protected branch in the protected branch's settings.
You can only give push access to a protected branch to users, teams, or installed {% data variables.product.prodname_github_apps %} with `write` access to a repository.
People and apps with admin permissions to a repository are always able to push to a protected branch.
{% tip %}
**Note:** If "Include administrators" is selected, you've enabled required status checks on the branch, and if any status checks fail, any attempt to push changes to the protected branch will also fail, even for people and apps with admin permissions. For more information, see "[Enabling required status checks](/articles/enabling-required-status-checks)."
{% endtip %}
### Further reading
- "[About protected branches](/articles/about-protected-branches)"
- "[Configuring protected branches](/articles/configuring-protected-branches)"
- "[About required status checks](/articles/about-required-status-checks)"
- "[Enabling required status checks](/articles/enabling-required-status-checks)"

2
content/github/administering-a-repository/about-merge-methods-on-github.md
View File

@@ -14,7 +14,7 @@ versions:
{% data reusables.pull_requests.default_merge_option %}
{% if currentVersion == "free-pro-team@latest" or currentVersion == "github-ae@latest" or currentVersion ver_gt "enterprise-server@2.19" %}
The default merge method creates a merge commit. You can prevent anyone from pushing merge commits to a protected branch by enforcing a linear commit history. For more information, see "[Requiring a linear commit history](/github/administering-a-repository/requiring-a-linear-commit-history)."{% endif %}
The default merge method creates a merge commit. You can prevent anyone from pushing merge commits to a protected branch by enforcing a linear commit history. For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches#require-linear-history)."{% endif %}
### Squashing your merge commits

131
content/github/administering-a-repository/about-protected-branches.md
View File

@@ -1,38 +1,141 @@
---
title: About protected branches
intro: 'Protected branches ensure that collaborators on your repository cannot make irrevocable changes to branches. Enabling protected branches also allows you to enable other optional checks and requirements, like required status checks and required reviews.'
intro: 'You can protect important branches by setting branch protection rules, which define whether collaborators can delete or force push to the branch and set requirements for any pushes to the branch, such as passing status checks or a linear commit history.'
product: '{% data reusables.gated-features.protected-branches %}'
redirect_from:
- /articles/about-protected-branches
- /enterprise/admin/developer-workflow/about-protected-branches-and-required-status-checks
- /articles/about-branch-restrictions
- /github/administering-a-repository/about-branch-restrictions
- /articles/about-required-status-checks
- /github/administering-a-repository/about-required-status-checks
- /articles/types-of-required-status-checks
- /github/administering-a-repository/types-of-required-status-checks
- /articles/about-required-commit-signing
- /github/administering-a-repository/about-required-commit-signing
- /articles/about-required-reviews-for-pull-requests
- /github/administering-a-repository/about-required-reviews-for-pull-requests
versions:
free-pro-team: '*'
enterprise-server: '*'
github-ae: '*'
---
### About protected branches
### About branch protection rules
{% data reusables.pull_requests.about-protected-branches %} You can choose to enforce restrictions on how a pull request is merged into your repository.
You can enforce certain workflows or requirements before a collaborator can push changes to a branch in your repository, including merging a pull request into the branch, by creating a branch protection rule.
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.
By default, each branch protection rule disables force pushes to the matching branches and prevents the matching branches from being deleted. You can optionally disable these restrictions and enable additional branch protection settings.
{% data reusables.repositories.branch-rules-example %} For more information, see "[Configuring protected branches](/articles/configuring-protected-branches/)."
By default, the restrictions of a branch protection rule don't apply to people with admin permissions to the repository. You can optionally choose to include administrators, too.
{% data reusables.repositories.branch-rules-example %} For more information about branch name patterns, see "[Managing a branch protection rule](/github/administering-a-repository/managing-a-branch-protection-rule)."
{% data reusables.pull_requests.you-can-auto-merge %}
### Prioritization of protected branch rules
### About branch protection settings
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.
For each branch protection rule, you can choose to enable or disable the following settings.
- [Require pull request reviews before merging](#require-pull-request-reviews-before-merging)
- [Require status checks before merging](#require-status-checks-before-merging)
- [Require signed commits](#require-signed-commits)
- [Require linear history](#require-linear-history)
- [Include administrators](#include-administrators)
- [Restrict who can push to matching branches](#restrict-who-can-push-to-matching-branches)
- [Allow force pushes](#allow-force-pushes)
- [Allow deletions](#allow-deletions)
Protected branch rules that mention a special character, such as `*`, `?`, or `]`, are applied in the order they were created, so older rules with these characters have a higher priority.
#### Require pull request reviews before merging
### Branch protection settings
{% data reusables.pull_requests.required-reviews-for-prs-summary %}
When you create a branch protection rule in a repository, collaborators cannot force push to the protected branch or delete the branch{% if currentVersion == "free-pro-team@latest" %} by default{% endif %}. You can enable other branch protection settings. For information, see "[Defining the mergeability of pull requests](/github/administering-a-repository/defining-the-mergeability-of-pull-requests)."
If you enable required reviews, collaborators can only push changes to a protected branch via a pull request that is approved by the required number of reviewers with write permissions.
### Further reading
If a person with admin permissions chooses the **Request changes** option in a review, then that person must approve the pull request before the pull request can be merged. If a reviewer who requests changes on a pull request isn't available, anyone with write permissions for the repository can dismiss the blocking review.
- "[About required status checks](/articles/about-required-status-checks)"
- "[About required reviews for pull requests](/articles/about-required-reviews-for-pull-requests)"
- "[About required commit signing](/articles/about-required-commit-signing)"
{% data reusables.repositories.review-policy-overlapping-commits %}
If a collaborator attempts to merge a pull request with pending or rejected reviews into the protected branch, the collaborator will receive an error message.
```shell
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Changes have been requested.
```
Optionally, you can choose to dismiss stale pull request approvals when commits are pushed. If anyone pushes a commit that modifies code to an approved pull request, the approval will be dismissed, and the pull request cannot be merged. This doesn't apply if the collaborator pushes commits that don't modify code, like merging the base branch into the pull request's branch. For information about the base branch, see "[About pull requests](/articles/about-pull-requests)."
Optionally, you can restrict the ability to dismiss pull request reviews to specific people or teams. For more information, see "[Dismissing a pull request review](/articles/dismissing-a-pull-request-review)."
Optionally, you can choose to require reviews from code owners. If you do, any pull request that affects code with a code owner must be approved by that code owner before the pull request can be merged into the protected branch.
#### Require status checks before merging
Required status checks ensure that all required CI tests are passing before collaborators can make changes to a protected branch. Required status checks can be checks or statuses. For more information, see "[About status checks](/github/collaborating-with-issues-and-pull-requests/about-status-checks)."
Before you can enable required status checks, you must configure the repository to use the status API. For more information, see "[Repositories](/rest/reference/repos#statuses)" in the REST documentation.
After enabling required status checks, all required status checks must pass before collaborators can merge changes into the protected branch. After all required status checks pass, any commits must either be pushed to another branch and then merged or pushed directly to the protected branch.
{% note %}
**Note:** Any person or integration with write permissions to a repository can set the state of any status check in the repository. {% data variables.product.company_short %} does not verify that the author of a check is authorized to create a check with a certain name or modify an existing status. Before merging a pull request, you should verify that the author of each status, listed in the merge box, is expected.
{% endnote %}
You can set up required status checks to either be "loose" or "strict." The type of required status check you choose determines whether your branch is required to be up-to-date with the base branch before merging.
| Type of required status check | Setting | Merge requirements | Considerations |
| --- | --- | --- | --- |
| **Strict** | The **Require branches to be up-to-date before merging** checkbox is checked. | The branch **must** be up to date with the base branch before merging. | This is the default behavior for required status checks. More builds may be required, as you'll need to bring the head branch up to date after other collaborators merge pull requests to the protected base branch.|
| **Loose** | The **Require branches to be up-to-date before merging** checkbox is **not** checked. | The branch **does not** have to be up to date with the base branch before merging. | You'll have fewer required builds, as you won't need to bring the head branch up to date after other collaborators merge pull requests. Status checks may fail after you merge your branch if there are incompatible changes with the base branch. |
| **Disabled** | The **Require status checks to pass before merging** checkbox is **not** checked. | The branch has no merge restrictions. | If required status checks aren't enabled, collaborators can merge the branch at any time, regardless of whether it is up to date with the base branch. This increases the possibility of incompatible changes.
For troubleshooting information, see "[Troubleshooting required status checks](/github/administering-a-repository/troubleshooting-required-status-checks)."
#### Require signed commits
When you enable required commit signing on a branch, contributors {% if currentVersion == "free-pro-team@latest" %}and bots{% endif %} can only push commits that have been signed and verified to the branch. For more information, see "[About commit signature verification](/articles/about-commit-signature-verification)."
{% note %}
**Note:** If a collaborator pushes an unsigned commit to a branch that requires commit signatures, the collaborator will need to rebase the commit to include a verified signature, then force push the rewritten commit to the branch.
{% endnote %}
You can always push local commits to the branch if the commits are signed and verified. {% if currentVersion == "free-pro-team@latest" %}You can also merge signed and verified commits into the branch using a pull request on {% data variables.product.product_name %}. However, you cannot squash and merge a pull request into the branch on {% data variables.product.product_name %} unless you are the author of the pull request.{% else %} However, you cannot merge pull requests into the branch on {% data variables.product.product_name %}.{% endif %} You can {% if currentVersion == "free-pro-team@latest" %}squash and {% endif %}merge pull requests locally. For more information, see "[Checking out pull requests locally](/github/collaborating-with-issues-and-pull-requests/checking-out-pull-requests-locally)."
{% if currentVersion == "free-pro-team@latest" %} For more information about merge methods, see "[About merge methods on {% data variables.product.prodname_dotcom %}](/github/administering-a-repository/about-merge-methods-on-github)."{% endif %}
#### Require linear history
Enforcing a linear commit history prevents collaborators from pushing merge commits to the branch. This means that any pull requests merged into the protected branch must use a squash merge or a rebase merge. A strictly linear commit history can help teams reverse changes more easily. For more information about merge methods, see "[About pull request merges](/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges)."
Before you can require a linear commit history, your repository must allow squash merging or rebase merging. For more information, see "[Configuring pull request merges](/github/administering-a-repository/configuring-pull-request-merges)."
#### Include administrators
By default, protected branch rules do not apply to people with admin permissions to a repository. You can enable this setting to include administrators in your protected branch rules.
#### Restrict who can push to matching branches
{% if currentVersion == "free-pro-team@latest" %}
You can enable branch restrictions if your repository is owned by an organization using {% data variables.product.prodname_team %} or {% data variables.product.prodname_ghe_cloud %}.
{% endif %}
When you enable branch restrictions, only users, teams, or apps that have been given permission can push to the protected branch. You can view and edit the users, teams, or apps with push access to a protected branch in the protected branch's settings.
You can only give push access to a protected branch to users, teams, or installed {% data variables.product.prodname_github_apps %} with write access to a repository. People and apps with admin permissions to a repository are always able to push to a protected branch.
#### Allow force pushes
By default, {% data variables.product.product_name %} blocks force pushes on all protected branches. When you enable force pushes to a protected branch, anyone with at least write permissions to the repository can force push to the branch, including those with admin permissions.
Enabling force pushes will not override any other branch protection rules. For example, if a branch requires a linear commit history, you cannot force push merge commits to that branch.
{% if enterpriseServerVersions contains currentVersion or currentVersion == "github-ae@latest" %}You cannot enable force pushes for a protected branch if a site administrator has blocked force pushes to all branches in your repository. For more information, see "[Blocking force pushes to repositories owned by a user account or organization](/enterprise/{{ currentVersion }}/admin/developer-workflow/blocking-force-pushes-to-repositories-owned-by-a-user-account-or-organization)."
If a site administrator has blocked force pushes to the default branch only, you can still enable force pushes for any other protected branch.{% endif %}
#### Allow deletions
By default, you cannot delete a protected branch. When you enable deletion of a protected branch, anyone with at least write permissions to the repository can delete the branch.

29
content/github/administering-a-repository/about-required-commit-signing.md
View File

@@ -1,29 +0,0 @@
---
title: About required commit signing
intro: Required commit signing ensures that collaborators can only push verified signed commits to a protected branch.
product: '{% data reusables.gated-features.protected-branches %}'
redirect_from:
- /articles/about-required-commit-signing
versions:
free-pro-team: '*'
enterprise-server: '*'
github-ae: '*'
---
If you've enforced branch protections in your repository, you can set up required commit signing. For more information, see "[Configuring protected branches](/articles/configuring-protected-branches/)."
When you enable required commit signing on a branch, contributors {% if currentVersion == "free-pro-team@latest" %}and bots{% endif %} can only push commits that have been signed and verified to the branch. For more information, see "[About commit signature verification](/articles/about-commit-signature-verification)."
You can always push local commits to the branch if the commits are signed and verified. {% if currentVersion == "free-pro-team@latest" %}You can also merge signed and verified commits into the branch using a pull request on {% data variables.product.product_name %}. However, you cannot squash and merge a pull request into the branch on {% data variables.product.product_name %} unless you are the author of the pull request.{% else %} However, you cannot merge pull requests into the branch on {% data variables.product.product_name %}.{% endif %} You can {% if currentVersion == "free-pro-team@latest" %}squash and {% endif %}merge pull requests locally. For more information, see "[Checking out pull requests locally](/github/collaborating-with-issues-and-pull-requests/checking-out-pull-requests-locally)."{% if currentVersion == "free-pro-team@latest" %} For more information about merge methods, see "[About merge methods on {% data variables.product.prodname_dotcom %}](/github/administering-a-repository/about-merge-methods-on-github)."{% endif %}
{% note %}
**Note:** Enabling required commit signing on a branch will make it more difficult to contribute. If a collaborator pushes an unsigned commit to a branch that has required commit signing enabled, they will need to rebase their commit to include a verified signature and force push the rewritten commit to the branch.
{% endnote %}
Administrators of a repository can push local commits that have not been signed and verified, however you can require administrators to be subject to required commit signing. For more information, see "[Enabling required commit signing](/articles/enabling-required-commit-signing)."
### Further reading
- "[About protected branches](/articles/about-protected-branches)"

36
content/github/administering-a-repository/about-required-reviews-for-pull-requests.md
View File

@@ -1,36 +0,0 @@
---
title: About required reviews for pull requests
intro: Required reviews ensure that pull requests have a specific number of approving reviews before collaborators can make changes to a protected branch.
product: '{% data reusables.gated-features.protected-branches %}'
redirect_from:
- /articles/about-required-reviews-for-pull-requests
versions:
free-pro-team: '*'
enterprise-server: '*'
github-ae: '*'
---
If you've enforced branch protections in your repository, you can set up required reviews. For more information about enforcing branch protections, see "[Configuring protected branches](/articles/configuring-protected-branches/)." For more information about setting up required reviews, see "[Enabling required reviews for pull requests](/articles/enabling-required-reviews-for-pull-requests)."
{% data reusables.pull_requests.required-reviews-for-prs-summary %}
If a person with *admin* permissions chooses the **Request changes** option in a review, then that person must approve the pull request before it can be merged. If a reviewer who requests changes on a pull request isn't available, anyone with *admin* or *write* permission for the repository can dismiss the blocking review. For more information, see "[Dismissing a pull request review](/articles/dismissing-a-pull-request-review)."
{% note %}
**Note:** Repository admins can restrict the ability to dismiss pull request reviews to specific people or teams. For more information, see "[Enabling required reviews for pull requests](/articles/enabling-required-reviews-for-pull-requests)."
{% endnote %}
If you push a code-modifying commit to the branch of an approved pull request, the approval may be dismissed if repository admins have set up stale review dismissals. For more information, see "[Enabling required reviews for pull requests](/articles/enabling-required-reviews-for-pull-requests)." This doesn't apply if you push non-code-modifying commits, like merging the base branch into your pull request's branch. For information about the base branch, see "[About pull requests](/articles/about-pull-requests)."
Unless required reviews have been set up to include repository admins, people with *admin* permissions can merge a pull request regardless of reviews from other admins.
{% data reusables.repositories.review-policy-overlapping-commits %}
You can't merge a pull request into a protected branch until someone with *write* or *admin* permissions approves it. If there are pending or rejected reviews, you'll receive an error message:
```shell
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Changes have been requested.
```

72
content/github/administering-a-repository/about-required-status-checks.md
View File

@@ -1,72 +0,0 @@
---
title: About required status checks
intro: Required status checks ensure that all required CI tests are passing before collaborators can make changes to a protected branch.
product: '{% data reusables.gated-features.protected-branches %}'
redirect_from:
- /articles/about-required-status-checks
versions:
free-pro-team: '*'
enterprise-server: '*'
github-ae: '*'
---
### About required status checks
If you've enforced branch protections in your repository, you can set up required status checks. For more information, see "[Configuring protected branches](/articles/configuring-protected-branches/)" and "[Enabling required status checks](/articles/enabling-required-status-checks)." Required status checks can be checks or statuses. For more information, see "[About status checks](/github/administering-a-repository/enabling-required-status-checks)."
After enabling required status checks, all required status checks must pass before branches can be merged into the protected branch. After all required status checks pass, any commits must either be pushed to another branch and then merged or pushed directly to the protected branch.
![Merge protected branch ](/assets/images/help/repository/req-status-check-all-passed.png)
{% tip %}
**Note:** Any person or integration with write permissions to a repository can set the state of any status check in the repository. {% data variables.product.product_name %} does not verify that the author of a check is authorized to create a check with a certain name or modify an existing status. Before merging a pull request, you should verify that the author of each status, listed in the merge box, is expected.
{% endtip %}
Administrators of a repository can merge a protected branch even if required status checks have failed or are pending. You can require administrators to be subject to required status checks. For more information, see "[Enabling required status checks](/github/administering-a-repository/enabling-required-status-checks)."
![Administrator merge of protected branch](/assets/images/help/repository/req-status-check-admin-merge.png)
Administrators can also merge a protected branch even if the branch is out of date with the base branch.
### Required status checks settings
You can set up either loose or strict status checks, depending on whether you want to require your branch to be up to date with the base branch before merging. For more information, see "[Types of required status checks](/github/administering-a-repository/types-of-required-status-checks)."
### Troubleshooting required status checks
If you have a check and a status with the same name and you select that name as a required status check, both the check and the status are required. For more information, see "[Checks](/rest/reference/checks)."
Once you've set up required status checks, your branch must be up to date with the base branch before merging. This ensures that your branch has been tested with the latest code from the base branch. If your branch is out of date, you'll need to merge the base branch into your branch.
{% note %}
**Note:** You can also bring your branch up to date with the base branch using Git rebase. For more information, see "[About Git rebase](/github/using-git/about-git-rebase)."
{% endnote %}
![Out-of-date branch](/assets/images/help/repository/req-status-check-out-of-date.png)
You won't be able to push local changes to a protected branch until all required status checks pass. Instead, you'll receive an error message similar to the following:
```shell
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Required status check "ci-build" is failing
```
{% note %}
**Note:** Pull requests that are up to date and pass required status checks can be merged locally and pushed to the protected branch. This can be done without status checks running on the merge commit itself.
{% endnote %}
{% if currentVersion == "free-pro-team@latest" or currentVersion == "github-ae@latest" or currentVersion ver_gt "enterprise-server@2.20" %}
Sometimes, the results of the status checks for the test merge commit and head commit will conflict. If the test merge commit has a status, it must pass. Otherwise, the status of the head commit must pass before you can merge the branch. For more information about test merge commits, see "[Pull Requests](/rest/reference/pulls#response-1)."
![Branch with conflicting merge commits](/assets/images/help/repository/req-status-check-conflicting-merge-commits.png)
{% endif %}
### Further reading
- "[About status checks](/github/collaborating-with-issues-and-pull-requests/about-status-checks)"

42
content/github/administering-a-repository/configuring-protected-branches.md
View File

@@ -1,42 +0,0 @@
---
title: Configuring protected branches
intro: 'If you''re a repository owner or have admin permissions in a repository, you can customize branch protections in the repository and enforce certain workflows, such as requiring more than one pull request review or requiring certain status checks to pass before allowing a pull request to merge.'
product: '{% data reusables.gated-features.protected-branches %}'
redirect_from:
- /articles/configuring-protected-branches
- /enterprise/admin/developer-workflow/configuring-protected-branches-and-required-status-checks
versions:
free-pro-team: '*'
enterprise-server: '*'
github-ae: '*'
---
{% data reusables.repositories.branch-rules-example %}
You can also set up automatic branch protection for all branches in your repository with the wildcard syntax `*`. Because {% data variables.product.prodname_dotcom %} uses the `File::FNM_PATHNAME` flag for the `File.fnmatch` syntax, the wildcard does not match directory separators (`/`). For example, `qa/*` will match all branches beginning with `qa/` and containing a single slash. You can include multiple slashes with `qa/**/*`, and you can extend the `qa` string with `qa**/**/*` to make it more inclusive. For more information about syntax options for branch rules, see the [fnmatch documentation](https://ruby-doc.org/core-2.5.1/File.html#method-c-fnmatch).
To create an exception to an existing branch rule, you can create a new branch protection rule that is higher priority, such as a branch rule for a specific branch name. For more information about the priority order and other settings for protected branch rules, see "[About protected branches](/github/administering-a-repository/about-protected-branches)."
{% note %}
**Note:** To create a branch rule, the branch you specify doesn't have to exist yet in the repository.
{% endnote %}
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-settings %}
{% data reusables.repositories.repository-branches %}
{% data reusables.repositories.add-branch-protection-rules %}
6. Optionally, you can configure specific branch rule settings.
![Protected branch rule settings](/assets/images/help/branches/branch-rule-settings.png)
7. To confirm your branch protection rule, click **Create** or **Save changes.**
### Further reading
- "[About protected branches](/github/administering-a-repository/about-protected-branches)"
- "[About required status checks](/github/administering-a-repository/about-required-status-checks)"
- "[Enabling required status checks](/github/administering-a-repository/enabling-required-status-checks)"
- "[About branch restrictions](/github/administering-a-repository/about-branch-restrictions)"
- "[Enabling branch restrictions](/github/administering-a-repository/enabling-branch-restrictions)"
- "[About required commit signing](/github/administering-a-repository/about-required-commit-signing)"

33
content/github/administering-a-repository/enabling-branch-restrictions.md
View File

@@ -1,33 +0,0 @@
---
title: Enabling branch restrictions
intro: 'You can enforce branch restrictions so that only certain users, teams, or apps can push to a protected branch in repositories owned by your organization.'
product: '{% data reusables.gated-features.branch-restrictions %}'
redirect_from:
- /articles/enabling-branch-restrictions
versions:
free-pro-team: '*'
enterprise-server: '*'
github-ae: '*'
---
Anyone with admin permissions to an organization-owned repository can enable branch restrictions.
{% data reusables.repositories.protected-branches-options %}
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-settings %}
{% data reusables.repositories.repository-branches %}
{% data reusables.repositories.add-branch-protection-rules %}
{% data reusables.repositories.include-administrators %}
6. Under "Protect matching branches", select **Restrict who can push to matching branches**.
![Branch restriction checkbox](/assets/images/help/repository/restrict-branch.png)
8. Search for and select the people, teams, or apps who will have permission to push to the protected branch.
![Branch restriction search](/assets/images/help/repository/restrict-branch-search.png)
9. Click **Create**.
### Further reading
- "[About protected branches](/github/administering-a-repository/about-protected-branches)"
- "[Configuring protected branches](/github/administering-a-repository/configuring-protected-branches)"
- "[About required status checks](/github/administering-a-repository/about-required-status-checks)"
- "[Enabling required status checks](/github/administering-a-repository/enabling-required-status-checks)"

23
content/github/administering-a-repository/enabling-deletion-of-a-protected-branch.md
View File

@@ -1,23 +0,0 @@
---
title: Enabling deletion of a protected branch
intro: You can allow anyone with write access for a repository to delete a protected branch.
product: '{% data reusables.gated-features.protected-branches %}'
versions:
free-pro-team: '*'
enterprise-server: '>=2.20'
github-ae: '*'
---
Anyone with admin permissions to a repository can enable branch deletions.
By default, you cannot delete a protected branch. When you enable deletion to a protected branch, anyone with at least write permissions to the repository can delete the branch, including those with admin permissions.
{% data reusables.repositories.protected-branches-options %}
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-settings %}
{% data reusables.repositories.repository-branches %}
{% data reusables.repositories.add-branch-protection-rules %}
6. Under "Rules applied to everyone including administrators", select **Allow deletions**.
![Allow branch deletions option](/assets/images/help/repository/allow-branch-deletions.png)
7. Click **Create**.

33
content/github/administering-a-repository/enabling-force-pushes-to-a-protected-branch.md
View File

@@ -1,33 +0,0 @@
---
title: Enabling force pushes to a protected branch
intro: You can allow force pushes to a protected branch.
product: '{% data reusables.gated-features.protected-branches %}'
versions:
free-pro-team: '*'
enterprise-server: '>=2.20'
github-ae: '*'
---
Anyone with admin permissions to a repository can enable force pushes.
### About force pushes to protected branches
By default, force pushes are blocked on all protected branches. When you enable force pushes to a protected branch, anyone with at least write permissions to the repository can force push to the branch, including those with admin permissions.
Enabling force pushes will not override any other branch protection rules. For example, if a branch requires a linear commit history, you cannot force push merge commits to that branch.
{% if enterpriseServerVersions contains currentVersion or currentVersion == "github-ae@latest" %}You cannot enable force pushes for a protected branch if a site administrator has blocked force pushes to all branches in your repository. For more information, see "[Blocking force pushes to repositories owned by a user account or organization](/enterprise/{{ currentVersion }}/admin/developer-workflow/blocking-force-pushes-to-repositories-owned-by-a-user-account-or-organization)."
If a site administrator has blocked force pushes to the default branch only, you can still enable force pushes for any other protected branch.{% endif %}
{% data reusables.repositories.protected-branches-options %}
### Enabling force pushes
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-settings %}
{% data reusables.repositories.repository-branches %}
{% data reusables.repositories.add-branch-protection-rules %}
6. Under "Rules applied to everyone including administrators", select **Allow force pushes**.
![Allow force pushes option](/assets/images/help/repository/allow-force-pushes.png)
7. Click **Create**.

25
content/github/administering-a-repository/enabling-required-commit-signing.md
View File

@@ -1,25 +0,0 @@
---
title: Enabling required commit signing
intro: Repository administrators can enforce required commit signing on a branch to block all commits that are not signed and verified.
product: '{% data reusables.gated-features.protected-branches %}'
redirect_from:
- /articles/enabling-required-commit-signing
versions:
free-pro-team: '*'
enterprise-server: '*'
github-ae: '*'
---
Before enabling required commit signing on a branch, you must first set the branch up as a protected branch. For more information, see "[Configuring protected branches](/github/administering-a-repository/configuring-protected-branches)."
{% data reusables.repositories.protected-branches-options %}
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-settings %}
{% data reusables.repositories.repository-branches %}
{% data reusables.repositories.add-branch-protection-rules %}
5. Select **Require signed commits**.
![Require signed commits option](/assets/images/help/repository/require-signed-commits.png)
6. Optionally, select **Include administrators**. This enforces the required signed commits on the repository administrators.
![Include administrators checkbox](/assets/images/help/repository/include-admins-protected-branches.png)
7. Click **Create**.

38
content/github/administering-a-repository/enabling-required-reviews-for-pull-requests.md
View File

@@ -1,38 +0,0 @@
---
title: Enabling required reviews for pull requests
intro: Repository administrators can enforce required reviews so that pull requests must have a specific number of approving reviews before they are merged.
product: '{% data reusables.gated-features.protected-branches %}'
redirect_from:
- /articles/enabling-required-reviews-for-pull-requests
versions:
free-pro-team: '*'
enterprise-server: '*'
github-ae: '*'
---
Before enabling required reviews on a branch, you must first set the branch up as a protected branch. For more information, see "[Configuring protected branches](/github/administering-a-repository/configuring-protected-branches)."
{% data reusables.repositories.protected-branches-options %}
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-settings %}
{% data reusables.repositories.repository-branches %}
{% data reusables.repositories.add-branch-protection-rules %}
5. Select **Require pull request reviews before merging**.
![Pull request review restriction checkbox](/assets/images/help/repository/PR-reviews-required.png)
6. In the Required approving reviews drop-down menu, select the number of approving reviews you'd like to require on the branch.
![Drop-down menu to select number of required review approvals](/assets/images/help/repository/number-of-required-review-approvals.png)
7. Optionally, select **Dismiss stale pull request approvals when new commits are pushed**. This dismisses a pull request approval review when a code-modifying commit is pushed to the branch.
![Dismiss stale pull request approvals when new commits are pushed checkbox](/assets/images/help/repository/PR-reviews-required-dismiss-stale.png)
8. Optionally, select **Require review from Code Owners** to require review from a code owner when the pull request affects code that has a designated owner. For more information, see "[About code owners](/github/creating-cloning-and-archiving-repositories/about-code-owners)."
![Require review from code owners](/assets/images/help/repository/PR-review-required-code-owner.png)
9. Optionally, if the repository is part of an organization, select **Restrict who can dismiss pull request reviews** to search for and select the people or teams who can dismiss pull request reviews. For more information, see "[Dismissing a pull request review](/github/collaborating-with-issues-and-pull-requests/dismissing-a-pull-request-review)." This option is not available for personal repositories.
![Restrict who can dismiss pull request reviews checkbox](/assets/images/help/repository/PR-review-required-dismissals.png)
{% data reusables.repositories.include-administrators %}
11. Click **Create**.
### Further reading
- "[About required reviews for pull requests](/github/administering-a-repository/about-required-reviews-for-pull-requests)"
- "[About protected branches](/github/administering-a-repository/about-protected-branches)"
- "[About required status checks](/github/administering-a-repository/about-required-status-checks)"

30
content/github/administering-a-repository/enabling-required-status-checks.md
View File

@@ -1,30 +0,0 @@
---
title: Enabling required status checks
intro: Repository administrators can enforce required status checks before a branch is merged in a pull request or before commits on a local branch can be pushed to the protected remote branch.
product: '{% data reusables.gated-features.protected-branches %}'
redirect_from:
- /articles/enabling-required-status-checks
versions:
free-pro-team: '*'
enterprise-server: '*'
github-ae: '*'
---
{% data reusables.repositories.protected-branches-options %}
Before you can enable required status checks, you must configure the repository to use the status API. For more information, see "[Building a CI Server](/guides/building-a-ci-server/)."
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-settings %}
{% data reusables.repositories.repository-branches %}
{% data reusables.repositories.add-branch-protection-rules %}
6. Under "Protect matching branches", select **Require status checks to pass before merging**.
![Required status checks option](/assets/images/help/repository/required-status-checks.png)
7. Optionally, select **Require branches to be up to date before merging**. If selected, this ensures that the branch is tested with the latest code on the base branch.
![Loose or strict required status checkbox](/assets/images/help/repository/protecting-branch-loose-status.png)
7. From the list of available status checks, select the checks you want to require.
![List of available status checks](/assets/images/help/repository/required-statuses-list.png)
{% data reusables.repositories.include-administrators %}
9. Click **Create**.
{% data reusables.repositories.required-status-merge-tip %}

15
content/github/administering-a-repository/index.md
View File

@@ -44,19 +44,8 @@ versions:
{% 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 %}
{% link_in_list /configuring-protected-branches %}
{% link_in_list /about-required-status-checks %}
{% link_in_list /types-of-required-status-checks %}
{% link_in_list /enabling-required-status-checks %}
{% link_in_list /about-branch-restrictions %}
{% link_in_list /enabling-branch-restrictions %}
{% link_in_list /about-required-reviews-for-pull-requests %}
{% link_in_list /enabling-required-reviews-for-pull-requests %}
{% link_in_list /about-required-commit-signing %}
{% link_in_list /enabling-required-commit-signing %}
{% link_in_list /requiring-a-linear-commit-history %}
{% link_in_list /enabling-force-pushes-to-a-protected-branch %}
{% link_in_list /enabling-deletion-of-a-protected-branch %}
{% link_in_list /managing-a-branch-protection-rule %}
{% link_in_list /troubleshooting-required-status-checks %}
{% topic_link_in_list /releasing-projects-on-github %}
{% link_in_list /about-releases %}
{% link_in_list /managing-releases-in-a-repository %}

100
content/github/administering-a-repository/managing-a-branch-protection-rule.md Normal file
View File

@@ -0,0 +1,100 @@
---
title: Managing a branch protection rule
intro: 'You can create a branch protection rule to enforce certain workflows for one or more branches, such as requiring an approving review or passing status checks for all pull requests merged into the protected branch.'
product: '{% data reusables.gated-features.protected-branches %}'
redirect_from:
- /articles/configuring-protected-branches
- /enterprise/admin/developer-workflow/configuring-protected-branches-and-required-status-checks
- /articles/enabling-required-status-checks
- /github/administering-a-repository/enabling-required-status-checks
- /articles/enabling-branch-restrictions
- /github/administering-a-repository/enabling-branch-restrictions
- /articles/enabling-required-reviews-for-pull-requests
- /github/administering-a-repository/enabling-required-reviews-for-pull-requests
- /articles/enabling-required-commit-signing
- /github/administering-a-repository/enabling-required-commit-signing
- /github/administering-a-repository/requiring-a-linear-commit-history
- /github/administering-a-repository/enabling-force-pushes-to-a-protected-branch
- /github/administering-a-repository/enabling-deletion-of-a-protected-branch
versions:
free-pro-team: '*'
enterprise-server: '*'
github-ae: '*'
permissions: People with admin permissions to a repository can manage branch protection rules.
---
### About branch protection rules
{% data reusables.repositories.branch-rules-example %}
You can create a rule for all current and future branches in your repository with the wildcard syntax `*`. Because {% data variables.product.company_short %} uses the `File::FNM_PATHNAME` flag for the `File.fnmatch` syntax, the wildcard does not match directory separators (`/`). For example, `qa/*` will match all branches beginning with `qa/` and containing a single slash. You can include multiple slashes with `qa/**/*`, and you can extend the `qa` string with `qa**/**/*` to make the rule more inclusive. For more information about syntax options for branch rules, see the [fnmatch documentation](https://ruby-doc.org/core-2.5.1/File.html#method-c-fnmatch).
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.
Protected branch rules that mention a special character, such as `*`, `?`, or `]`, are applied in the order they were created, so older rules with these characters have a higher priority.
To create an exception to an existing branch rule, you can create a new branch protection rule that is higher priority, such as a branch rule for a specific branch name.
For more information about each of each of the available branch protection settings, see "[About protected branches](/github/administering-a-repository/about-protected-branches)."
### Creating a branch protection rule
When you create a branch rule, the branch you specify doesn't have to exist yet in the repository.
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-settings %}
{% data reusables.repositories.repository-branches %}
{% data reusables.repositories.add-branch-protection-rules %}
1. Optionally, enable required pull request reviews.
- Under "Protect matching branches", select **Require pull request reviews before merging**.
![Pull request review restriction checkbox](/assets/images/help/repository/PR-reviews-required.png)
- Click the **Required approving reviews** drop-down menu, then select the number of approving reviews you'd like to require on the branch.
![Drop-down menu to select number of required review approvals](/assets/images/help/repository/number-of-required-review-approvals.png)
- Optionally, to dismiss a pull request approval review when a code-modifying commit is pushed to the branch, select **Dismiss stale pull request approvals when new commits are pushed**.
![Dismiss stale pull request approvals when new commits are pushed checkbox](/assets/images/help/repository/PR-reviews-required-dismiss-stale.png)
- Optionally, to require review from a code owner when the pull request affects code that has a designated owner, select **Require review from Code Owners**. For more information, see "[About code owners](/github/creating-cloning-and-archiving-repositories/about-code-owners)."
![Require review from code owners](/assets/images/help/repository/PR-review-required-code-owner.png)
- Optionally, if the repository is part of an organization, select **Restrict who can dismiss pull request reviews**. Then, search for and select the people or teams who are allowed to dismiss pull request reviews. For more information, see "[Dismissing a pull request review](/github/collaborating-with-issues-and-pull-requests/dismissing-a-pull-request-review)."
![Restrict who can dismiss pull request reviews checkbox](/assets/images/help/repository/PR-review-required-dismissals.png)
1. Optionally, enable required status checks.
- Select **Require status checks to pass before merging**.
![Required status checks option](/assets/images/help/repository/required-status-checks.png)
- Optionally, to ensure that pull requests are tested with the latest code on the protected branch, select **Require branches to be up to date before merging**.
![Loose or strict required status checkbox](/assets/images/help/repository/protecting-branch-loose-status.png)
- From the list of available status checks, select the checks you want to require.
![List of available status checks](/assets/images/help/repository/required-statuses-list.png)
1. Optionally, select **Require signed commits**.
![Require signed commits option](/assets/images/help/repository/require-signed-commits.png)
1. Optionally, select **Require linear history**.
![Required linear history option](/assets/images/help/repository/required-linear-history.png)
1. Optionally, select **Include administrators**.
![Include administrators checkbox](/assets/images/help/repository/include-admins-protected-branches.png)
1. Optionally,{% if currentVersion == "free-pro-team@latest" %} if your repository is owned by an organization using {% data variables.product.prodname_team %} or {% data variables.product.prodname_ghe_cloud %},{% endif %} enable branch restrictions.
- Select **Restrict who can push to matching branches**.
![Branch restriction checkbox](/assets/images/help/repository/restrict-branch.png)
- Search for and select the people, teams, or apps who will have permission to push to the protected branch.
![Branch restriction search](/assets/images/help/repository/restrict-branch-search.png)
1. Optionally, under "Rules applied to everyone including administrators", select **Allow force pushes**.
![Allow force pushes option](/assets/images/help/repository/allow-force-pushes.png)
1. Optionally, select **Allow deletions**.
![Allow branch deletions option](/assets/images/help/repository/allow-branch-deletions.png)
1. Click **Create**.
### Editing a branch protection rule
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-settings %}
{% data reusables.repositories.repository-branches %}
1. To the right of the branch protection rule you want to edit, click **Edit**.
![Edit button](/assets/images/help/repository/edit-branch-protection-rule.png)
1. Make your desired changes to the branch protection rule.
1. Click **Save changes**.
![Save changes button](/assets/images/help/repository/save-branch-protection-rule.png)
### Deleting a branch protection rule
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-settings %}
{% data reusables.repositories.repository-branches %}
1. To the right of the branch protection rule you want to delete, click **Delete**.
![Delete button](/assets/images/help/repository/delete-branch-protection-rule.png)

31
content/github/administering-a-repository/requiring-a-linear-commit-history.md
View File

@@ -1,31 +0,0 @@
---
title: Requiring a linear commit history
intro: You can require a linear commit history to block all merge commits from a protected branch.
product: '{% data reusables.gated-features.protected-branches %}'
versions:
free-pro-team: '*'
enterprise-server: '>=2.20'
github-ae: '*'
---
Anyone with admin permissions to a repository can require a linear commit history.
### About enforcement of linear commit history
Enforcing a linear commit history prevents merge commits from being pushed to the protected branch. This means that any pull requests merged into the protected branch must use a squash merge or a rebase merge. A strictly linear commit history can help teams backtrack changes more efficiently. For more information about merge methods, see "[About pull request merges](/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges)."
{% data reusables.repositories.protected-branches-options %}
Before you can require a linear commit history, your repository must allow squash merging or rebase merging. For more information, see "[Configuring pull request merges](/github/administering-a-repository/configuring-pull-request-merges)."
### Enforcing a linear commit history
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-settings %}
{% data reusables.repositories.repository-branches %}
{% data reusables.repositories.add-branch-protection-rules %}
6. Under "Protect matching branches", select **Require linear history**.
![Required linear history option](/assets/images/help/repository/required-linear-history.png)
{% data reusables.repositories.include-administrators %}
7. Click **Create**.

38
content/github/administering-a-repository/troubleshooting-required-status-checks.md Normal file
View File

@@ -0,0 +1,38 @@
---
title: Troubleshooting required status checks
intro: 'You can check for common errors and resolve issues with required status checks.'
product: '{% data reusables.gated-features.protected-branches %}'
versions:
free-pro-team: '*'
enterprise-server: '*'
github-ae: '*'
---
If you have a check and a status with the same name, and you select that name as a required status check, both the check and the status are required. For more information, see "[Checks](/rest/reference/checks)."
After you enable required status checks, your branch may need to be up-to-date with the base branch before merging. This ensures that your branch has been tested with the latest code from the base branch. If your branch is out of date, you'll need to merge the base branch into your branch. For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches#require-status-checks-before-merging)."
{% note %}
**Note:** You can also bring your branch up to date with the base branch using Git rebase. For more information, see "[About Git rebase](/github/using-git/about-git-rebase)."
{% endnote %}
You won't be able to push local changes to a protected branch until all required status checks pass. Instead, you'll receive an error message similar to the following.
```shell
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Required status check "ci-build" is failing
```
{% note %}
**Note:** Pull requests that are up-to-date and pass required status checks can be merged locally and pushed to the protected branch. This can be done without status checks running on the merge commit itself.
{% endnote %}
{% if currentVersion == "free-pro-team@latest" or currentVersion == "github-ae@latest" or currentVersion ver_gt "enterprise-server@2.20" %}
Sometimes, the results of the status checks for the test merge commit and head commit will conflict. If the test merge commit has a status, the test merge commit must pass. Otherwise, the status of the head commit must pass before you can merge the branch. For more information about test merge commits, see "[Pulls](/rest/reference/pulls#get-a-pull-request)."
![Branch with conflicting merge commits](/assets/images/help/repository/req-status-check-conflicting-merge-commits.png)
{% endif %}

22
content/github/administering-a-repository/types-of-required-status-checks.md
View File

@@ -1,22 +0,0 @@
---
title: Types of required status checks
intro: You can set up required status checks to either be "loose" or "strict." The type of required status check you choose determines whether your branch is required to be up to date with the base branch before merging.
product: '{% data reusables.gated-features.protected-branches %}'
redirect_from:
- /articles/types-of-required-status-checks
versions:
free-pro-team: '*'
enterprise-server: '*'
github-ae: '*'
---
| Type of required status check | Setting | Merge requirements | Considerations |
| --- | --- | --- | --- |
| **Strict** | The **Require branches to be up-to-date before merging** checkbox is checked. | The branch **must** be up to date with the base branch before merging. | This is the default behavior for required status checks. More builds may be required, as you'll need to bring the head branch up to date after other collaborators merge pull requests to the protected base branch.|
| **Loose** | The **Require branches to be up-to-date before merging** checkbox is **not** checked. | The branch **does not** have to be up to date with the base branch before merging. | You'll have fewer required builds, as you won't need to bring the head branch up to date after other collaborators merge pull requests. Status checks may fail after you merge your branch if there are incompatible changes with the base branch. |
| **Disabled** | The **Require status checks to pass before merging** checkbox is **not** checked. | The branch has no merge restrictions. | If required status checks aren't enabled, collaborators can merge the branch at any time, regardless of whether it is up to date with the base branch. This increases the possibility of incompatible changes.
### Further reading
- "[About required status checks](/articles/about-required-status-checks)"
- "[Enabling required status checks](/articles/enabling-required-status-checks)"

2
content/github/authenticating-to-github/about-commit-signature-verification.md
View File

@@ -19,7 +19,7 @@ You can sign commits and tags locally, so other people can verify that your work
If a commit or tag has a signature that cannot be verified, {% data variables.product.product_name %} marks the commit or tag as unverified.
Repository administrators can enforce required commit signing on a branch to block all commits that are not signed and verified. For more information, see "[About required commit signing](/articles/about-required-commit-signing)."
Repository administrators can enforce required commit signing on a branch to block all commits that are not signed and verified. For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches#require-signed-commits)."
You can check the verification status of your signed commits or tags on {% data variables.product.product_name %} and view why your commit signatures might be unverified. For more information, see "[Checking your commit and tag signature verification status](/articles/checking-your-commit-and-tag-signature-verification-status)."

2
content/github/building-a-strong-community/manually-creating-a-single-issue-template-for-your-repository.md
View File

@@ -18,7 +18,7 @@ You can add YAML frontmatter to each issue template to pre-fill the issue title,
Here is example YAML front matter.
```
```yaml
---
name: Tracking issue
about: Use this template for tracking new features.

2
content/github/collaborating-with-issues-and-pull-requests/about-branches.md
View File

@@ -74,7 +74,7 @@ When a branch is protected:
- If required status checks are enabled on the branch, you won't be able to merge changes into the branch until all of the required CI tests pass. For more information, see "[About status checks](/articles/about-status-checks)."
- If required pull request reviews are enabled on the branch, you won't be able to merge changes into the branch until all requirements in the pull request review policy have been met. For more information, see "[Merging a pull request](/articles/merging-a-pull-request)."
- If required review from a code owner is enabled on a branch, and a pull request modifies code that has an owner, a code owner must approve the pull request before it can be merged. For more information, see "[About code owners](/articles/about-code-owners)."
- If required commit signing is enabled on a branch, you won't be able to push any commits to the branch that are not signed and verified. For more information, see "[About commit signature verification](/articles/about-commit-signature-verification)" and "[About required commit signing](/articles/about-required-commit-signing)."{% if currentVersion == "free-pro-team@latest" or currentVersion == "github-ae@latest" or currentVersion ver_gt "enterprise-server@2.21" %}
- If required commit signing is enabled on a branch, you won't be able to push any commits to the branch that are not signed and verified. For more information, see "[About commit signature verification](/articles/about-commit-signature-verification)" and "[About protected branches](/github/administering-a-repository/about-protected-branches#require-signed-commits)."{% if currentVersion == "free-pro-team@latest" or currentVersion == "github-ae@latest" or currentVersion ver_gt "enterprise-server@2.21" %}
- If you use {% data variables.product.prodname_dotcom %}'s conflict editor to fix conflicts for a pull request that you created from a protected branch, {% data variables.product.prodname_dotcom %} helps you to create an alternative branch for the pull request, so that your resolution of the conflicts can be merged. For more information, see "[Resolving a merge conflict on {% data variables.product.prodname_dotcom %}](/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-on-github)."{% endif %}
### Further reading

5
content/github/collaborating-with-issues-and-pull-requests/about-pull-request-reviews.md
View File

@@ -44,9 +44,7 @@ You can view all of the reviews a pull request has received in the Conversation
### Required reviews
{% data reusables.pull_requests.required-reviews-for-prs-summary %}
For more information, see "[About required reviews for pull requests](/articles/about-required-reviews-for-pull-requests)."
{% data reusables.pull_requests.required-reviews-for-prs-summary %} For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging)."
{% tip %}
@@ -57,6 +55,5 @@ For more information, see "[About required reviews for pull requests](/articles/
### Further reading
- "[Reviewing proposed changes in a pull request](/articles/reviewing-proposed-changes-in-a-pull-request)"
- "[Enabling required reviews for pull requests](/articles/enabling-required-reviews-for-pull-requests)"
- "[Viewing a pull request review](/articles/viewing-a-pull-request-review)"
- "[Setting guidelines for repository contributors](/articles/setting-guidelines-for-repository-contributors)"

5
content/github/collaborating-with-issues-and-pull-requests/approving-a-pull-request-with-required-reviews.md
View File

@@ -9,9 +9,9 @@ versions:
github-ae: '*'
---
For more information about required reviews, see "[About required reviews for pull requests](/articles/about-required-reviews-for-pull-requests)."
For more information about required reviews, see "[About protected branches](/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging)."
You can comment on a pull request, approve the changes, or request improvements before approving. For more information, see "[About required reviews for pull requests](/articles/about-required-reviews-for-pull-requests)" and "[Reviewing proposed changes in a pull request](/articles/reviewing-proposed-changes-in-a-pull-request)."
You can comment on a pull request, approve the changes, or request improvements before approving. For more information, see "[Reviewing proposed changes in a pull request](/articles/reviewing-proposed-changes-in-a-pull-request)."
{% data reusables.search.requested_reviews_search %}
@@ -34,6 +34,5 @@ You can comment on a pull request, approve the changes, or request improvements
### Further reading
- "[About required reviews for pull requests](/articles/about-required-reviews-for-pull-requests)"
- "[Reviewing proposed changes in a pull request](/articles/reviewing-proposed-changes-in-a-pull-request)"
- "[Commenting on a pull request](/articles/commenting-on-a-pull-request)"

2
content/github/collaborating-with-issues-and-pull-requests/committing-changes-to-a-pull-request-branch-created-from-a-fork.md
View File

@@ -13,7 +13,7 @@ You can only make commits on pull request branches that:
- are opened in a repository that you have push access to and that were created from a fork of that repository
- are on a user-owned fork
- have permission granted from the pull request creator
- don't have [branch restrictions](/articles/about-branch-restrictions) that will prevent you from committing
- don't have [branch restrictions](/github/administering-a-repository/about-protected-branches#restrict-who-can-push-to-matching-branches) that will prevent you from committing
Only the user who created the pull request can give you permission to push commits to the user-owned fork. For more information, see "[Allowing changes to a pull request branch created from a fork](/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork)."

4
content/github/collaborating-with-issues-and-pull-requests/dismissing-a-pull-request-review.md
View File

@@ -1,6 +1,6 @@
---
title: Dismissing a pull request review
intro: 'If your repository [requires reviews](/articles/about-required-reviews-for-pull-requests), you can dismiss pull request reviews that are no longer valid or are unable to be approved by the reviewer.'
intro: 'If your repository requires reviews, you can dismiss pull request reviews that are no longer valid or are unable to be approved by the reviewer.'
redirect_from:
- /articles/dismissing-a-pull-request-review
versions:
@@ -26,4 +26,4 @@ This changes the status of the review to a review comment. When you dismiss a re
- "[About pull request reviews](/articles/about-pull-request-reviews)"
- "[Reviewing proposed changes in a pull request](/articles/reviewing-proposed-changes-in-a-pull-request)"
- "[About required reviews for pull requests](/articles/about-required-reviews-for-pull-requests)"
- "[About protected branches](/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging)"

2
content/github/collaborating-with-issues-and-pull-requests/merging-a-pull-request.md
View File

@@ -12,7 +12,7 @@ versions:
### About pull request merges
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)."
In a pull request, you propose that changes you've made on a head branch should be merged into a base branch. By default, any pull request can be merged at any time, unless the head branch is in conflict with the base branch. 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 %}

16
content/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-using-the-command-line.md
View File

@@ -46,14 +46,14 @@ For example, if you and another person both edited the file _styleguide.md_ on t
4. Open your favorite text editor, such as [Atom](https://atom.io/), and navigate to the file that has merge conflicts.
5. To see the beginning of the merge conflict in your file, search the file for the conflict marker `<<<<<<<`. When you open the file in your text editor, you'll see the changes from the HEAD or base branch after the line `<<<<<<< HEAD`. Next, you'll see `=======`, which divides your changes from the changes in the other branch, followed by `>>>>>>> BRANCH-NAME`. In this example, one person wrote "open an issue" in the base or HEAD branch and another person wrote "ask your question in IRC" in the compare branch or `branch-a`.
```
If you have questions, please
<<<<<<< HEAD
open an issue
=======
ask your question in IRC.
>>>>>>> branch-a
````
```
If you have questions, please
<<<<<<< HEAD
open an issue
=======
ask your question in IRC.
>>>>>>> branch-a
```
{% data reusables.pull_requests.decide-how-to-resolve-competing-line-change-merge-conflict %} In this example, both changes are incorporated into the final merge:
```shell

2
content/github/collaborating-with-issues-and-pull-requests/reviewing-proposed-changes-in-a-pull-request.md
View File

@@ -70,5 +70,5 @@ After you've finished reviewing all the files you want in the pull request, subm
### Further reading
- "[About required reviews for pull requests](/github/administering-a-repository/about-required-reviews-for-pull-requests)"
- "[About protected branches](/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging)"
- "[Filtering pull requests by review status](/github/managing-your-work-on-github/filtering-pull-requests-by-review-status)"

2
content/github/collaborating-with-issues-and-pull-requests/working-with-pre-receive-hooks.md
View File

@@ -11,7 +11,7 @@ Pre-receive hooks run tests on code pushed to a repository to ensure contributio
If your push isn't accepted, you'll see an error message corresponding to the failed pre-receive hook.
```
```shell
$ git push
Counting objects: 3, done.
Delta compression using up to 4 threads.

2
content/github/creating-cloning-and-archiving-repositories/about-code-owners.md
View File

@@ -19,7 +19,7 @@ The people you choose as code owners must have write permissions for the reposit
Code owners are automatically requested for review when someone opens a pull request that modifies code that they own. Code owners are not automatically requested to review draft pull requests. For more information about draft pull requests, see "[About pull requests](/github/collaborating-with-issues-and-pull-requests/about-pull-requests#draft-pull-requests)." When you mark a draft pull request as ready for review, code owners are automatically notified. If you convert a pull request to a draft, people who are already subscribed to notifications are not automatically unsubscribed. For more information, see "[Changing the stage of a pull request](/github/collaborating-with-issues-and-pull-requests/changing-the-stage-of-a-pull-request)."
When someone with admin or owner permissions has enabled required reviews, they also can optionally require approval from a code owner before the author can merge a pull request in the repository. For more information, see "[Enabling required reviews for pull requests](/github/administering-a-repository/enabling-required-reviews-for-pull-requests)."
When someone with admin or owner permissions has enabled required reviews, they also can optionally require approval from a code owner before the author can merge a pull request in the repository. For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging)."
{% if currentVersion == "free-pro-team@latest" or currentVersion == "github-ae@latest" or currentVersion ver_gt "enterprise-server@2.19" %}If a team has enabled code review assignments, the individual approvals won't satisfy the requirement for code owner approval in a protected branch. For more information, see "[Managing code review assignment for your team](/github/setting-up-and-managing-organizations-and-teams/managing-code-review-assignment-for-your-team)."{% endif %}

4
content/github/creating-cloning-and-archiving-repositories/about-repositories.md
View File

@@ -22,8 +22,8 @@ Each person and organization can own unlimited repositories and invite an unlimi
{% endif %}
You can use repositories to manage your work and collaborate with others.
- You can use issues to collect user feedback, report software bugs, and organize tasks you'd like to accomplish. For more information, see "[About issues](/github/managing-your-work-on-github/about-issues)."
- {% data reusables.discussions.you-can-use-discussions %}
- You can use issues to collect user feedback, report software bugs, and organize tasks you'd like to accomplish. For more information, see "[About issues](/github/managing-your-work-on-github/about-issues)."{% if currentVersion == "free-pro-team@latest" %}
- {% data reusables.discussions.you-can-use-discussions %}{% endif %}
- You can use pull requests to propose changes to a repository. For more information, see "[About pull requests](/github/collaborating-with-issues-and-pull-requests/about-pull-requests)."
- You can use project boards to organize and prioritize your issues and pull requests. For more information, see "[About project boards](/github/managing-your-work-on-github/about-project-boards)."

10
content/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-codeql-code-scanning-in-your-ci-system.md
View File

@@ -21,7 +21,7 @@ To integrate {% data variables.product.prodname_code_scanning %} into your CI sy
In general, you invoke the {% data variables.product.prodname_codeql_runner %} as follows.
```
```shell
$ /path/to-runner/codeql-runner-OS <COMMAND> <FLAGS>
```
@@ -40,7 +40,7 @@ The {% data variables.product.prodname_codeql_runner %} automatically detects an
To override automatic language detection, run the `init` command with the `--languages` flag, followed by a comma-separated list of language keywords. The keywords for the supported languages are `cpp`, `csharp`, `go`, `java`, `javascript`, and `python`.
```
```shell
$ /path/to-runner/codeql-runner-linux init --languages cpp,java
```
@@ -58,7 +58,7 @@ For more information, see "[Using a custom configuration file](#using-a-custom-c
In the following example, the `+` symbol ensures that the {% data variables.product.prodname_codeql_runner %} uses the additional queries together with any queries specified in the referenced configuration file.
```
```shell
$ /path/to-runner/codeql-runner-linux init --config-file .github/codeql/codeql-config.yml
--queries +security-and-quality,octo-org/python-qlpack/show_ifs.ql@main
```
@@ -71,7 +71,7 @@ The configuration file is a YAML file. It uses syntax similar to the workflow sy
Use the `--config-file` flag of the `init` command to specify the configuration file. The value of <nobr>`--config-file`</nobr> is the path to the configuration file that you want to use. This example loads the configuration file _.github/codeql/codeql-config.yml_.
```
```shell
$ /path/to-runner/codeql-runner-linux init --config-file .github/codeql/codeql-config.yml
```
@@ -87,7 +87,7 @@ For many common build systems, the {% data variables.product.prodname_codeql_run
The `autobuild` process only ever attempts to build _one_ compiled language for a repository. The language automatically selected for analysis is the language with the most files. If you want to choose a language explicitly, use the `--language` flag of the `autobuild` command.
```
```shell
$ /path/to-runner/codeql-runner-linux autobuild --language csharp
```

2
content/github/finding-security-vulnerabilities-and-errors-in-your-code/triaging-code-scanning-alerts-in-pull-requests.md
View File

@@ -15,7 +15,7 @@ versions:
In repositories where {% data variables.product.prodname_code_scanning %} is configured as a pull request check, {% data variables.product.prodname_code_scanning %} checks the code in the pull request. By default, this is limited to pull requests that target the default branch, but you can change this configuration within {% data variables.product.prodname_actions %} or in a third-party CI/CD system. If merging the changes would introduce new {% data variables.product.prodname_code_scanning %} alerts to the target branch, these are reported as check results in the pull request. The alerts are also shown as annotations in the **Files changed** tab of the pull request. If you have write permission for the repository, you can see any existing {% data variables.product.prodname_code_scanning %} alerts on the **Security** tab. For information about repository alerts, see "[Managing {% data variables.product.prodname_code_scanning %} alerts for your repository](/github/finding-security-vulnerabilities-and-errors-in-your-code/managing-code-scanning-alerts-for-your-repository)."
If {% data variables.product.prodname_code_scanning %} has any results with a severity of `error`, the check fails and the error is reported in the check results. If all the results found by {% data variables.product.prodname_code_scanning %} have lower severities, the alerts are treated as warnings or notices and the check succeeds. If your pull request targets a protected branch that has been enabled for {% data variables.product.prodname_code_scanning %}, and the repository owner has configured required status checks, then you must either fix or {% if currentVersion == "enterprise-server@2.22" %}close{% else %}dismiss{% endif %} all error alerts before the pull request can be merged. For more information, see "[About required status checks](/github/administering-a-repository/about-required-status-checks)."
If {% data variables.product.prodname_code_scanning %} has any results with a severity of `error`, the check fails and the error is reported in the check results. If all the results found by {% data variables.product.prodname_code_scanning %} have lower severities, the alerts are treated as warnings or notices and the check succeeds. If your pull request targets a protected branch that has been enabled for {% data variables.product.prodname_code_scanning %}, and the repository owner has configured required status checks, then you must either fix or {% if currentVersion == "enterprise-server@2.22" %}close{% else %}dismiss{% endif %} all error alerts before the pull request can be merged. For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches#require-status-checks-before-merging)."
![Failed {% data variables.product.prodname_code_scanning %} check on a pull request](/assets/images/help/repository/code-scanning-check-failure.png)

2
content/github/getting-started-with-github/about-github-advanced-security.md
View File

@@ -10,7 +10,7 @@ versions:
{% data variables.product.prodname_dotcom %} has many features that help you improve and maintain the quality of your code. Some of these are included in all plans, for example: dependency graph and {% data variables.product.prodname_dependabot_alerts %}. Other security features require a license for {% data variables.product.prodname_GH_advanced_security %} to run on repositories apart from public repositories on {% data variables.product.prodname_dotcom_the_website %}. (That is, private and internal repositories on {% data variables.product.prodname_dotcom_the_website %}, and all repositories on {% data variables.product.prodname_ghe_server %}.)
For an overview of all security features, see "[About securing your repository](/github/administering-a-repository/about-securing-your-repository#setting-up-your-repository-securely)."
For an overview of all security features, see "[About securing your repository](/github/administering-a-repository/about-securing-your-repository#setting-up-your-repository-securely)." For information about permission requirements for actions related to security features, see "[Repository permission levels for an organization](/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization#permission-requirements-for-security-features)."
### About {% data variables.product.prodname_advanced_security %} features

2
content/github/getting-started-with-github/keyboard-shortcuts.md
View File

@@ -33,7 +33,7 @@ Below is a list of some of the available keyboard shortcuts.
|-----------|------------
|<kbd>g</kbd> <kbd>c</kbd> | Go to the **Code** tab
|<kbd>g</kbd> <kbd>i</kbd> | Go to the **Issues** tab. For more information, see "[About issues](/articles/about-issues)."
|<kbd>g</kbd> <kbd>p</kbd> | Go to the **Pull requests** tab. For more information, see "[About pull requests](/articles/about-pull-requests)."{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.21" or currentVersion == "github-ae@latest" %}
|<kbd>g</kbd> <kbd>p</kbd> | Go to the **Pull requests** tab. For more information, see "[About pull requests](/articles/about-pull-requests)."{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.21" %}
|<kbd>g</kbd> <kbd>a</kbd> | Go to the **Actions** tab. For more information, see "[About Actions](/actions/getting-started-with-github-actions/about-github-actions)."{% endif %}
|<kbd>g</kbd> <kbd>b</kbd> | Go to the **Projects** tab. For more information, see "[About project boards](/articles/about-project-boards)."
|<kbd>g</kbd> <kbd>w</kbd> | Go to the **Wiki** tab. For more information, see "[About wikis](/articles/about-wikis)."

2
content/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies.md
View File

@@ -47,6 +47,8 @@ For a list of the ecosystems that {% data variables.product.product_name %} can
You can also enable or disable {% data variables.product.prodname_dependabot_alerts %} for all repositories owned by your user account or organization. For more information, see "[Managing security and analysis settings for your user account](/github/setting-up-and-managing-your-github-user-account/managing-security-and-analysis-settings-for-your-user-account)" or "[Managing security and analysis settings for your organization](/github/setting-up-and-managing-organizations-and-teams/managing-security-and-analysis-settings-for-your-organization)."
For information about permission requirements for actions related to {% data variables.product.prodname_dependabot_alerts %}, see "[Repository permission levels for an organization](/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization#permission-requirements-for-security-features)."
{% data variables.product.product_name %} starts generating the dependency graph immediately and generates alerts for any vulnerable dependencies as soon as they are identified. The graph is usually populated within minutes but this may take longer for repositories with many dependencies. For more information, see "[Managing data use settings for your private repository](/github/understanding-how-github-uses-and-protects-your-data/managing-data-use-settings-for-your-private-repository)."
{% endif %}

2
content/github/managing-your-work-on-github/about-issues.md
View File

@@ -14,9 +14,11 @@ versions:
You can collect user feedback, report software bugs, and organize tasks you'd like to accomplish with issues in a repository. Issues can act as more than just a place to report software bugs.
{% if currentVersion == "free-pro-team@latest" %}
Other conversations are more suitable for discussions. {% data reusables.discussions.you-can-use-discussions %}
{% data reusables.discussions.you-cannot-convert-a-discussion %}
{% endif %}
{% data reusables.pull_requests.close-issues-using-keywords %}

2
content/github/managing-your-work-on-github/filtering-pull-requests-by-review-status.md
View File

@@ -11,7 +11,7 @@ versions:
You can filter a repository's list of pull requests to find:
- Pull requests that haven't been [reviewed](/articles/about-pull-request-reviews) yet
- Pull requests that [require a review](/articles/about-required-reviews-for-pull-requests) before they can be merged
- Pull requests that [require a review](/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging) before they can be merged
- Pull requests that a reviewer has approved
- Pull requests in which a reviewer has asked for changes
- Pull requests that you have reviewed

2
content/github/managing-your-work-on-github/using-search-to-filter-issues-and-pull-requests.md
View File

@@ -36,7 +36,7 @@ For issues, you can also use search to:
For pull requests, you can also use search to:
- Filter [draft](/articles/about-pull-requests#draft-pull-requests) pull requests: `is:draft`
- Filter pull requests that haven't been [reviewed](/articles/about-pull-request-reviews) yet: `state:open type:pr review:none`
- Filter pull requests that [require a review](/articles/about-required-reviews-for-pull-requests) before they can be merged: `state:open type:pr review:required`
- Filter pull requests that [require a review](/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging) before they can be merged: `state:open type:pr review:required`
- Filter pull requests that a reviewer has approved: `state:open type:pr review:approved`
- Filter pull requests in which a reviewer has asked for changes: `state:open type:pr review:changes_requested`
- Filter pull requests by [reviewer](/articles/about-pull-request-reviews/): `state:open type:pr reviewed-by:octocat`

41
content/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization.md
View File

@@ -1,6 +1,7 @@
---
title: Repository permission levels for an organization
intro: 'You can customize access to each repository in your organization with granular permission levels, giving people access to the features and tasks they need.'
miniTocMaxHeadingLevel: 4
redirect_from:
- /articles/repository-permission-levels-for-an-organization-early-access-program/
- /articles/repository-permission-levels-for-an-organization
@@ -42,6 +43,13 @@ In addition to managing organization-level settings, organization owners have ad
{% endwarning %}
### Repository access for each permission level
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.21" %}
{% note %}
**Note:** Repository permissions required to use security features are listed in "[Permission requirements for security features](#permission-requirements-for-security-features)" below.
{% endnote %}
{% endif %}
| Repository action | Read | Triage | Write | Maintain | Admin |
|:---|:---:|:---:|:---:|:---:|:---:|
@@ -104,17 +112,7 @@ In addition to managing organization-level settings, organization owners have ad
| Rename the repository's default branch (see "[Renaming a branch](/github/administering-a-repository/renaming-a-branch)") | | | | | **X** |
| Rename a branch other than the repository's default branch (see "[Renaming a branch](/github/administering-a-repository/renaming-a-branch)") | | | **X** | **X** | **X** |{% endif %}
| Manage webhooks and deploy keys | | | | | **X** |{% if currentVersion == "free-pro-team@latest" %}
| [Enable the dependency graph](/github/visualizing-repository-data-with-graphs/exploring-the-dependencies-and-dependents-of-a-repository) for a private repository | | | | | **X** |
| Receive [{% data variables.product.prodname_dependabot_alerts %} for vulnerable dependencies](/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies) in a repository | | | | | **X** |
| [Dismiss {% data variables.product.prodname_dependabot_alerts %}](/github/managing-security-vulnerabilities/viewing-and-updating-vulnerable-dependencies-in-your-repository) | | | | | **X** |
| [Designate additional people or teams to receive {% data variables.product.prodname_dependabot_alerts %}](/github/administering-a-repository/managing-security-and-analysis-settings-for-your-repository#granting-access-to-security-alerts) for vulnerable dependencies | | | | | **X** |
| [Manage data use settings for your private repository](/github/understanding-how-github-uses-and-protects-your-data/managing-data-use-settings-for-your-private-repository) | | | | | **X** |
| Create [security advisories](/github/managing-security-vulnerabilities/about-github-security-advisories) | | | | | **X** |
| Manage access to {% data variables.product.prodname_GH_advanced_security %} features (see "[Managing security and analysis settings for your organization](/github/setting-up-and-managing-organizations-and-teams/managing-security-and-analysis-settings-for-your-organization)") | | | | | **X** |{% endif %}{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.21" %}
| [View {% data variables.product.prodname_code_scanning %} alerts on pull requests](/github/finding-security-vulnerabilities-and-errors-in-your-code/triaging-code-scanning-alerts-in-pull-requests) | **X** | **X** | **X** | **X** | **X** |
| [List, dismiss, and delete {% data variables.product.prodname_code_scanning %} alerts](/github/finding-security-vulnerabilities-and-errors-in-your-code/managing-code-scanning-alerts-for-your-repository) | | | **X** | **X** | **X** |{% endif %}{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" %}
| [View {% data variables.product.prodname_secret_scanning %} alerts in a repository, and also resolve, revoke or re-open {% data variables.product.prodname_secret_scanning %} alerts](/github/administering-a-repository/managing-alerts-from-secret-scanning) | | | | | **X** |
| [Designate additional people or teams to receive {% data variables.product.prodname_secret_scanning %} alerts](/github/administering-a-repository/managing-security-and-analysis-settings-for-your-repository#granting-access-to-security-alerts) in repositories | | | | | **X** |{% endif %}
| [Manage data use settings for your private repository](/github/understanding-how-github-uses-and-protects-your-data/managing-data-use-settings-for-your-private-repository) | | | | | **X** |{% endif %}
| [Manage the forking policy for a repository](/github/administering-a-repository/managing-the-forking-policy-for-your-repository) | | | | | **X** |
| [Transfer repositories into the organization](/articles/restricting-repository-creation-in-your-organization) | | | | | **X** |
| [Delete or transfer repositories out of the organization](/articles/setting-permissions-for-deleting-or-transferring-repositories) | | | | | **X** |
@@ -132,6 +130,27 @@ In addition to managing organization-level settings, organization owners have ad
| [Create new discussions and comment on existing discussions](/discussions/collaborating-with-your-community-using-discussions/participating-in-a-discussion) | **X** | **X** | **X** | **X** | **X** |
| [Delete a discussion](/discussions/managing-discussions-for-your-community/managing-discussions-in-your-repository#deleting-a-discussion) | | | | **X** | **X** |{% endif %}
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.21" %}
#### Permission requirements for security features
In this section, you can find the repository permission levels required for security features, such as {% data variables.product.prodname_dependabot %} and {% data variables.product.prodname_advanced_security %} features.
| Repository action | Read | Triage | Write | Maintain | Admin |
|:---|:---:|:---:|:---:|:---:|:---:|{% if currentVersion == "free-pro-team@latest" %}
| Receive [{% data variables.product.prodname_dependabot_alerts %} for vulnerable dependencies](/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies) in a repository | | | | | **X** |
| [Dismiss {% data variables.product.prodname_dependabot_alerts %}](/github/managing-security-vulnerabilities/viewing-and-updating-vulnerable-dependencies-in-your-repository) | | | | | **X** |
| [Designate additional people or teams to receive {% data variables.product.prodname_dependabot_alerts %}](/github/administering-a-repository/managing-security-and-analysis-settings-for-your-repository#granting-access-to-security-alerts) for vulnerable dependencies | | | | | **X** |
| Create [security advisories](/github/managing-security-vulnerabilities/about-github-security-advisories) | | | | | **X** |
| Manage access to {% data variables.product.prodname_GH_advanced_security %} features (see "[Managing security and analysis settings for your organization](/github/setting-up-and-managing-organizations-and-teams/managing-security-and-analysis-settings-for-your-organization)") | | | | | **X** |
| [Enable the dependency graph](/github/visualizing-repository-data-with-graphs/exploring-the-dependencies-and-dependents-of-a-repository) for a private repository | | | | | **X** |
| [View dependency reviews](/github/collaborating-with-issues-and-pull-requests/reviewing-dependency-changes-in-a-pull-request) | **X** | **X** | **X** | **X** | **X** |{% endif %}{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.21" %}
| [View {% data variables.product.prodname_code_scanning %} alerts on pull requests](/github/finding-security-vulnerabilities-and-errors-in-your-code/triaging-code-scanning-alerts-in-pull-requests) | **X** | **X** | **X** | **X** | **X** |
| [List, dismiss, and delete {% data variables.product.prodname_code_scanning %} alerts](/github/finding-security-vulnerabilities-and-errors-in-your-code/managing-code-scanning-alerts-for-your-repository) | | | **X** | **X** | **X** |{% endif %}{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" %}
| [View {% data variables.product.prodname_secret_scanning %} alerts in a repository](/github/administering-a-repository/managing-alerts-from-secret-scanning) | | | | | **X** |
| [Resolve, revoke or re-open {% data variables.product.prodname_secret_scanning %} alerts](/github/administering-a-repository/managing-alerts-from-secret-scanning) | | | | | **X** |
| [Designate additional people or teams to receive {% data variables.product.prodname_secret_scanning %} alerts](/github/administering-a-repository/managing-security-and-analysis-settings-for-your-repository#granting-access-to-security-alerts) in repositories | | | | | **X** |{% endif %}
{% endif %}
### Further reading
- "[Managing access to your organization's repositories](/articles/managing-access-to-your-organization-s-repositories)"

13
content/github/setting-up-and-managing-your-github-user-account/types-of-emails-github-sends.md
View File

@@ -1,6 +1,6 @@
---
title: Types of emails GitHub sends
intro: 'There are several types of emails you can receive from {% data variables.product.product_name %}, including notifications, account information, and marketing communications.'
intro: 'There are several types of emails you can receive from {% data variables.product.product_name %}, including notifications, account information, customer research invitations, and marketing communications.'
redirect_from:
- /articles/types-of-emails-github-sends
versions:
@@ -25,6 +25,17 @@ You can also choose which type of email updates you'd like to receive on convers
If you've upgraded to paid products or features, then you'll receive billing receipts at the account's primary email address. For more information, see "[Setting your billing email](/articles/setting-your-billing-email)."
### Customer research emails
{% data variables.product.product_name %} occasionally seeks customers to participate in research sessions to help us build a better GitHub. These are conducted remotely, open to customers worldwide, and may include:
- Feedback surveys
- Research interviews
- Usability testing sessions
- Previewing early prototypes or concepts
These emails are infrequent and you can choose whether or not to participate. If you're interested in additional opportunities to participate in research sessions, you may add yourself to the GitHub Customer Research Panel. For more information, see "[GitHub Customer Experience Research](https://cxr.github.com)."
### Marketing emails
{% data variables.product.product_name %} occasionally sends these types of marketing emails:

4
content/github/working-with-github-pages/about-github-pages-and-jekyll.md
View File

@@ -38,7 +38,7 @@ You can configure most Jekyll settings, such as your site's theme and plugins, b
Some configuration settings cannot be changed for {% data variables.product.prodname_pages %} sites.
```
```yaml
lsi: false
safe: true
source: [your repo's top level directory]
@@ -111,7 +111,7 @@ By default, code blocks on your site will be highlighted by Jekyll. Jekyll uses
If you want to use another highlighter, such as `highlight.js`, you must disable Jekyll's syntax highlighting by updating your project's *_config.yml* file.
```
```yaml
kramdown:
syntax_highlighter_opts:
disable : true

4
content/github/working-with-github-pages/about-jekyll-build-errors-for-github-pages-sites.md
View File

@@ -44,13 +44,13 @@ You can see build failures (but not build warnings) for your site on {% data var
You can configure a third-party service, such as [Travis CI](https://travis-ci.org/), to display error messages after each commit.
1. If you haven't already, add a file called _Gemfile_ in the root of your publishing source, with the following content:
```
```ruby
source `https://rubygems.org`
gem `github-pages`
```
2. Configure your site's repository for the testing service of your choice. For example, to use [Travis CI](https://travis-ci.org/), add a file named _.travis.yml_ in the root of your publishing source, with the following content:
```
```yaml
language: ruby
rvm:
- 2.3

2
content/github/working-with-github-pages/adding-a-theme-to-your-github-pages-site-using-jekyll.md
View File

@@ -42,7 +42,7 @@ People with write permissions for a repository can add a theme to a {% data vari
{% data reusables.pages.navigate-publishing-source %}
1. Create a new file called _/assets/css/style.scss_.
2. Add the following content to the top of the file:
```
```scss
---
---

2
content/github/working-with-github-pages/adding-content-to-your-github-pages-site-using-jekyll.md
View File

@@ -62,6 +62,8 @@ Your theme includes default layouts, includes, and stylesheets that will automat
{% data reusables.files.choose_commit_branch %}
{% data reusables.files.propose_file_change %}
Your post should now be up on your site! If the base URL of your site is `https://octocat.github.io`, then your new post will be located at `https://octocat.github.io/YYYY/MM/DD/TITLE.html`.
### Next steps
{% data reusables.pages.add-jekyll-theme %} For more information, see "[Adding a theme to your {% data variables.product.prodname_pages %} site using Jekyll](/articles/adding-a-theme-to-your-github-pages-site-using-jekyll)."

2
content/github/working-with-github-pages/creating-a-custom-404-page-for-your-github-pages-site.md
View File

@@ -17,7 +17,7 @@ versions:
3. In the file name field, type `404.html` or `404.md`.
![File name field](/assets/images/help/pages/404-file-name.png)
4. If you named your file `404.md`, add the following YAML front matter to the beginning of the file:
```
```yaml
---
permalink: /404.html
---

2
content/github/working-with-github-pages/troubleshooting-jekyll-build-errors-for-github-pages-sites.md
View File

@@ -78,7 +78,7 @@ This error means that your code references a symlinked file that does not exist
This error means that you used non-Latin characters, like `日本語`, without telling the computer to expect these symbols.
To troubleshoot, force UTF-8 encoding by adding the following line to your *_config.yml* file:
```
```yaml
encoding: UTF-8
```

16
content/github/writing-on-github/basic-writing-and-formatting-syntax.md
View File

@@ -13,7 +13,7 @@ versions:
To create a heading, add one to six `#` symbols before your heading text. The number of `#` you use will determine the size of the heading.
```
```markdown
# The largest heading
## The second largest heading
###### The smallest heading
@@ -37,7 +37,7 @@ You can indicate emphasis with bold, italic, or strikethrough text.
You can quote text with a `>`.
```
```markdown
In the words of Abraham Lincoln:
> Pardon my French
@@ -55,7 +55,7 @@ In the words of Abraham Lincoln:
You can call out code or a command within a sentence with single backticks. The text within the backticks will not be formatted.
```
```markdown
Use `git status` to list all new or modified files that haven't yet been committed.
```
@@ -102,7 +102,7 @@ You can create an inline link by wrapping link text in brackets `[ ]`, and then
You can make an unordered list by preceding one or more lines of text with `-` or `*`.
```
```markdown
- George Washington
- John Adams
- Thomas Jefferson
@@ -112,7 +112,7 @@ You can make an unordered list by preceding one or more lines of text with `-` o
To order your list, precede each line with a number.
```
```markdown
1. James Madison
2. James Monroe
3. John Quincy Adams
@@ -126,7 +126,7 @@ You can create a nested list by indenting one or more list items below another i
To create a nested list using the web editor on {% data variables.product.product_name %} or a text editor that uses a monospaced font, like [Atom](https://atom.io/), you can align your list visually. Type space characters in front of your nested list item, until the list marker character (`-` or `*`) lies directly below the first character of the text in the item above it.
```
```markdown
1. First list item
- First nested list item
- Second nested list item
@@ -140,7 +140,7 @@ To create a nested list in the comment editor on {% data variables.product.produ
In this example, you could add a nested list item under the list item `100. First list item` by indenting the nested list item a minimum of five spaces, since there are five characters (`100. `) before `First list item`.
```
```markdown
100. First list item
- First nested list item
```
@@ -149,7 +149,7 @@ In this example, you could add a nested list item under the list item `100. Firs
You can create multiple levels of nested lists using the same method. For example, because the first nested list item has seven spaces (`␣␣␣␣␣-␣`) before the nested list content `First nested list item`, you would need to indent the second nested list item by seven spaces.
```
```markdown
100. First list item
- First nested list item
- Second nested list item

10
content/github/writing-on-github/organizing-information-with-tables.md
View File

@@ -13,7 +13,7 @@ versions:
You can create tables with pipes `|` and hyphens `-`. Hyphens are used to create each column's header, while pipes separate each column. You must include a blank line before your table in order for it to correctly render.
```
```markdown
| First Header | Second Header |
| ------------- | ------------- |
@@ -27,7 +27,7 @@ The pipes on either end of the table are optional.
Cells can vary in width and do not need to be perfectly aligned within columns. There must be at least three hyphens in each column of the header row.
```
```markdown
| Command | Description |
| --- | --- |
| git status | List all new or modified files |
@@ -40,7 +40,7 @@ Cells can vary in width and do not need to be perfectly aligned within columns.
You can use [formatting](/articles/basic-writing-and-formatting-syntax) such as links, inline code blocks, and text styling within your table:
```
```markdown
| Command | Description |
| --- | --- |
| `git status` | List all *new or modified* files |
@@ -51,7 +51,7 @@ You can use [formatting](/articles/basic-writing-and-formatting-syntax) such as
You can align text to the left, right, or center of a column by including colons `:` to the left, right, or on both sides of the hyphens within the header row.
```
```markdown
| Left-aligned | Center-aligned | Right-aligned |
| :--- | :---: | ---: |
| git status | git status | git status |
@@ -62,7 +62,7 @@ You can align text to the left, right, or center of a column by including colons
To include a pipe `|` as content within your cell, use a `\` before the pipe:
```
```markdown
| Name | Character |
| --- | --- |
| Backtick | ` |

1
content/graphql/guides/forming-calls-with-graphql.md
View File

@@ -103,6 +103,7 @@ Mutations are structured like this:
<pre>mutation {
<em>mutationName</em>(input: {<em>MutationNameInput!</em>}) {
<em>MutationNamePayload</em>
}
}</pre>
The input object in this example is `MutationNameInput`, and the payload object is `MutationNamePayload`.

38
content/graphql/guides/introduction-to-graphql.md
View File

@@ -81,9 +81,25 @@ GraphQL is [introspective](https://graphql.github.io/learn/introspection/). This
* Query `__schema` to list all types defined in the schema and get details about each:
```graphql
query {
__schema {
types {
query {
__schema {
types {
name
kind
description
fields {
name
}
}
}
}
```
* Query `__type` to get details about any type:
```graphql
query {
__type(name: "Repository") {
name
kind
description
@@ -92,22 +108,6 @@ query {
}
}
}
}
```
* Query `__type` to get details about any type:
```graphql
query {
__type(name: "Repository") {
name
kind
description
fields {
name
}
}
}
```
* You can also run an _introspection query_ of the schema via a `GET` request:

2
content/insights/installing-and-configuring-github-insights/enabling-a-link-between-github-insights-and-github-enterprise.md
View File

@@ -14,7 +14,7 @@ After you enable the link, each user can navigate directly from {% data variable
1. Connect to the administrative shell for {% data variables.product.prodname_ghe_server %}. For more information, see "[Accessing the administrative shell (SSH)](/enterprise/{{ currentVersion }}/admin/guides/installation/accessing-the-administrative-shell-ssh/)."
2. Run the following command.
```
```shell
ghe-config 'app.github.insights-available' 'true' && ghe-config-apply
```
3. Return to {% data variables.product.prodname_ghe_server %}.

10
content/packages/guides/configuring-apache-maven-for-use-with-github-packages.md
View File

@@ -38,7 +38,7 @@ If you want to interact with multiple repositories, you can add each repository
If your instance has subdomain isolation enabled:
{% endif %}
```
```xml
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
@@ -80,7 +80,7 @@ If your instance has subdomain isolation enabled:
{% if enterpriseServerVersions contains currentVersion %}
If your instance has subdomain isolation disabled:
```
```xml
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
@@ -136,7 +136,7 @@ For more information on creating a package, see the [maven.apache.org documentat
{% if enterpriseServerVersions contains currentVersion %}
If your instance has subdomain isolation enabled:
{% endif %}
```
```xml
<distributionManagement>
<repository>
<id>github</id>
@@ -147,7 +147,7 @@ For more information on creating a package, see the [maven.apache.org documentat
```
{% if enterpriseServerVersions contains currentVersion %}
If your instance has subdomain isolation disabled:
```
```xml
<distributionManagement>
<repository>
<id>github</id>
@@ -172,7 +172,7 @@ To install an Apache Maven package from {% data variables.product.prodname_regis
{% data reusables.package_registry.authenticate-step %}
2. Add the package dependencies to the `dependencies` element of your project *pom.xml* file, replacing `com.example:test` with your package.
```
```xml
<dependencies>
<dependency>
<groupId>com.example</groupId>

2
content/packages/guides/configuring-npm-for-use-with-github-packages.md
View File

@@ -162,7 +162,7 @@ You also need to add the *.npmrc* file to your project so all requests to instal
{% data reusables.package_registry.add-npmrc-to-repo-step %}
4. Configure *package.json* in your project to use the package you are installing. To add your package dependencies to the *package.json* file for {% data variables.product.prodname_registry %}, specify the full-scoped package name, such as `@my-org/server`. For packages from *npmjs.com*, specify the full name, such as `@babel/core` or `@lodash`. For example, this following *package.json* uses the `@octo-org/octo-app` package as a dependency.
```
```json
{
"name": "@my-org/server",
"version": "1.0.0",

6
content/packages/guides/configuring-rubygems-for-use-with-github-packages.md
View File

@@ -108,7 +108,7 @@ $ bundle config https://{% if currentVersion == "free-pro-team@latest" %}rubygem
To publish multiple gems to the same repository, you can include the URL to the {% data variables.product.prodname_dotcom %} repository in the `github_repo` field in `gem.metadata`. If you include this field, {% data variables.product.prodname_dotcom %} matches the repository based on this value, instead of using the gem name.{% if enterpriseServerVersions contains currentVersion %} Replace *HOSTNAME* with the host name of your {% data variables.product.prodname_ghe_server %} instance.{% endif %}
```
```ruby
gem.metadata = { "github_repo" => "ssh://{% if currentVersion == "free-pro-team@latest" %}github.com{% else %}HOSTNAME{% endif %}/OWNER/REPOSITORY" }
```
@@ -119,7 +119,7 @@ You can use gems from {% data variables.product.prodname_registry %} much like y
{% data reusables.package_registry.authenticate-step %}
2. For Bundler, add your {% data variables.product.prodname_dotcom %} user or organization as a source in your *Gemfile* to fetch gems from this new source. For example, you can add a new `source` block to your *Gemfile* that uses {% data variables.product.prodname_registry %} only for the packages you specify, replacing *GEM NAME* with the package you want to install from {% data variables.product.prodname_registry %} and *OWNER* with the user or organization that owns the repository containing the gem you want to install.{% if enterpriseServerVersions contains currentVersion %} Replace `REGISTRY-URL` with the URL for your instance's Rubygems registry. If your instance has subdomain isolation enabled, use `rubygems.HOSTNAME`. If your instance has subdomain isolation disabled, use `HOSTNAME/_registry/rubygems`. In either case, replace *HOSTNAME* with the host name of your {% data variables.product.prodname_ghe_server %} instance.{% endif %}
```
```ruby
source "https://rubygems.org"
gem "rails"
@@ -131,7 +131,7 @@ You can use gems from {% data variables.product.prodname_registry %} much like y
3. For Bundler versions earlier than 1.7.0, you need to add a new global `source`. For more information on using Bundler, see the [bundler.io documentation](http://bundler.io/v1.5/gemfile.html).
```
```ruby
source "https://{% if currentVersion == "free-pro-team@latest" %}rubygems.pkg.github.com{% else %}REGISTRY-URL{% endif %}/OWNER"
source "https://rubygems.org"

4
content/packages/manage-packages/deleting-a-package.md
View File

@@ -58,7 +58,7 @@ Use the `deletePackageVersion` mutation in the GraphQL API. You must use a token
Here is an example cURL command to delete a package version with the package version ID of `MDIyOlJlZ2lzdHJ5UGFja2FnZVZlcnNpb243MTExNg`, using a personal access token.
{% if currentVersion == "free-pro-team@latest" %}
```
```shell
curl -X POST \
-H "Accept: application/vnd.github.package-deletes-preview+json" \
-H "Authorization: bearer TOKEN" \
@@ -68,7 +68,7 @@ https://api.github.com/graphql
{% else %}
```
```shell
curl -X POST \
-H "Accept: application/vnd.github.package-deletes-preview+json" \
-H "Authorization: bearer TOKEN" \

18
content/rest/overview/resources-in-the-rest-api.md
View File

@@ -31,7 +31,7 @@ For information about GitHub's GraphQL API, see the [v4 documentation](/graphql)
sent and received as JSON.
```shell
$ curl -i {% data variables.product.api_url_pre %}/users/octocat/orgs
$ curl -I {% data variables.product.api_url_pre %}/users/octocat/orgs
> HTTP/1.1 200 OK
> Server: nginx
@@ -137,7 +137,7 @@ Read [more about unauthenticated rate limiting](#increasing-the-unauthenticated-
Authenticating with invalid credentials will return `401 Unauthorized`:
```shell
$ curl -i {% data variables.product.api_url_pre %} -u foo:bar
$ curl -I {% data variables.product.api_url_pre %} -u foo:bar
> HTTP/1.1 401 Unauthorized
> {
@@ -369,7 +369,7 @@ Note that [the Search API has custom rate limit rules](/rest/reference/search#ra
The returned HTTP headers of any API request show your current rate limit status:
```shell
$ curl -i {% data variables.product.api_url_pre %}/users/octocat
$ curl -I {% data variables.product.api_url_pre %}/users/octocat
> HTTP/1.1 200 OK
> Date: Mon, 01 Jul 2013 17:27:06 GMT
> Status: 200 OK
@@ -469,7 +469,7 @@ User-Agent: Awesome-Octocat-App
cURL sends a valid `User-Agent` header by default. If you provide an invalid `User-Agent` header via cURL (or via an alternative client), you will receive a `403 Forbidden` response:
```shell
$ curl -iH 'User-Agent: ' {% data variables.product.api_url_pre %}/meta
$ curl -IH 'User-Agent: ' {% data variables.product.api_url_pre %}/meta
> HTTP/1.0 403 Forbidden
> Connection: close
> Content-Type: text/html
@@ -501,7 +501,7 @@ whenever possible.
{% endif %}
```shell
$ curl -i {% data variables.product.api_url_pre %}/user
$ curl -I {% data variables.product.api_url_pre %}/user
> HTTP/1.1 200 OK
> Cache-Control: private, max-age=60
> ETag: "644b5b0155e6404a9cc4bd9d8b1ae730"
@@ -512,7 +512,7 @@ $ curl -i {% data variables.product.api_url_pre %}/user
> X-RateLimit-Remaining: 4996
> X-RateLimit-Reset: 1372700873
$ curl -i {% data variables.product.api_url_pre %}/user -H 'If-None-Match: "644b5b0155e6404a9cc4bd9d8b1ae730"'
$ curl -I {% data variables.product.api_url_pre %}/user -H 'If-None-Match: "644b5b0155e6404a9cc4bd9d8b1ae730"'
> HTTP/1.1 304 Not Modified
> Cache-Control: private, max-age=60
> ETag: "644b5b0155e6404a9cc4bd9d8b1ae730"
@@ -523,7 +523,7 @@ $ curl -i {% data variables.product.api_url_pre %}/user -H 'If-None-Match: "644b
> X-RateLimit-Remaining: 4996
> X-RateLimit-Reset: 1372700873
$ curl -i {% data variables.product.api_url_pre %}/user -H "If-Modified-Since: Thu, 05 Jul 2012 15:31:30 GMT"
$ curl -I {% data variables.product.api_url_pre %}/user -H "If-Modified-Since: Thu, 05 Jul 2012 15:31:30 GMT"
> HTTP/1.1 304 Not Modified
> Cache-Control: private, max-age=60
> Last-Modified: Thu, 05 Jul 2012 15:31:30 GMT
@@ -546,7 +546,7 @@ Here's a sample request sent from a browser hitting
`http://example.com`:
```shell
$ curl -i {% data variables.product.api_url_pre %} -H "Origin: http://example.com"
$ curl -I {% data variables.product.api_url_pre %} -H "Origin: http://example.com"
HTTP/1.1 302 Found
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: ETag, Link, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval
@@ -555,7 +555,7 @@ Access-Control-Expose-Headers: ETag, Link, X-GitHub-OTP, X-RateLimit-Limit, X-Ra
This is what the CORS preflight request looks like:
```shell
$ curl -i {% data variables.product.api_url_pre %} -H "Origin: http://example.com" -X OPTIONS
$ curl -I {% data variables.product.api_url_pre %} -H "Origin: http://example.com" -X OPTIONS
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Authorization, Content-Type, If-Match, If-Modified-Since, If-None-Match, If-Unmodified-Since, X-GitHub-OTP, X-Requested-With

2
contributing/development.md
View File

@@ -48,7 +48,7 @@ For more detailed instructions, please see this [VS Code recipe](https://github.
While running the local server, you can visit [localhost:4000/dev-toc](http://localhost:4000/dev-toc) to view a top-level TOC of all the content in the site. This page is not available on https://docs.github.com. It was created for internal GitHub writers' use.
At the `/dev-toc` path, you'll see a list of available versions. Click a version, and a list of products will appear. Note that the TOC content is versioned. If you are viewing `free-pro-team@latest` and you click the `Enterprise Admin` product, it will be empty, because there isn't any Admin content available on that version.
At the `/dev-toc` path, you'll see a list of available versions. Click a version, and a list of products will appear. Note that the TOC content is versioned. If you are viewing the `GitHub.com` version and you click the `Enterprise Admin` product, it will be empty, because there isn't any Admin content available on that version.
## Site structure

6
contributing/permalinks.md
View File

@@ -4,7 +4,7 @@ Because the site is dynamic, it does not build HTML files for each different ver
For example, an article that is available in currently supported versions will have permalink URLs like the following:
* `/en/free-pro-team@latest/github/getting-started-with-github/set-up-git`
* `/en/github/getting-started-with-github/set-up-git`
* `/en/enterprise-server@2.22/github/getting-started-with-github/set-up-git`
* `/en/enterprise-server@2.21/github/getting-started-with-github/set-up-git`
* `/en/enterprise-server@2.20/github/getting-started-with-github/set-up-git`
@@ -12,10 +12,8 @@ For example, an article that is available in currently supported versions will h
An article that is not available in Enterprise will have just one permalink:
* `/en/free-pro-team@latest/github/getting-started-with-github/set-up-git`
* `/en/github/getting-started-with-github/set-up-git`
**If you are a content contributor:** You don't need to worry about supported versions when adding a link to a document. Following the examples above, if you want to reference an article you can just use its relative location:
* `/github/getting-started-with-github/set-up-git`
*(Please note that using a hard-coded link or supported version will result in an error when your submitted PR is automatically tested)*

3
data/reusables/gated-features/branch-restrictions.md
View File

@@ -1,3 +0,0 @@
{% data reusables.gated-features.protected-branches %}
<br>
Branch restriction is a type of branch protection that's available for public and private repositories owned by organizations in {% data variables.product.prodname_team %}, {% data variables.product.prodname_ghe_cloud %},{% if currentVersion == "github-ae@latest" %} {% data variables.product.prodname_ghe_managed %},{% endif %} and {% data variables.product.prodname_ghe_server %}. {% if currentVersion == "free-pro-team@latest" %}{% data reusables.gated-features.more-info %}{% endif %}

2
data/reusables/gated-features/protected-branches.md
View File

@@ -1 +1 @@
Protected branches are available in public repositories with {% data variables.product.prodname_free_user %} and {% data variables.product.prodname_free_team %} for organizations, and in public and private repositories with {% data variables.product.prodname_pro %}, {% data variables.product.prodname_team %}, {% data variables.product.prodname_ghe_cloud %},{% if currentVersion == "github-ae@latest" %} {% data variables.product.prodname_ghe_managed %},{% endif %} and {% data variables.product.prodname_ghe_server %}. {% if currentVersion == "free-pro-team@latest" %}{% data reusables.gated-features.more-info %}{% endif %}
{% if currentVersion == "github-ae@latest" %}Protected branches are available in internal and private repositories with {% data variables.product.prodname_ghe_managed %}, {% else%}Protected branches are available {% endif %}in public repositories with {% data variables.product.prodname_free_user %} and {% data variables.product.prodname_free_team %} for organizations, and in public and private repositories with {% data variables.product.prodname_pro %}, {% data variables.product.prodname_team %}, {% data variables.product.prodname_ghe_cloud %}, and {% data variables.product.prodname_ghe_server %}. {% if currentVersion == "free-pro-team@latest" %}{% data reusables.gated-features.more-info %}{% endif %}

1
data/reusables/pull_requests/about-protected-branches.md
View File

@@ -1 +0,0 @@
By default, any pull request can be merged at any time, unless the head branch is in conflict with the base branch.

2
data/reusables/pull_requests/required-checks-must-pass-to-merge.md
View File

@@ -1 +1 @@
If status checks are required for a repository, the required status checks must pass before you can merge your branch into the protected branch. For more information, see "[About required status checks](/articles/about-required-status-checks)."
If status checks are required for a repository, the required status checks must pass before you can merge your branch into the protected branch. For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches#require-status-checks-before-merging)."

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