1
0
mirror of synced 2025-12-19 18:10:59 -05:00

Merge branch 'main' into main

This commit is contained in:
Ethan Palm
2021-04-26 17:14:07 -04:00
committed by GitHub
227 changed files with 8909 additions and 4214 deletions

View File

@@ -25,3 +25,11 @@ Thanks again!
- [ ] I have reviewed my changes in staging. (look for the **deploy-to-heroku** link in your pull request, then click **View deployment**)
- [ ] For content changes, I have reviewed the [localization checklist](https://github.com/github/docs/blob/main/contributing/localization-checklist.md)
- [ ] For content changes, I have reviewed the [Content style guide for GitHub Docs](https://github.com/github/docs/blob/main/contributing/content-style-guide.md).
### Writer impact (This section is for GitHub staff members only):
- [ ] This pull request impacts the contribution experience
- [ ] I have added the 'writer impact' label
- [ ] I have added a description and/or a video demo of the changes below (eg. a "before and after video")
<!-- Description of the writer impact here -->

View File

@@ -0,0 +1,69 @@
name: Copy to REST API issue to docs-content
# **What it does**: Copies an issue in the open source repo to the docs-content repo, comments on and closes the original issue
# **Why we have it**: REST API updates cannot be made in the open source repo. Instead, we copy the issue to an internal issue (we do not transfer so that the issue does not disappear for the contributor) and close the original issue.
# **Who does it impact**: Open source and docs-content maintainers
on:
issues:
types:
- labeled
jobs:
transfer-issue:
name: Transfer issue
runs-on: ubuntu-latest
if: github.event.label.name == 'rest-description' && github.repository == 'github/docs'
steps:
- name: Check if this run was triggered by a member of the docs team
uses: actions/github-script@626af12fe9a53dc2972b48385e7fe7dec79145c9
id: triggered-by-member
with:
github-token: ${{secrets.DOCUBOT_FR_PROJECT_BOARD_WORKFLOWS_REPO_ORG_READ_SCOPES}}
result-encoding: string
script: |
const triggerer_login = context.payload.sender.login
const teamMembers = await github.request(
`/orgs/github/teams/docs/members?per_page=100`
)
const logins = teamMembers.data.map(member => member.login)
if (logins.includes(triggerer_login)) {
console.log(`This workflow was triggered by ${triggerer_login} (on the docs team).`)
return 'true'
}
console.log(`This workflow was triggered by ${triggerer_login} (not on the docs team), so no action will be taken.`)
return 'false'
- name: Exit if not triggered by a docs team member
if: steps.triggered-by-member.outputs.result == 'false'
run: |
echo Aborting. This workflow must be triggered by a member of the docs team.
exit 1
- name: Create an issue in the docs-content repo
run: |
new_issue_url="$(gh issue create --title "$ISSUE_TITLE" --body "$ISSUE_BODY" --repo github/docs-content)"
echo 'NEW_ISSUE='$new_issue_url >> $GITHUB_ENV
env:
GITHUB_TOKEN: ${{secrets.DOCUBOT_FR_PROJECT_BOARD_WORKFLOWS_REPO_ORG_READ_SCOPES}}
ISSUE_TITLE: ${{ github.event.issue.title }}
ISSUE_BODY: ${{ github.event.issue.body }}
- name: Comment on the new issue
run: gh issue comment $NEW_ISSUE --body "This issue was originally opened in the open source repo as $OLD_ISSUE"
env:
GITHUB_TOKEN: ${{secrets.DOCUBOT_FR_PROJECT_BOARD_WORKFLOWS_REPO_ORG_READ_SCOPES}}
NEW_ISSUE: ${{ env.NEW_ISSUE }}
OLD_ISSUE: ${{ github.event.issue.html_url }}
- name: Comment on the old issue
run: gh issue comment $OLD_ISSUE --body "Thank you for opening this issue! Updates to the REST API description must be made internally. I have copied your issue to an internal issue, so I will close this issue."
env:
GITHUB_TOKEN: ${{secrets.DOCUBOT_FR_PROJECT_BOARD_WORKFLOWS_REPO_ORG_READ_SCOPES}}
OLD_ISSUE: ${{ github.event.issue.html_url }}
- name: Close the old issue
run: gh issue close $OLD_ISSUE
env:
GITHUB_TOKEN: ${{secrets.DOCUBOT_FR_PROJECT_BOARD_WORKFLOWS_REPO_ORG_READ_SCOPES}}
OLD_ISSUE: ${{ github.event.issue.html_url }}

View File

@@ -1,6 +1,6 @@
name: Move and unlabel ready to merge issues
name: Move and unlabel ready to merge PRs
# **What it does**: This moves ready to merge issues on the project board for the open source repo. When an issue in the open source repo is labeled "ready to merge," the "waiting for review" label is removed and the issue is moved to the "Triage" column.
# **What it does**: When a PR in the open source repo is labeled "ready to merge," the "waiting for review" label is removed and the PR is moved to the "Triage" column.
# **Why we have it**: To help with managing our project boards.
# **Who does it impact**: Open source contributors, open-source maintainers.
@@ -14,7 +14,7 @@ jobs:
if: github.repository == 'github/docs' && github.event.label.name == 'ready to merge'
runs-on: ubuntu-latest
steps:
- name: move issue
- name: move PR
uses: alex-page/github-project-automation-plus@fdb7991b72040d611e1123d2b75ff10eda9372c9
with:
project: Docs team reviews

View File

@@ -0,0 +1,55 @@
name: Transfer REST API issue to rest-api-description
# **What it does**: Transfers an issue in the open source repo to the open source rest-api-description repo
# **Why we have it**: Requests to change the OpenAPI schema (unless the schema is just a description update) should be made in github/rest-api-description
# **Who does it impact**: Open source and docs-content maintainers
on:
issues:
types:
- labeled
jobs:
transfer-issue:
name: Transfer issue
runs-on: ubuntu-latest
if: github.event.label.name == 'rest-schema' && github.repository == 'github/docs'
steps:
- name: Check if this run was triggered by a member of the docs team
uses: actions/github-script@626af12fe9a53dc2972b48385e7fe7dec79145c9
id: triggered-by-member
with:
github-token: ${{secrets.DOCUBOT_FR_PROJECT_BOARD_WORKFLOWS_REPO_ORG_READ_SCOPES}}
result-encoding: string
script: |
const triggerer_login = context.payload.sender.login
const teamMembers = await github.request(
`/orgs/github/teams/docs/members?per_page=100`
)
const logins = teamMembers.data.map(member => member.login)
if (logins.includes(triggerer_login)) {
console.log(`This workflow was triggered by ${triggerer_login} (on the docs team).`)
return 'true'
}
console.log(`This workflow was triggered by ${triggerer_login} (not on the docs team), so no action will be taken.`)
return 'false'
- name: Exit if not triggered by a docs team member
if: steps.triggered-by-member.outputs.result == 'false'
run: |
echo Aborting. This workflow must be triggered by a member of the docs team.
exit 1
- name: Comment on the old issue
run: gh issue comment $OLD_ISSUE --body "Thank you for opening this issue! Changes to the REST API schema can be requested in [github/rest-api-description](https://github.com/github/rest-api-description). I will transfer your issue over to that open source repo."
env:
GITHUB_TOKEN: ${{secrets.DOCUBOT_FR_PROJECT_BOARD_WORKFLOWS_REPO_ORG_READ_SCOPES}}
OLD_ISSUE: ${{ github.event.issue.html_url }}
- name: Transfer the issue to the rest-api-description repo
run: |
new_issue_url="$(gh issue transfer $OLD_ISSUE github/rest-api-description)"
echo 'NEW_ISSUE='$new_issue_url >> $GITHUB_ENV
env:
GITHUB_TOKEN: ${{secrets.DOCUBOT_FR_PROJECT_BOARD_WORKFLOWS_REPO_ORG_READ_SCOPES}}
OLD_ISSUE: ${{ github.event.issue.html_url }}

View File

@@ -95,6 +95,8 @@ A [pull request](https://docs.github.com/en/github/collaborating-with-issues-and
When we merge those changes, they should be deployed to the live site within 24 hours. :earth_africa: To learn more about opening a pull request in this repo, see [Opening a pull request](#opening-a-pull-request) below.
We cannot accept contributions to the [REST API reference documentation](https://docs.github.com/en/rest/reference). If you spot an inaccuracy in the REST API reference documentation, open an issue in the [github/rest-api-description](https://github.com/github/rest-api-description/issues/new?template=schema-inaccuracy.md) repository.
### :question: Support
We are a small team working hard to keep up with the documentation demands of a continuously changing product. Unfortunately, we just can't help with support questions in this repository. If you are experiencing a problem with GitHub, unrelated to our documentation, please [contact GitHub Support directly](https://support.github.com/contact). Any issues, discussions, or pull requests opened here requesting support will be given information about how to contact GitHub Support, then closed and locked.

Binary file not shown.

After

Width:  |  Height:  |  Size: 115 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 72 KiB

After

Width:  |  Height:  |  Size: 33 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 53 KiB

After

Width:  |  Height:  |  Size: 21 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 126 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 125 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 108 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 58 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 31 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 42 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 42 KiB

View File

@@ -0,0 +1 @@
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16" width="16" height="16"><path fill-rule="evenodd" d="M1.75 2.5a.25.25 0 00-.25.25v10.5c0 .138.112.25.25.25h.94a.76.76 0 01.03-.03l6.077-6.078a1.75 1.75 0 012.412-.06L14.5 10.31V2.75a.25.25 0 00-.25-.25H1.75zm12.5 11H4.81l5.048-5.047a.25.25 0 01.344-.009l4.298 3.889v.917a.25.25 0 01-.25.25zm1.75-.25V2.75A1.75 1.75 0 0014.25 1H1.75A1.75 1.75 0 000 2.75v10.5C0 14.216.784 15 1.75 15h12.5A1.75 1.75 0 0016 13.25zM5.5 6a.5.5 0 11-1 0 .5.5 0 011 0zM7 6a2 2 0 11-4 0 2 2 0 014 0z"></path></svg>

After

Width:  |  Height:  |  Size: 548 B

View File

@@ -53,6 +53,7 @@ For a definition of common terms, see "[Core concepts for {% data variables.prod
Browse the complete list of CI workflow templates offered by {% data variables.product.product_name %} in the {% if currentVersion == "free-pro-team@latest" %}[actions/starter-workflows](https://github.com/actions/starter-workflows/tree/main/ci) repository{% else %} `actions/starter-workflows` repository on {% data variables.product.product_location %}{% endif %}.
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" or currentVersion == "github-ae@next" %}
### Skipping workflow runs
If you want to temporarily prevent a workflow from being triggered, you can add a skip instruction to the commit message. Workflows that would otherwise be triggered `on: push` or `on: pull_request`, won't be triggered if you add any any of the following strings to the commit message in a push, or the HEAD commit of a pull request:
@@ -72,6 +73,7 @@ You won't be able to merge the pull request if your repository is configured to
**Note:** Skip instructions only apply to the `push` and `pull_request` events. For example, adding `[skip ci]` to a commit message won't stop a workflow that's triggered `on: pull_request_target` from running.
{% endnote %}
{% endif %}
### Notifications for workflow runs

View File

@@ -29,7 +29,6 @@ In the tutorial, you will first make a workflow file that uses the [`andymckay/l
2. {% data reusables.actions.make-workflow-file %}
3. Copy the following YAML contents into your workflow file.
{% raw %}
```yaml{:copy}
name: Label issues
on:
@@ -39,14 +38,17 @@ In the tutorial, you will first make a workflow file that uses the [`andymckay/l
- opened
jobs:
label_issues:
runs-on: ubuntu-latest
runs-on: ubuntu-latest{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
issues: write{% endif %}
steps:
- name: Label issues
uses: andymckay/labeler@1.0.2
with:
add-labels: "triage"
repo-token: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
```
{% endraw %}
4. Customize the parameters in your workflow file:
- Change the value for `add-labels` to the list of labels that you want to add to the issue. Separate multiple labels with commas. For example, `"help wanted, good first issue"`. For more information about labels, see "[Managing labels](/github/managing-your-work-on-github/managing-labels#applying-labels-to-issues-and-pull-requests)."
5. {% data reusables.actions.commit-workflow %}

View File

@@ -227,7 +227,6 @@ jobs:
You can configure your workflow to publish your Dotnet package to a package registry when your CI tests pass. You can use repository secrets to store any tokens or credentials needed to publish your binary. The following example creates and publishes a package to {% data variables.product.prodname_registry %} using `dotnet core cli`.
{% raw %}
```yaml
name: Upload dotnet package
@@ -237,7 +236,10 @@ on:
jobs:
deploy:
runs-on: ubuntu-latest
runs-on: ubuntu-latest{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
packages: write
contents: read{% endif %}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-dotnet@v1
@@ -245,11 +247,10 @@ jobs:
dotnet-version: '3.1.x' # SDK Version to use.
source-url: https://nuget.pkg.github.com/<owner>/index.json
env:
NUGET_AUTH_TOKEN: ${{secrets.GITHUB_TOKEN}}
NUGET_AUTH_TOKEN: {% raw %}${{secrets.GITHUB_TOKEN}}{% endraw %}
- run: dotnet build --configuration Release <my project>
- name: Create the package
run: dotnet pack --configuration Release <my project>
- name: Publish the package to GPR
run: dotnet nuget push <my project>/bin/Release/*.nupkg
```
{% endraw %}

View File

@@ -264,7 +264,6 @@ You can configure your workflow to publish your Ruby package to any package regi
You can store any access tokens or credentials needed to publish your package using repository secrets. The following example creates and publishes a package to `GitHub Package Registry` and `RubyGems`.
{% raw %}
```yaml
name: Ruby Gem
@@ -281,9 +280,12 @@ on:
jobs:
build:
name: Build + Publish
runs-on: ubuntu-latest
runs-on: ubuntu-latest{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
packages: write
contents: read{% endif %}
steps:
steps:{% raw %}
- uses: actions/checkout@v2
- name: Set up Ruby 2.6
uses: ruby/setup-ruby@v1
@@ -312,6 +314,5 @@ jobs:
gem build *.gemspec
gem push *.gem
env:
GEM_HOST_API_KEY: "${{secrets.RUBYGEMS_AUTH_TOKEN}}"
GEM_HOST_API_KEY: "${{secrets.RUBYGEMS_AUTH_TOKEN}}"{% endraw %}
```
{% endraw %}

View File

@@ -29,7 +29,6 @@ In the tutorial, you will first make a workflow file that uses the [`actions/sta
2. {% data reusables.actions.make-workflow-file %}
3. Copy the following YAML contents into your workflow file.
{% raw %}
```yaml{:copy}
name: Close inactive issues
on:
@@ -38,7 +37,10 @@ In the tutorial, you will first make a workflow file that uses the [`actions/sta
jobs:
close-issues:
runs-on: ubuntu-latest
runs-on: ubuntu-latest{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
issues: write
pull-requests: write{% endif %}
steps:
- uses: actions/stale@v3
with:
@@ -49,9 +51,9 @@ In the tutorial, you will first make a workflow file that uses the [`actions/sta
close-issue-message: "This issue was closed because it has been inactive for 14 days since being marked as stale."
days-before-pr-stale: -1
days-before-pr-close: -1
repo-token: ${{ secrets.GITHUB_TOKEN }}
repo-token: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
```
{% endraw %}
4. Customize the parameters in your workflow file:
- Change the value for `on.schedule` to dictate when you want this workflow to run. In the example above, the workflow will run every day at 1:30 UTC. For more information about scheduled workflows, see "[Scheduled events](/actions/reference/events-that-trigger-workflows#scheduled-events)."
- Change the value for `days-before-issue-stale` to the number of days without activity before the `actions/stale` action labels an issue. If you never want this action to label issues, set this value to `-1`.

View File

@@ -29,7 +29,6 @@ In the tutorial, you will first make a workflow file that uses the [`peter-evans
2. {% data reusables.actions.make-workflow-file %}
3. Copy the following YAML contents into your workflow file.
{% raw %}
```yaml{:copy}
name: Add comment
on:
@@ -39,16 +38,18 @@ In the tutorial, you will first make a workflow file that uses the [`peter-evans
jobs:
add-comment:
if: github.event.label.name == 'help-wanted'
runs-on: ubuntu-latest
runs-on: ubuntu-latest{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
issues: write{% endif %}
steps:
- name: Add comment
uses: peter-evans/create-or-update-comment@v1
with:
issue-number: ${{ github.event.issue.number }}
issue-number: {% raw %}${{ github.event.issue.number }}{% endraw %}
body: |
This issue is available for anyone to work on. **Make sure to reference this issue in your pull request.** :sparkles: Thank you for your contribution! :sparkles:
```
{% endraw %}
4. Customize the parameters in your workflow file:
- Replace `help-wanted` in `if: github.event.label.name == 'help-wanted'` with the label that you want to act on. If you want to act on more than one label, separate the conditions with `||`. For example, `if: github.event.label.name == 'bug' || github.event.label.name == 'fix me'` will comment whenever the `bug` or `fix me` labels are added to an issue.
- Change the value for `body` to the comment that you want to add. GitHub flavored markdown is supported. For more information about markdown, see "[Basic writing and formatting syntax](/github/writing-on-github/basic-writing-and-formatting-syntax)."

View File

@@ -73,7 +73,6 @@ The following example workflow demonstrates how to build a container image and p
Ensure that you provide your own values for all the variables in the `env` key of the workflow.
{% raw %}
```yaml{:copy}
name: Deploy to Amazon ECS
@@ -98,9 +97,12 @@ defaults:
jobs:
deploy:
name: Deploy
runs-on: ubuntu-latest
runs-on: ubuntu-latest{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
packages: write
contents: read{% endif %}
steps:
{% raw %}steps:
- name: Checkout
uses: actions/checkout@v2
@@ -142,9 +144,9 @@ jobs:
task-definition: ${{ steps.task-def.outputs.task-definition }}
service: ${{ env.ECS_SERVICE }}
cluster: ${{ env.ECS_CLUSTER }}
wait-for-service-stability: true
wait-for-service-stability: true{% endraw %}
```
{% endraw %}
### Additional resources

View File

@@ -98,7 +98,6 @@ The `build-push-action` options required for {% data variables.product.prodname_
* `registry`: Must be set to `docker.pkg.github.com`.
* `repository`: Must be set in the format `OWNER/REPOSITORY/IMAGE_NAME`. For example, for an image named `octo-image` stored on {% data variables.product.prodname_dotcom %} at `http://github.com/octo-org/octo-repo`, the `repository` option should be set to `octo-org/octo-repo/octo-image`.
{% raw %}
```yaml{:copy}
name: Publish Docker image
on:
@@ -107,21 +106,23 @@ on:
jobs:
push_to_registry:
name: Push Docker image to GitHub Packages
runs-on: ubuntu-latest
runs-on: ubuntu-latest{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
packages: write
contents: read{% endif %}
steps:
- name: Check out the repo
uses: actions/checkout@v2
- name: Push to GitHub Packages
uses: docker/build-push-action@v1
with:
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
username: {% raw %}${{ github.actor }}{% endraw %}
password: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
registry: docker.pkg.github.com
repository: my-org/my-repo/my-image
tag_with_ref: true
```
{% endraw %}
{% data reusables.github-actions.docker-tag-with-ref %}
@@ -131,7 +132,6 @@ In a single workflow, you can publish your Docker image to multiple registries b
The following example workflow uses the `build-push-action` steps from the previous sections ("[Publishing images to Docker Hub](#publishing-images-to-docker-hub)" and "[Publishing images to {% data variables.product.prodname_registry %}](#publishing-images-to-github-packages)") to create a single workflow that pushes to both registries.
{% raw %}
```yaml{:copy}
name: Publish Docker image
on:
@@ -140,26 +140,28 @@ on:
jobs:
push_to_registries:
name: Push Docker image to multiple registries
runs-on: ubuntu-latest
runs-on: ubuntu-latest{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
packages: write
contents: read{% endif %}
steps:
- name: Check out the repo
uses: actions/checkout@v2
- name: Push to Docker Hub
uses: docker/build-push-action@v1
with:
username: ${{ secrets.DOCKER_USERNAME }}
password: ${{ secrets.DOCKER_PASSWORD }}
username: {% raw %}${{ secrets.DOCKER_USERNAME }}{% endraw %}
password: {% raw %}${{ secrets.DOCKER_PASSWORD }}{% endraw %}
repository: my-docker-hub-namespace/my-docker-hub-repository
tag_with_ref: true
- name: Push to GitHub Packages
uses: docker/build-push-action@v1
with:
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
username: {% raw %}${{ github.actor }}{% endraw %}
password: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
registry: docker.pkg.github.com
repository: my-org/my-repo/my-image
tag_with_ref: true
```
{% endraw %}
The above workflow checks out the {% data variables.product.prodname_dotcom %} repository, and uses the `build-push-action` action twice to build and push the Docker image to Docker Hub and {% data variables.product.prodname_registry %}. For both steps, it sets the `build-push-action` option [`tag_with_ref`](https://github.com/marketplace/actions/build-and-push-docker-images#tag_with_ref) to automatically tag the built Docker image with the Git reference of the workflow event. This workflow is triggered on publishing a {% data variables.product.prodname_dotcom %} release, so the reference for both registries will be the Git tag for the release.

View File

@@ -108,7 +108,7 @@ Each time you create a new release, you can trigger a workflow to publish your p
You can define a new Maven repository in the publishing block of your _build.gradle_ that points to {% data variables.product.prodname_registry %}. In that repository configuration, you can also take advantage of environment variables set in your CI workflow run. You can use the `GITHUB_ACTOR` environment variable as a username, and you can set the `GITHUB_TOKEN` environment variable with your `GITHUB_TOKEN` secret.
The `GITHUB_TOKEN` exists in your repository by default and has read and write permissions for packages in the repository where the workflow runs. For more information, see "[Authenticating with the GITHUB_TOKEN](/actions/configuring-and-managing-workflows/authenticating-with-the-github_token)."
{% data reusables.github-actions.github-token-permissions %}
For example, if your organization is named "octocat" and your repository is named "hello-world", then the {% data variables.product.prodname_registry %} configuration in _build.gradle_ would look similar to the below example.
@@ -133,7 +133,6 @@ publishing {
With this configuration, you can create a workflow that publishes your package to the Maven Central Repository by running the `gradle publish` command.
{% raw %}
```yaml{:copy}
name: Publish package to GitHub Packages
on:
@@ -141,7 +140,10 @@ on:
types: [created]
jobs:
publish:
runs-on: ubuntu-latest
runs-on: ubuntu-latest {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
contents: read
packages: write {% endif %}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v2
@@ -151,12 +153,11 @@ jobs:
- name: Publish package
run: gradle publish
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
GITHUB_TOKEN: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
```
{% endraw %}
{% data reusables.github-actions.gradle-workflow-steps %}
1. Runs the `gradle publish` command to publish to {% data variables.product.prodname_registry %}. The `GITHUB_TOKEN` environment variable will be set with the content of the `GITHUB_TOKEN` secret.
1. Runs the `gradle publish` command to publish to {% data variables.product.prodname_registry %}. The `GITHUB_TOKEN` environment variable will be set with the content of the `GITHUB_TOKEN` secret. {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}The `permissions` key specifies the access that the `GITHUB_TOKEN` secret will allow.{% endif %}
For more information about using secrets in your workflow, see "[Creating and using encrypted secrets](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
@@ -199,7 +200,6 @@ publishing {
With this configuration, you can create a workflow that publishes your package to both the Maven Central Repository and {% data variables.product.prodname_registry %} by running the `gradle publish` command.
{% raw %}
```yaml{:copy}
name: Publish package to the Maven Central Repository and GitHub Packages
on:
@@ -207,7 +207,10 @@ on:
types: [created]
jobs:
publish:
runs-on: ubuntu-latest
runs-on: ubuntu-latest {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
contents: read
packages: write {% endif %}
steps:
- uses: actions/checkout@v2
- name: Set up Java
@@ -217,14 +220,13 @@ jobs:
distribution: 'adopt'
- name: Publish to the Maven Central Repository
run: gradle publish
env:
env: {% raw %}
MAVEN_USERNAME: ${{ secrets.OSSRH_USERNAME }}
MAVEN_PASSWORD: ${{ secrets.OSSRH_TOKEN }}
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}{% endraw %}
```
{% endraw %}
{% data reusables.github-actions.gradle-workflow-steps %}
1. Runs the `gradle publish` command to publish to the `OSSRH` Maven repository and {% data variables.product.prodname_registry %}. The `MAVEN_USERNAME` environment variable will be set with the contents of your `OSSRH_USERNAME` secret, and the `MAVEN_PASSWORD` environment variable will be set with the contents of your `OSSRH_TOKEN` secret. The `GITHUB_TOKEN` environment variable will be set with the content of the `GITHUB_TOKEN` secret.
1. Runs the `gradle publish` command to publish to the `OSSRH` Maven repository and {% data variables.product.prodname_registry %}. The `MAVEN_USERNAME` environment variable will be set with the contents of your `OSSRH_USERNAME` secret, and the `MAVEN_PASSWORD` environment variable will be set with the contents of your `OSSRH_TOKEN` secret. The `GITHUB_TOKEN` environment variable will be set with the content of the `GITHUB_TOKEN` secret. {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}The `permissions` key specifies the access that the `GITHUB_TOKEN` secret will allow.{% endif %}
For more information about using secrets in your workflow, see "[Creating and using encrypted secrets](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."

View File

@@ -112,9 +112,9 @@ This workflow performs the following steps:
Each time you create a new release, you can trigger a workflow to publish your package. The workflow in the example below runs when the `release` event triggers with type `created`. The workflow publishes the package to {% data variables.product.prodname_registry %} if CI tests pass. For more information on the `release` event, see "[Events that trigger workflows](/actions/reference/events-that-trigger-workflows#release)."
In this workflow, you can use the `setup-java` action. This action installs the given version of the JDK into the `PATH`, and also sets up a Maven _settings.xml_ for publishing the package to {% data variables.product.prodname_registry %}. The generated _settings.xml_ defines authentication for a server with an `id` of `github`, using the `GITHUB_ACTOR` environment variable as the username and the `GITHUB_TOKEN` environment variable as the password.
In this workflow, you can use the `setup-java` action. This action installs the given version of the JDK into the `PATH`, and also sets up a Maven _settings.xml_ for publishing the package to {% data variables.product.prodname_registry %}. The generated _settings.xml_ defines authentication for a server with an `id` of `github`, using the `GITHUB_ACTOR` environment variable as the username and the `GITHUB_TOKEN` environment variable as the password. The `GITHUB_TOKEN` environment variable is assigned the value of the special `GITHUB_TOKEN` secret.
The `GITHUB_TOKEN` exists in your repository by default and has read and write permissions for packages in the repository where the workflow runs. For more information, see "[Authenticating with the GITHUB_TOKEN](/actions/configuring-and-managing-workflows/authenticating-with-the-github_token)."
{% data reusables.github-actions.github-token-permissions %}
For a Maven-based project, you can make use of these settings by creating a distribution repository in your _pom.xml_ file with an `id` of `github` that points to your {% data variables.product.prodname_registry %} endpoint.
@@ -137,7 +137,6 @@ For example, if your organization is named "octocat" and your repository is name
With this configuration, you can create a workflow that publishes your package to {% data variables.product.prodname_registry %} by making use of the automatically generated _settings.xml_.
{% raw %}
```yaml{:copy}
name: Publish package to GitHub Packages
on:
@@ -145,7 +144,10 @@ on:
types: [created]
jobs:
publish:
runs-on: ubuntu-latest
runs-on: ubuntu-latest {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
contents: read
packages: write {% endif %}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v2
@@ -155,9 +157,8 @@ jobs:
- name: Publish package
run: mvn --batch-mode deploy
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
GITHUB_TOKEN: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
```
{% endraw %}
This workflow performs the following steps:
@@ -173,7 +174,6 @@ You can publish your packages to both the Maven Central Repository and {% data v
Ensure your _pom.xml_ file includes a distribution management repository for both your {% data variables.product.prodname_dotcom %} repository and your Maven Central Repository provider. For example, if you deploy to the Central Repository through the OSSRH hosting project, you might want to specify it in a distribution management repository with the `id` set to `ossrh`, and you might want to specify {% data variables.product.prodname_registry %} in a distribution management repository with the `id` set to `github`.
{% raw %}
```yaml{:copy}
name: Publish package to the Maven Central Repository and GitHub Packages
on:
@@ -181,7 +181,10 @@ on:
types: [created]
jobs:
publish:
runs-on: ubuntu-latest
runs-on: ubuntu-latest {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
contents: read
packages: write {% endif %}
steps:
- uses: actions/checkout@v2
- name: Set up Java for publishing to Maven Central Repository
@@ -194,7 +197,7 @@ jobs:
server-password: MAVEN_PASSWORD
- name: Publish to the Maven Central Repository
run: mvn --batch-mode deploy
env:
env:{% raw %}
MAVEN_USERNAME: ${{ secrets.OSSRH_USERNAME }}
MAVEN_PASSWORD: ${{ secrets.OSSRH_TOKEN }}
- name: Set up Java for publishing to GitHub Packages
@@ -205,9 +208,8 @@ jobs:
- name: Publish to GitHub Packages
run: mvn --batch-mode deploy
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}{% endraw %}
```
{% endraw %}
This workflow calls the `setup-java` action twice. Each time the `setup-java` action runs, it overwrites the Maven _settings.xml_ file for publishing packages. For authentication to the repository, the _settings.xml_ file references the distribution management repository `id`, and the username and password.

View File

@@ -112,7 +112,7 @@ However, if you do provide the `repository` key, then the repository in that key
#### Authenticating to the destination repository
To authenticate to the {% data variables.product.prodname_registry %} registry in your workflow, you can use the `GITHUB_TOKEN` from your repository. It is created automatically and has _read_ and _write_ permissions for packages in the repository where the workflow runs. For more information, see "[Authentication in a workflow](/actions/reference/authentication-in-a-workflow)."
To perform authenticated operations against the {% data variables.product.prodname_registry %} registry in your workflow, you can use the `GITHUB_TOKEN`. {% data reusables.github-actions.github-token-permissions %}
If you want to publish your package to a different repository, you must use a personal access token (PAT) that has permission to write to packages in the destination repository. For more information, see "[Creating a personal access token](/github/authenticating-to-github/creating-a-personal-access-token)" and "[Encrypted secrets](/actions/reference/encrypted-secrets)."
@@ -120,7 +120,6 @@ If you want to publish your package to a different repository, you must use a pe
This example stores the `GITHUB_TOKEN` secret in the `NODE_AUTH_TOKEN` environment variable. When the `setup-node` action creates an *.npmrc* file, it references the token from the `NODE_AUTH_TOKEN` environment variable.
{% raw %}
```yaml{:copy}
name: Node.js Package
on:
@@ -128,7 +127,10 @@ on:
types: [created]
jobs:
build:
runs-on: ubuntu-latest
runs-on: ubuntu-latest {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
contents: read
packages: write {% endif %}
steps:
- uses: actions/checkout@v2
# Setup .npmrc file to publish to GitHub Packages
@@ -141,9 +143,8 @@ jobs:
- run: npm install
- run: npm publish
env:
NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
NODE_AUTH_TOKEN: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
```
{% endraw %}
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.
@@ -196,13 +197,13 @@ If you publish a package to both registries, you'll need to ensure that your sco
Ensure your *package.json* file includes the scope of your {% data variables.product.prodname_dotcom %} repository and npm registry. For example, if you plan to publish a package in the `octocat/npm-hello-world-test` repository to {% data variables.product.prodname_dotcom %} and https://www.npmjs.com/package/@octocat/npm-hello-world-test, the name in your *package.json* file would be `"name": "@octocat/npm-hello-world-test"`.
To perform authenticated operations against the {% data variables.product.prodname_registry %} registry in your workflow, you can use the `GITHUB_TOKEN`. The `GITHUB_TOKEN` exists in your repository by default and has read and write permissions for packages in the repository where the workflow runs. For more information, see "[Creating and using encrypted secrets](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
To perform authenticated operations against the {% data variables.product.prodname_registry %} registry in your workflow, you can use the `GITHUB_TOKEN`. {% data reusables.github-actions.github-token-permissions %}
When you use the `scope` input to the `setup-node` action, the action creates an *.npmrc* file that includes the scope prefix. By default, the `setup-node` action sets the scope in the *.npmrc* file to the user or organization that owns the workflow file.
This workflow calls the `setup-node` action two times. Each time the `setup-node` action runs, it overwrites the *.npmrc* file. The *.npmrc* file references the token that allows you to perform authenticated operations against the package registry from the `NODE_AUTH_TOKEN` environment variable. The workflow sets the `NODE_AUTH_TOKEN` environment variable each time the `npm publish` command is run, first with a token to publish to npm (`NPM_TOKEN`) and then with a token to publish to {% data variables.product.prodname_registry %} (`GITHUB_TOKEN`).
{% raw %}
```yaml{:copy}
name: Node.js Package
on:
@@ -210,7 +211,10 @@ on:
types: [created]
jobs:
build:
runs-on: ubuntu-latest
runs-on: ubuntu-latest {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
contents: read
packages: write {% endif %}
steps:
- uses: actions/checkout@v2
# Setup .npmrc file to publish to npm
@@ -221,7 +225,7 @@ jobs:
- run: npm install
# Publish to npm
- run: npm publish --access public
env:
env:{% raw %}
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
# Setup .npmrc file to publish to GitHub Packages
- uses: actions/setup-node@v1
@@ -232,6 +236,5 @@ jobs:
# Publish to GitHub Packages
- run: npm publish
env:
NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}{% endraw %}
```
{% endraw %}

View File

@@ -30,7 +30,6 @@ In the tutorial, you will first make a workflow file that uses the [`andymckay/l
3. {% data reusables.actions.make-workflow-file %}
4. Copy the following YAML contents into your workflow file.
{% raw %}
```yaml{:copy}
name: Remove labels
on:
@@ -40,14 +39,18 @@ In the tutorial, you will first make a workflow file that uses the [`andymckay/l
jobs:
remove_labels:
if: github.event.project_card.column_id == '12345678'
runs-on: ubuntu-latest
runs-on: ubuntu-latest{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
issues: write
pull-requests: write{% endif %}
steps:
- name: remove labels
uses: andymckay/labeler@master
with:
remove-labels: "needs review"
repo-token: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
```
{% endraw %}
5. Customize the parameters in your workflow file:
- In `github.event.project_card.column_id == '12345678'`, replace `12345678` with the ID of the column where you want to un-label issues and pull requests that are moved there.

View File

@@ -29,7 +29,6 @@ In the tutorial, you will first make a workflow file that uses the [`imjohnbo/is
2. {% data reusables.actions.make-workflow-file %}
3. Copy the following YAML contents into your workflow file.
{% raw %}
```yaml{:copy}
name: Weekly Team Sync
on:
@@ -39,7 +38,9 @@ In the tutorial, you will first make a workflow file that uses the [`imjohnbo/is
jobs:
create_issue:
name: Create team sync issue
runs-on: ubuntu-latest
runs-on: ubuntu-latest{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
issues: write{% endif %}
steps:
- name: Create team sync issue
uses: imjohnbo/issue-bot@v3.0
@@ -62,9 +63,9 @@ In the tutorial, you will first make a workflow file that uses the [`imjohnbo/is
pinned: false
close-previous: false
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
GITHUB_TOKEN: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
```
{% endraw %}
4. Customize the parameters in your workflow file:
- Change the value for `on.schedule` to dictate when you want this workflow to run. In the example above, the workflow will run every Monday at 7:20 UTC. For more information about scheduled workflows, see "[Scheduled events](/actions/reference/events-that-trigger-workflows#scheduled-events)."
- Change the value for `assignees` to the list of {% data variables.product.prodname_dotcom %} usernames that you want to assign to the issue.

View File

@@ -53,7 +53,7 @@ When creating a group, you must choose a policy that defines which repositories
**Warning**
{% indented_data_reference site.data.reusables.github-actions.self-hosted-runner-security spaces=3 %}
{% indented_data_reference reusables.github-actions.self-hosted-runner-security spaces=3 %}
For more information, see "[About self-hosted runners](/actions/hosting-your-own-runners/about-self-hosted-runners#self-hosted-runner-security-with-public-repositories)."
@@ -85,7 +85,7 @@ When creating a group, you must choose a policy that defines which organizations
**Warning**
{% indented_data_reference site.data.reusables.github-actions.self-hosted-runner-security spaces=3 %}
{% indented_data_reference reusables.github-actions.self-hosted-runner-security spaces=3 %}
For more information, see "[About self-hosted runners](/actions/hosting-your-own-runners/about-self-hosted-runners#self-hosted-runner-security-with-public-repositories)."

View File

@@ -443,7 +443,9 @@ jobs:
path: vendor/bundle
key: administrate-${{ matrix.image }}-${{ hashFiles('Gemfile.lock') }}
- name: Install postgres headers
run: sudo apt-get install libpq-dev
run: |
sudo apt-get update
sudo apt-get install libpq-dev
- name: Install dependencies
run: bundle install --path vendor/bundle
- name: Setup environment configuration

View File

@@ -39,7 +39,8 @@ To help prevent accidental disclosure, {% data variables.product.product_name %}
- Audit how secrets are used, to help ensure theyre being handled as expected. You can do this by reviewing the source code of the repository executing the workflow, and checking any actions used in the workflow. For example, check that theyre not sent to unintended hosts, or explicitly being printed to log output.
- View the run logs for your workflow after testing valid/invalid inputs, and check that secrets are properly redacted, or not shown. It's not always obvious how a command or tool youre invoking will send errors to `STDOUT` and `STDERR`, and secrets might subsequently end up in error logs. As a result, it is good practice to manually review the workflow logs after testing valid and invalid inputs.
- **Use credentials that are minimally scoped**
- Make sure the credentials being used within workflows have the least privileges required, and be mindful that any user with write access to your repository has read access to all secrets configured in your repository.
- Make sure the credentials being used within workflows have the least privileges required, and be mindful that any user with write access to your repository has read access to all secrets configured in your repository. {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
- Actions can use the `GITHUB_TOKEN` by accessing it from the `github.token` context. For more information, see "[Context and expression syntax for {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions#github-context)." You should therefore make sure that the `GITHUB_TOKEN` is granted the minimum required permissions. It's good security practice to set the default permission for the `GITHUB_TOKEN` to read access only for repository contents. The permissions can then be increased, as required, for individual jobs within the workflow file. For more information, see "[Authentication in a workflow](/actions/reference/authentication-in-a-workflow#permissions-for-the-github_token)." {% endif %}
- **Audit and rotate registered secrets**
- Periodically review the registered secrets to confirm they are still required. Remove those that are no longer needed.
- Rotate secrets periodically to reduce the window of time during which a compromised secret is valid.
@@ -52,7 +53,7 @@ To help prevent accidental disclosure, {% data variables.product.product_name %}
The individual jobs in a workflow can interact with (and compromise) other jobs. For example, a job querying the environment variables used by a later job, writing files to a shared directory that a later job processes, or even more directly by interacting with the Docker socket and inspecting other running containers and executing commands in them.
This means that a compromise of a single action within a workflow can be very significant, as that compromised action would have access to all secrets configured on your repository, and can use the `GITHUB_TOKEN` to write to the repository. Consequently, there is significant risk in sourcing actions from third-party repositories on {% data variables.product.prodname_dotcom %}. You can help mitigate this risk by following these good practices:
This means that a compromise of a single action within a workflow can be very significant, as that compromised action would have access to all secrets configured on your repository, and may be able to use the `GITHUB_TOKEN` to write to the repository. Consequently, there is significant risk in sourcing actions from third-party repositories on {% data variables.product.prodname_dotcom %}. You can help mitigate this risk by following these good practices:
* **Pin actions to a full length commit SHA**
@@ -77,14 +78,14 @@ This means that a compromise of a single action within a workflow can be very si
### Considering cross-repository access
{% data variables.product.prodname_actions %} is intentionally scoped for a single repository at a time. The `GITHUB_TOKEN` grants the same level of access as a write-access user, because any write-access user can access this token by creating or modifying workflow files. Users have specific permissions for each repository, so allowing the `GITHUB_TOKEN` for one repository to grant access to another would impact the {% data variables.product.prodname_dotcom %} permission model if not implemented carefully. Similarly, caution must be taken when adding {% data variables.product.prodname_dotcom %} authentication tokens to a workflow, because this can also affect the {% data variables.product.prodname_dotcom %} permission model by inadvertently granting broad access to collaborators.
{% data variables.product.prodname_actions %} is intentionally scoped for a single repository at a time. The `GITHUB_TOKEN` grants the same level of access as a write-access user, because any write-access user can access this token by creating or modifying a workflow file{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}, elevating the permissions of the `GITHUB_TOKEN` if necessary{% endif %}. Users have specific permissions for each repository, so allowing the `GITHUB_TOKEN` for one repository to grant access to another would impact the {% data variables.product.prodname_dotcom %} permission model if not implemented carefully. Similarly, caution must be taken when adding {% data variables.product.prodname_dotcom %} authentication tokens to a workflow, because this can also affect the {% data variables.product.prodname_dotcom %} permission model by inadvertently granting broad access to collaborators.
We have [a plan on the {% data variables.product.prodname_dotcom %} roadmap](https://github.com/github/roadmap/issues/74) to support a flow that allows cross-repository access within {% data variables.product.product_name %}, but this is not yet a supported feature. Currently, the only way to perform privileged cross-repository interactions is to place a {% data variables.product.prodname_dotcom %} authentication token or SSH key as a secret within the workflow. Because many authentication token types do not allow for granular access to specific resources, there is significant risk in using the wrong token type, as it can grant much broader access than intended.
This list describes the recommended approaches for accessing repository data within a workflow, in descending order of preference:
1. **The `GITHUB_TOKEN`**
- This token is intentionally scoped to the single repository that invoked the workflow, and has the same level of access as a write-access user on the repository. The token is created before each job begins and expires when the job is finished. For more information, see "[Authenticating with the GITHUB_TOKEN](/actions/configuring-and-managing-workflows/authenticating-with-the-github_token)."
- This token is intentionally scoped to the single repository that invoked the workflow, and {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}can have {% else %}has {% endif %}the same level of access as a write-access user on the repository. The token is created before each job begins and expires when the job is finished. For more information, see "[Authenticating with the GITHUB_TOKEN](/actions/configuring-and-managing-workflows/authenticating-with-the-github_token)."
- The `GITHUB_TOKEN` should be used whenever possible.
2. **Repository deploy key**
- Deploy keys are one of the only credential types that grant read or write access to a single repository, and can be used to interact with another repository within a workflow. For more information, see "[Managing deploy keys](/developers/overview/managing-deploy-keys#deploy-keys)."
@@ -103,7 +104,7 @@ This list describes the recommended approaches for accessing repository data wit
**Self-hosted** runners on {% data variables.product.product_name %} do not have guarantees around running in ephemeral clean virtual machines, and can be persistently compromised by untrusted code in a workflow.
As a result, self-hosted runners should almost [never be used for public repositories](/actions/hosting-your-own-runners/about-self-hosted-runners#self-hosted-runner-security-with-public-repositories) on {% data variables.product.product_name %}, because any user can open pull requests against the repository and compromise the environment. Similarly, be cautious when using self-hosted runners on private repositories, as anyone who can fork the repository and open a PR (generally those with read-access to the repository) are able to compromise the self-hosted runner environment, including gaining access to secrets and the more privileged `GITHUB_TOKEN` which grants write-access permissions on the repository.
As a result, self-hosted runners should almost [never be used for public repositories](/actions/hosting-your-own-runners/about-self-hosted-runners#self-hosted-runner-security-with-public-repositories) on {% data variables.product.product_name %}, because any user can open pull requests against the repository and compromise the environment. Similarly, be cautious when using self-hosted runners on private repositories, as anyone who can fork the repository and open a pull request (generally those with read-access to the repository) are able to compromise the self-hosted runner environment, including gaining access to secrets and the `GITHUB_TOKEN` which{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}, depending on its settings, can grant {% else %} grants {% endif %}write-access permissions on the repository.
When a self-hosted runner is defined at the organization or enterprise level, {% data variables.product.product_name %} can schedule workflows from multiple repositories onto the same runner. Consequently, a security compromise of these environments can result in a wide impact. To help reduce the scope of a compromise, you can create boundaries by organizing your self-hosted runners into separate groups. For more information, see "[Managing access to self-hosted runners using groups](/actions/hosting-your-own-runners/managing-access-to-self-hosted-runners-using-groups)."

View File

@@ -0,0 +1,19 @@
---
title: Approving workflow runs from public forks
intro: 'When a first-time contributor submits a pull request to a public repository, a maintainer with write access must approve any workflow runs.'
product: '{% data reusables.gated-features.actions %}'
versions:
free-pro-team: '*'
---
Forks of public repositories can submit pull requests that propose changes to a repository's {% data variables.product.prodname_actions %} workflows. Although workflows from forks do not have access to sensitive data such as secrets, they can be an annoyance for maintainers if they are modified for abusive purposes. To help prevent this, workflows on pull requests are not run automatically if they are received from first-time contributors, and must be approved first.
Maintainers with write access to the repository can use the following procedure to review and run workflows on pull requests from first-time contributors. After a contributor has at least one pull request merged into a project's repository, any future pull requests from that contributor's fork will automatically run workflows.
{% data reusables.repositories.sidebar-pr %}
{% data reusables.repositories.choose-pr-review %}
{% data reusables.repositories.changed-files %}
1. Inspect the proposed changes in the pull request and ensure that you are comfortable running your workflows on the pull request branch. You should be especially alert to any proposed changes in the `.github/workflows/` directory that affect workflow files.
1. If you are comfortable with running workflows on the pull request branch, return to the {% octicon "comment-discussion" aria-label="The discussion icon" %} **Conversation** tab, and under "Workflow(s) awaiting approval", click **Approve and run**.
![Approve and run workflows](/assets/images/help/pull_requests/actions-approve-and-run-workflows-from-fork.png)

View File

@@ -26,6 +26,7 @@ versions:
{% link_in_list /manually-running-a-workflow %}
{% link_in_list /re-running-a-workflow %}
{% link_in_list /canceling-a-workflow %}
{% link_in_list /approving-workflow-runs-from-public-forks %}
{% link_in_list /reviewing-deployments %}
{% link_in_list /disabling-and-enabling-a-workflow %}
{% link_in_list /deleting-a-workflow-run %}

View File

@@ -28,44 +28,60 @@ The token is also available in the `github.token` context. For more information,
### Using the `GITHUB_TOKEN` in a workflow
To use the `GITHUB_TOKEN` secret, you must reference it in your workflow file. Using a token might include passing the token as an input to an action that requires it, or making authenticated {% data variables.product.prodname_dotcom %} API calls.
You can use the `GITHUB_TOKEN` by using the standard syntax for referencing secrets: {%raw%}`${{ secrets.GITHUB_TOKEN }}`{% endraw %}. Examples of using the `GITHUB_TOKEN` include passing the token as an input to an action, or using it to make an authenticated {% data variables.product.prodname_dotcom %} API request.
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
{% note %}
**Important:** An action can access the `GITHUB_TOKEN` through the `github.token` context even if the workflow does not explicitly pass the `GITHUB_TOKEN` to the action. As a good security practice, you should always make sure that actions only have the minimum access they require by limiting the permissions granted to the `GITHUB_TOKEN`. For more information, see "[Permissions for the `GITHUB_TOKEN`](#permissions-for-the-github_token)."
{% endnote %}
{% endif %}
{% data reusables.github-actions.actions-do-not-trigger-workflows %}
#### Example passing `GITHUB_TOKEN` as an input
#### Example 1: passing the `GITHUB_TOKEN` as an input
This example workflow uses the [labeler action](https://github.com/actions/labeler), which requires the `GITHUB_TOKEN` as the value for the `repo-token` input parameter:
{% raw %}
```yaml
name: Pull request labeler
on:
- pull_request_target
jobs:
```yaml
name: Pull request labeler
on: [ pull_request_target ]
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}permissions:
contents: read
pull-requests: write
{% endif %}
jobs:
triage:
runs-on: ubuntu-latest
steps:
- uses: actions/labeler@v2
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
```
{% endraw %}
repo-token: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
```
#### Example calling the REST API
#### Example 2: calling the REST API
You can use the `GITHUB_TOKEN` to make authenticated API calls. This example workflow creates an issue using the {% data variables.product.prodname_dotcom %} REST API:
{% raw %}
```yaml
name: Create issue on commit
on:
- push
jobs:
```yaml
name: Create issue on commit
on: [ push ]
jobs:
create_commit:
runs-on: ubuntu-latest
runs-on: ubuntu-latest {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
issues: write {% endif %}
steps:
- name: Create issue using REST API
run: |
run: {% raw %}|
curl --request POST \
--url https://api.github.com/repos/${{ github.repository }}/issues \
--header 'authorization: Bearer ${{ secrets.GITHUB_TOKEN }}' \
@@ -74,16 +90,32 @@ You can use the `GITHUB_TOKEN` to make authenticated API calls. This example wor
"title": "Automated issue for commit: ${{ github.sha }}",
"body": "This issue was automatically created by the GitHub Action workflow **${{ github.workflow }}**. \n\n The commit hash was: _${{ github.sha }}_."
}' \
--fail
```
{% endraw %}
--fail{% endraw %}
```
### Permissions for the `GITHUB_TOKEN`
For information about the API endpoints {% data variables.product.prodname_github_apps %} can access with each permission, see "[{% data variables.product.prodname_github_app %} Permissions](/rest/reference/permissions-required-for-github-apps)."
| Permission | Access type | Access by forked repos |
|------------|-------------|--------------------------|
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
The following table shows the permissions granted to the `GITHUB_TOKEN` by default. People with admin permissions to an enterprise, organization, or repository can set the default permissions to be either permissive or restricted. For information on how to set the default permissions for the `GITHUB_TOKEN` for your enterprise, organization, or repository, see "[Enforcing {% data variables.product.prodname_actions %} policies in your enterprise account](/github/setting-up-and-managing-your-enterprise/enforcing-github-actions-policies-in-your-enterprise-account#setting-the-permissions-of-the-github_token-for-your-enterprise)," "[Disabling or limiting {% data variables.product.prodname_actions %} for your organization](/github/setting-up-and-managing-organizations-and-teams/disabling-or-limiting-github-actions-for-your-organization#setting-the-permissions-of-the-github_token-for-your-organization)," or "[Disabling or limiting {% data variables.product.prodname_actions %} for a repository](/github/administering-a-repository/disabling-or-limiting-github-actions-for-a-repository#setting-the-permissions-of-the-github_token-for-a-repository)."
| Scope | Default access<br>(permissive) | Default access<br>(restricted) | Maximum access<br>by forked repos |
|---------------|-----------------------------|-----------------------------|--------------------------------|
| actions | read/write | none | read |
| checks | read/write | none | read |
| contents | read/write | read | read |
| deployments | read/write | none | read |
| issues | read/write | none | read |
| metadata | read | read | read |
| packages | read/write | none | read |
| pull requests | read/write | none | read |
| repository projects | read/write | none | read |
| security events | read/write | none | read |
| statuses | read/write | none | read |
{% else %}
| Scope | Access type | Access by forked repos |
|----------|-------------|--------------------------|
| actions | read/write | read |
| checks | read/write | read |
| contents | read/write | read |
@@ -94,9 +126,32 @@ For information about the API endpoints {% data variables.product.prodname_githu
| pull requests | read/write | read |
| repository projects | read/write | read |
| statuses | read/write | read |
{% endif %}
{% data reusables.actions.workflow-runs-dependabot-note %}
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
#### Modifying the permissions for the `GITHUB_TOKEN`
You can modify the permissions for the `GITHUB_TOKEN` in individual workflow files. If the default permissions for the `GITHUB_TOKEN` are restrictive, you may have to elevate the permissions to allow some actions and commands to run successfully. If the default permissions are permissive, you can edit the workflow file to remove some permissions from the `GITHUB_TOKEN`. As a good security practice, you should grant the `GITHUB_TOKEN` the least required access.
You can see the permissions that `GITHUB_TOKEN` had for a specific job in the "Set up job" section of the workflow run log. For more information, see "[Using workflow run logs](/actions/managing-workflow-runs/using-workflow-run-logs)."
You can use the `permissions` key in your workflow file to modify permissions for the `GITHUB_TOKEN` for an entire workflow or for individual jobs. This allows you to configure the minimum required permissions for a workflow or job. When the `permissions` key is used, all unspecified permissions are set to no access, with the exception of the `metadata` scope, which always gets read access.
{% data reusables.github-actions.forked-write-permission %}
The two workflow examples earlier in this article show the `permissions` key being used at the workflow level, and at the job level. In [Example 1](#example-1-passing-the-github_token-as-an-input) the two permissions are specified for the entire workflow. In [Example 2](#example-2-calling-the-rest-api) write access is granted for one scope for a single job.
For full details of the `permissions` key, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#permissions)."
##### How the permissions are calculated for a workflow job
The permissions for the `GITHUB_TOKEN` are initially set to the default setting for the enterprise, organization, or repository. If the default is set to the restricted permissions at any of these levels then this will apply to the relevant repositories. For example, if you choose the restricted default at the organization level then all repositories in that organization will use the restricted permissions as the default. The permissions are then adjusted based on any configuration within the workflow file, first at the workflow level and then at the job level. Finally, if the workflow was triggered by a pull request from a forked repository, and the **Send write tokens to workflows from pull requests** setting is not selected, the permissions are adjusted to change any write permissions to read only.
#### Granting additional permissions
{% endif %}
If you need a token that requires permissions that aren't available in the `GITHUB_TOKEN`, you can create a personal access token and set it as a secret in your repository:
1. Use or create a token with the appropriate permissions for that repository. For more information, see "[Creating a personal access token](/github/authenticating-to-github/creating-a-personal-access-token)."

View File

@@ -187,6 +187,32 @@ For more information, see "[About comparing branches in pull requests](/articles
For more information about cron syntax, see "[Events that trigger workflows](/actions/automating-your-workflow-with-github-actions/events-that-trigger-workflows#scheduled-events)."
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
### `permissions`
You can modify the default permissions granted to the `GITHUB_TOKEN`, adding or removing access as required, so that you only allow the minimum required access. For more information, see "[Authentication in a workflow](/actions/reference/authentication-in-a-workflow#permissions-for-the-github_token)."
You can use `permissions` either as a top-level key, to apply to all jobs in the workflow, or within specific jobs. When you add the `permissions` key within a specific job, all actions and run commands within that job that use the `GITHUB_TOKEN` gain the access rights you specify. For more information, see [`jobs.<job_id>.permissions`](#jobsjob_idpermissions).
{% data reusables.github-actions.github-token-available-permissions %}
{% data reusables.github-actions.forked-write-permission %}
#### Example
This example shows permissions being set for the `GITHUB_TOKEN` that will apply to all jobs in the workflow. All permissions are granted read access.
```yaml
name: "My workflow"
on: [ push ]
permissions: read-all
jobs:
...
```
{% endif %}
### `env`
A `map` of environment variables that are available to the steps of all jobs in the workflow. You can also set environment variables that are only available to the steps of a single job or to a single step. For more information, see [`jobs.<job_id>.env`](#jobsjob_idenv) and [`jobs.<job_id>.steps[*].env`](#jobsjob_idstepsenv).
@@ -351,6 +377,34 @@ runs-on: [self-hosted, linux]
For more information, see "[About self-hosted runners](/github/automating-your-workflow-with-github-actions/about-self-hosted-runners)" and "[Using self-hosted runners in a workflow](/github/automating-your-workflow-with-github-actions/using-self-hosted-runners-in-a-workflow)."
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
### `jobs.<job_id>.permissions`
You can modify the default permissions granted to the `GITHUB_TOKEN`, adding or removing access as required, so that you only allow the minimum required access. For more information, see "[Authentication in a workflow](/actions/reference/authentication-in-a-workflow#permissions-for-the-github_token)."
By specifying the permission within a job definition, you can configure a different set of permissions for the `GITHUB_TOKEN` for each job, if required. Alternatively, you can specify the permissions for all jobs in the workflow. For information on defining permissions at the workflow level, see [`permissions`](#permissions).
{% data reusables.github-actions.github-token-available-permissions %}
{% data reusables.github-actions.forked-write-permission %}
#### Example
This example shows permissions being set for the `GITHUB_TOKEN` that will only apply to the job named `stale`. Write access is granted for the `issues` and `pull-requests` scopes. All other scopes will have no access.
```yaml
jobs:
stale:
runs-on: ubuntu-latest
permissions:
issues: write
pull-requests: write
steps:
- uses: actions/stale@v3
```
{% endif %}
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" or currentVersion == "github-ae@latest" %}
### `jobs.<job_id>.environment`

View File

@@ -93,6 +93,10 @@ We recommend using actions to interact with the software installed on runners. T
If there is a tool that you'd like to request, please open an issue at [actions/virtual-environments](https://github.com/actions/virtual-environments). This repository also contains announcements about all major software updates on runners.
#### Installing additional software
You can install additional software on {% data variables.product.prodname_dotcom %}-hosted runners. For more information, see "[Customizing GitHub-hosted runners](/actions/using-github-hosted-runners/customizing-github-hosted-runners)".
### IP addresses
{% note %}

View File

@@ -0,0 +1,92 @@
---
title: Customizing GitHub-hosted runners
intro: >-
You can install additional software on GitHub-hosted runners as a
part of your workflow.
product: '{% data reusables.gated-features.actions %}'
versions:
free-pro-team: '*'
enterprise-server: '>=2.22'
type: tutorial
topics:
- Workflows
---
{% data reusables.actions.enterprise-github-hosted-runners %}
If you require additional software packages on {% data variables.product.prodname_dotcom %}-hosted runners, you can create a job that installs the packages as part of your workflow.
To see which packages are already installed by default, see "[Preinstalled software](/actions/using-github-hosted-runners/about-github-hosted-runners#preinstalled-software)."
This guide demonstrates how to create a job that installs additional software on a {% data variables.product.prodname_dotcom %}-hosted runner.
### Installing software on Ubuntu runners
The following example demonstrates how to install an `apt` package as part of a job.
{% raw %}
```yaml
name: Build on Ubuntu
on: push
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Check out repository code
uses: actions/checkout@v2
- name: Install jq tool
run: |
sudo apt-get update
sudo apt-get install jq
```
{% endraw %}
{% note %}
**Note:** Always run `sudo apt-get update` before installing a package. In case the `apt` index is stale, this command fetches and re-indexes any available packages, which helps prevent package installation failures.
{% endnote %}
### Installing software on macOS runners
The following example demonstrates how to install Brew packages and casks as part of a job.
{% raw %}
```yaml
name: Build on macOS
on: push
jobs:
build:
runs-on: macos-latest
steps:
- name: Check out repository code
uses: actions/checkout@v2
- name: Install GitHub CLI
run: |
brew update
brew install gh
- name: Install Microsoft Edge
run: |
brew update
brew install --cask microsoft-edge
```
{% endraw %}
### Installing software on Windows runners
The following example demonstrates how to use [Chocolatey](https://community.chocolatey.org/packages) to install the {% data variables.product.prodname_dotcom %} CLI as part of a job.
{% raw %}
```yaml
name: Build on Windows
on: push
jobs:
build:
runs-on: windows-latest
steps:
- run: choco install gh
- run: gh version
```
{% endraw %}

View File

@@ -11,6 +11,7 @@ versions:
{% data reusables.actions.enterprise-github-hosted-runners %}
{% link_in_list /about-github-hosted-runners %}
{% link_in_list /customizing-github-hosted-runners %}
{% link_in_list /about-ae-hosted-runners %}
{% link_in_list /adding-ae-hosted-runners %}
{% link_in_list /using-ae-hosted-runners-in-a-workflow %}

View File

@@ -17,9 +17,7 @@ topics:
{% endif %}
{% if currentVersion == "github-ae@latest" %}
The first time you access your enterprise, you will complete an initial configuration to get {% data variables.product.product_name %} ready to use. The initial configuration includes connecting your enterprise with an idP, authenticating with SAML SSO, and configuring policies for repositories and organizations in your enterprise. For more information, see "[Initializing {% data variables.product.prodname_ghe_managed %}](/admin/configuration/initializing-github-ae)."
For users to receive any emails from {% data variables.product.product_name %} after the initial configuration, you must ask {% data variables.contact.github_support %} to configure outbound email support with your SMTP server. For more information, see "[Configuring email for notifications](/admin/configuration/configuring-email-for-notifications)."
The first time you access your enterprise, you will complete an initial configuration to get {% data variables.product.product_name %} ready to use. The initial configuration includes connecting your enterprise with an identity provider (IdP), authenticating with SAML SSO, configuring policies for repositories and organizations in your enterprise, and configuring SMTP for outbound email. For more information, see "[Initializing {% data variables.product.prodname_ghe_managed %}](/admin/configuration/initializing-github-ae)."
Later, you can use the site admin dashboard and enterprise settings to further configure your enterprise, manage users, organizations and repositories, and set policies that reduce risk and increase quality.

View File

@@ -89,7 +89,12 @@ There are two types of snapshots:
{% note %}
**Note**: Installing a hotpatch using the {% data variables.enterprise.management_console %} is not available in clustered environments. To install a hotpatch in a clustered environment, see "[Upgrading a cluster](/enterprise/{{ currentVersion }}/admin/clustering/upgrading-a-cluster#upgrading-with-a-hotpatch)."
**{% if currentVersion ver_gt "enterprise-server@2.22" %}Notes{% else %}Note{% endif %}**:
{% if currentVersion ver_gt "enterprise-server@2.22" %}
- If {% data variables.product.product_location %} is running a release candidate build, you can't upgrade with a hotpatch.
- {% endif %}Installing a hotpatch using the {% data variables.enterprise.management_console %} is not available in clustered environments. To install a hotpatch in a clustered environment, see "[Upgrading a cluster](/enterprise/{{ currentVersion }}/admin/clustering/upgrading-a-cluster#upgrading-with-a-hotpatch)."
{% endnote %}

View File

@@ -14,7 +14,7 @@ topics:
Before enabling {% data variables.product.prodname_actions %}, make sure you have completed the following steps:
* Create your Amazon S3 bucket for storing artifacts generated by workflow runs. {% indented_data_reference site.data.reusables.actions.enterprise-s3-permission spaces=2 %}
* Create your Amazon S3 bucket for storing artifacts generated by workflow runs. {% indented_data_reference reusables.actions.enterprise-s3-permission spaces=2 %}
{% data reusables.actions.enterprise-common-prereqs %}

View File

@@ -15,7 +15,7 @@ topics:
Before enabling {% data variables.product.prodname_actions %}, make sure you have completed the following steps:
* To avoid resource contention on the appliance, we recommend that MinIO be hosted separately from {% data variables.product.product_location %}.
* Create your bucket for storing workflow artifacts. To set up your bucket and access key, see the [MinIO documentation](https://docs.min.io/docs/minio-gateway-for-nas.html). {% indented_data_reference site.data.reusables.actions.enterprise-s3-permission spaces=2 %}
* Create your bucket for storing workflow artifacts. To set up your bucket and access key, see the [MinIO documentation](https://docs.min.io/docs/minio-gateway-for-nas.html). {% indented_data_reference reusables.actions.enterprise-s3-permission spaces=2 %}
{% data reusables.actions.enterprise-common-prereqs %}

View File

@@ -14,16 +14,31 @@ topics:
Your enterprise instance includes a number of built-in actions that you can use in your workflows. For more information about the bundled actions, see "[Official actions bundled with your enterprise instance](/admin/github-actions/about-using-actions-in-your-enterprise#official-actions-bundled-with-your-enterprise-instance)."
These bundled actions are a point-in-time snapshot of the official actions found at https://github.com/actions; as a result, these actions may be older versions that can be updated. To update these actions, you can use `actions-sync` to retrieve updated versions from {% data variables.product.prodname_dotcom_the_website %}.
These bundled actions are a point-in-time snapshot of the official actions found at https://github.com/actions, so there may be newer versions of these actions available. You can use the `actions-sync` tool to update these actions, or you can configure {% data variables.product.prodname_github_connect %} to allow access to the latest actions on {% data variables.product.prodname_dotcom_the_website %}. These options are described in the following sections.
These options are described in more detail in the following sections.
### Using `actions-sync` to update the bundled actions
### Using actions-sync to update a bundled action
To update the bundled actions, you can use the `actions-sync` tool to update the snapshot. For more information on using `actions-sync`, see "[Manually syncing actions from {% data variables.product.prodname_dotcom_the_website %}](/admin/github-actions/manually-syncing-actions-from-githubcom)."
To update the bundled actions, you can use the `actions-sync` tool to synchronize actions with {% data variables.product.prodname_dotcom_the_website %}. For more information on using `actions-sync`, see "[Manually syncing actions from {% data variables.product.prodname_dotcom_the_website %}](/admin/github-actions/manually-syncing-actions-from-githubcom)."
### Using {% data variables.product.prodname_github_connect %} to access the latest actions
### Using actions from {% data variables.product.prodname_dotcom_the_website %}
You can use {% data variables.product.prodname_github_connect %} to allow {% data variables.product.product_name %} to use actions from {% data variables.product.prodname_dotcom_the_website %}. For more information, see "[Enabling automatic access to {% data variables.product.prodname_dotcom_the_website %} actions using {% data variables.product.prodname_github_connect %}](/admin/github-actions/enabling-automatic-access-to-githubcom-actions-using-github-connect)."
To allow {% data variables.product.product_name %} to use actions directly from {% data variables.product.prodname_dotcom_the_website %}, you can use {% data variables.product.prodname_github_connect %}. For more information, see "[Enabling automatic access to {% data variables.product.prodname_dotcom_the_website %} actions using {% data variables.product.prodname_github_connect %}](/admin/github-actions/enabling-automatic-access-to-githubcom-actions-using-github-connect)."
Once {% data variables.product.prodname_github_connect %} is configured, you can use the latest version of an action by deleting its local repository in the `actions` organization on your instance. For example, if your enterprise instance is using the `actions/checkout@v1` action, and you need to use `actions/checkout@v2` which isn't available on your enterprise instance, perform the following steps to be able to use the latest `checkout` action from {% data variables.product.prodname_dotcom_the_website %}:
Once configured, you can use a new version of an action from {% data variables.product.prodname_dotcom_the_website %} by manually specifying the required version in the workflow file. For example, to use version `v2.2.1` of `actions/setup-python` from {% data variables.product.prodname_dotcom_the_website %}, you can specify the tag `actions/setup-python@v2.2.1` in your workflow file.
1. By default, site administrators are not owners of the bundled actions organization. To get the required access to delete the `checkout` repository, use the `ghe-org-admin-promote` command to promote a user to be an owner of the bundled `actions` organization. For more information, see "[Accessing the administrative shell (SSH)](/admin/configuration/accessing-the-administrative-shell-ssh)" and "[`ghe-org-admin-promote`](/admin/configuration/command-line-utilities#ghe-org-admin-promote)." For example:
```shell
$ ghe-org-admin-promote -u octocat -o actions
Do you want to give organization admin privileges for actions to octocat? (y/N) y
Making octocat an admin of actions
--> Adding octocat as an admin of actions
--> octocat is now an admin of the actions organization
--> Done.
```
1. On your {% data variables.product.product_name %} instance, delete the `checkout` repository within the `actions` organization. For information on how to delete a repository, see "[Deleting a repository
](/github/administering-a-repository/deleting-a-repository)."
1. It is recommended that you leave the `actions` organization once you no longer require administrative access. For more information, see "[Removing yourself from an organization
](/github/setting-up-and-managing-your-github-user-account/removing-yourself-from-an-organization)."
1. Configure your workflow's YAML to use `actions/checkout@v2`.
1. Each time your workflow runs, the runner will use the `v2` version of `actions/checkout` from {% data variables.product.prodname_dotcom_the_website %}.

View File

@@ -34,6 +34,12 @@ If you don't have private mode enabled, the migration script will have no effect
### Running the migration
1. Connect to the administrative shell. For more information, see "[Accessing the administrative shell (SSH)](/enterprise/admin/installation/accessing-the-administrative-shell-ssh)."
{% if currentVersion ver_gt "enterprise-server@2.22" or currentVersion == "github-ae@latest" %}
2. Run the migration command.
```shell
github-env 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
```
{% else %}
2. Navigate to the `/data/github/current` directory.
```shell
cd /data/github/current
@@ -42,6 +48,7 @@ If you don't have private mode enabled, the migration script will have no effect
```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
```
{% endif %}
Log output will appear in the terminal and `/tmp/convert_public_ghes_repos_to_internal.log`.

View File

@@ -187,7 +187,10 @@ Alternatively, you can install Python dependencies manually on any operating sys
jobs:
CodeQL-Build:
runs-on: ubuntu-latest
runs-on: ubuntu-latest{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
security-events: write
actions: read{% endif %}
steps:
- name: Checkout repository

View File

@@ -48,7 +48,10 @@ on:
jobs:
analyze:
name: Analyze
runs-on: ubuntu-latest
runs-on: ubuntu-latest{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
security-events: write
actions: read{% endif %}
strategy:
fail-fast: false

View File

@@ -34,7 +34,10 @@ If an automatic build of code for a compiled language within your project fails,
```yaml
jobs:
analyze:
analyze:{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
security-events: write
actions: read{% endif %}
...
strategy:
fail-fast: false

View File

@@ -68,7 +68,9 @@ on:
jobs:
build:
runs-on: ubuntu-latest
runs-on: ubuntu-latest{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
security-events: write{% endif %}
steps:
# This step checks out a copy of your repository.
- name: Checkout repository
@@ -100,6 +102,9 @@ on:
jobs:
build:
runs-on: ubuntu-latest{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
security-events: write{% endif %}
steps:
- uses: actions/checkout@v2
- name: Run npm install

View File

@@ -446,12 +446,12 @@ updates:
#### `rebase-strategy`
By default, {% data variables.product.prodname_dependabot %} automatically rebases open pull requests when it detects conflicts. Use `rebase-strategy` to disable this behavior.
By default, {% data variables.product.prodname_dependabot %} automatically rebases open pull requests when it detects any changes to the pull request. Use `rebase-strategy` to disable this behavior.
Available rebase strategies
- `disabled` to disable automatic rebasing.
- `auto` to use the default behavior and rebase open pull requests when conflicts are detected.
- `auto` to use the default behavior and rebase open pull requests when changes are detected.
{% data reusables.dependabot.option-affects-security-updates %}

View File

@@ -20,6 +20,7 @@ topics:
{% link_in_list /exploring-the-dependencies-of-a-repository %}
{% topic_link_in_list /keeping-your-dependencies-updated-automatically %}
{% link_in_list /about-dependabot-version-updates %}
{% link_in_list /upgrading-from-dependabotcom-to-github-native-dependabot %}
{% link_in_list /enabling-and-disabling-version-updates %}
{% link_in_list /listing-dependencies-configured-for-version-updates %}
{% link_in_list /managing-pull-requests-for-dependency-updates %}

View File

@@ -0,0 +1,36 @@
---
title: Upgrading from Dependabot.com to GitHub-native Dependabot
intro: 'You can upgrade to GitHub-native Dependabot by merging a pull request that will allow your dependencies to continue being updated.'
versions:
free-pro-team: '*'
topics:
- repositories
---
### About upgrading from Dependabot Preview to {% data variables.product.prodname_dotcom %}-native {% data variables.product.prodname_dependabot %}
Dependabot Preview has been built directly into {% data variables.product.prodname_dotcom %}, so you can use {% data variables.product.prodname_dependabot %} alongside all the other functionality in {% data variables.product.prodname_dotcom %} without having to install and use a separate application. By migrating to {% data variables.product.prodname_dotcom %}-native {% data variables.product.prodname_dependabot %}, we can also focus on bringing lots of exciting new features to {% data variables.product.prodname_dependabot %}, including more [ecosystem updates](https://github.com/github/roadmap/issues/150), [improved notifications](https://github.com/github/roadmap/issues/133), and {% data variables.product.prodname_dependabot %} support for [{% data variables.product.prodname_ghe_server %}](https://github.com/github/roadmap/issues/86) and [{% data variables.product.prodname_ghe_managed %}](https://github.com/github/roadmap/issues/135).
### Differences between Dependabot Preview and {% data variables.product.prodname_dotcom %}-native {% data variables.product.prodname_dependabot %}
While most of the Dependabot Preview features exist in {% data variables.product.prodname_dotcom %}-native {% data variables.product.prodname_dependabot %}, a few remain unavailable:
- **Live updates:** We hope to bring these back in the future. For now, you can run {% data variables.product.prodname_dotcom %} {% data variables.product.prodname_dependabot %} daily to catch new packages within one day of release.
- **PHP environment variable registries:** For now, you can use {% data variables.product.prodname_actions %} to fetch dependencies from these registries.
- **Auto-merge:** We always recommend verifying your dependencies before merging them; therefore, auto-merge will not be supported for the foreseeable future. For those of you who have vetted your dependencies, or are only using internal dependencies, we recommend adding third-party auto-merge apps, or setting up GitHub Actions to merge.
In {% data variables.product.prodname_dotcom %}-native {% data variables.product.prodname_dependabot %}, you can configure all version updates using the configuration file. This file is similar to the Dependabot Preview configuration file with a few changes and improvements that will be automatically included in your upgrade pull request. For more information about the upgrade pull request, see "[Upgrading to GitHub-native Dependabot](/code-security/supply-chain-security/upgrading-from-dependabotcom-to-github-native-dependabot#upgrading-to-github-native-dependabot)".
To see update logs for {% data variables.product.prodname_dotcom %}-native {% data variables.product.prodname_dependabot %} that were previously on the Dependabot.com dashboard:
1. Navigate to your repositorys **Insights** page.
2. Click **Dependency graph** to the left.
3. Click **{% data variables.product.prodname_dependabot %}**.
For more information about version updates with {% data variables.product.prodname_dotcom %}-native {% data variables.product.prodname_dependabot %}, see "[About Dependabot version updates](/code-security/supply-chain-security/about-dependabot-version-updates)."
### Upgrading to {% data variables.product.prodname_dotcom %}-native {% data variables.product.prodname_dependabot %}
Upgrading from Dependabot Preview to {% data variables.product.prodname_dotcom %}-native {% data variables.product.prodname_dependabot %} requires only one step: merge the *Upgrade to GitHub-native Dependabot* pull request in your repository. This pull request includes the updated configuration file needed for {% data variables.product.prodname_dotcom %}-native {% data variables.product.prodname_dependabot %}.
If you have any questions or need help migrating, you can view or open issues in the [dependabot/dependabot-core](https://github.com/dependabot/dependabot-core/issues) repository.

View File

@@ -22,6 +22,12 @@ With wikis, you can write content just like everywhere else on {% data variables
You can edit wikis directly on {% data variables.product.product_name %}, or you can edit wiki files locally. By default, only people with write access to your repository can make changes to wikis, although you can allow everyone on {% data variables.product.product_location %} to contribute to a wiki in {% if currentVersion == "github-ae@latest" %}an internal{% else %}a public{% endif %} repository. For more information, see "[Changing access permissions for wikis](/communities/documenting-your-project-with-wikis/changing-access-permissions-for-wikis)".
{% note %}
**Note:** Search engines will not index the contents of wikis. To have your content indexed by search engines, you can use [{% data variables.product.prodname_pages %}](/pages) in a public repository.
{% endnote %}
### Further reading
- "[Adding or editing wiki pages](/communities/documenting-your-project-with-wikis/adding-or-editing-wiki-pages)"

View File

@@ -140,18 +140,16 @@ You'll add this new method as a [Sinatra helper](https://github.com/sinatra/sina
``` ruby
# Create a new check run with the status queued
def create_check_run
# # At the time of writing, Octokit does not support the Checks API yet, but
# it does provide generic HTTP methods you can use:
# /rest/reference/checks#create-a-check-run
check_run = @installation_client.post(
"repos/#{@payload['repository']['full_name']}/check-runs",
{
accept: 'application/vnd.github.v3+json',
# The name of your check run.
name: 'Octo RuboCop',
@installation_client.create_check_run(
# [String, Integer, Hash, Octokit Repository object] A GitHub repository.
@payload['repository']['full_name'],
# [String] The name of your check run.
'Octo RuboCop',
# [String] The SHA of the commit to check
# The payload structure differs depending on whether a check run or a check suite event occurred.
head_sha: @payload['check_run'].nil? ? @payload['check_suite']['head_sha'] : @payload['check_run']['head_sha']
}
@payload['check_run'].nil? ? @payload['check_suite']['head_sha'] : @payload['check_run']['head_sha'],
# [Hash] 'Accept' header option, to avoid a warning about the API not being ready for production use.
accept: 'application/vnd.github.v3+json'
)
end
```
@@ -159,25 +157,22 @@ end
``` ruby
# Create a new check run with the status queued
def create_check_run
# # At the time of writing, Octokit does not support the Checks API yet, but
# it does provide generic HTTP methods you can use:
# /rest/reference/checks#create-a-check-run
check_run = @installation_client.post(
"repos/#{@payload['repository']['full_name']}/check-runs",
{
# This header allows for beta access to Checks API
accept: 'application/vnd.github.antiope-preview+json',
# The name of your check run.
name: 'Octo RuboCop',
@installation_client.create_check_run(
# [String, Integer, Hash, Octokit Repository object] A GitHub repository.
@payload['repository']['full_name'],
# [String] The name of your check run.
'Octo RuboCop',
# [String] The SHA of the commit to check
# The payload structure differs depending on whether a check run or a check suite event occurred.
head_sha: @payload['check_run'].nil? ? @payload['check_suite']['head_sha'] : @payload['check_run']['head_sha']
}
@payload['check_run'].nil? ? @payload['check_suite']['head_sha'] : @payload['check_run']['head_sha'],
# [Hash] 'Accept' header option, to avoid a warning about the API not being ready for production use.
accept: 'application/vnd.github.antiope-preview+json'
)
end
```
{% endif %}
This code calls the "[Create a check run](/rest/reference/checks#create-a-check-run)" endpoint using the generic [HTTP `POST` method](http://octokit.github.io/octokit.rb/Octokit/Connection.html#post-instance_method). This method takes two parameters: the URL of the endpoint and the input parameters to the method.
This code calls the "[Create a check run](/rest/reference/checks#create-a-check-run)" endpoint using the [create_check_run method](https://rdoc.info/gems/octokit/Octokit%2FClient%2FChecks:create_check_run).
To create a check run, only two input parameters are required: `name` and `head_sha`. We will use [Rubocop](https://rubocop.readthedocs.io/en/latest/) to implement the CI test later in this quickstart, which is why the name "Octo Rubocop" is used here, but you can choose any name you'd like for the check run.
@@ -240,31 +235,22 @@ def initiate_check_run
# to 'in_progress' and run the CI process. When the CI finishes, you'll
# update the check run status to 'completed' and add the CI results.
# Octokit doesn't yet support the Checks API, but it does provide generic
# HTTP methods you can use:
# /rest/reference/checks#update-a-check-run
updated_check_run = @installation_client.patch(
"repos/#{@payload['repository']['full_name']}/check-runs/#{@payload['check_run']['id']}",
{
accept: 'application/vnd.github.v3+json',
name: 'Octo RuboCop',
@installation_client.update_check_run(
@payload['repository']['full_name'],
@payload['check_run']['id'],
status: 'in_progress',
started_at: Time.now.utc.iso8601
}
accept: 'application/vnd.github.v3+json'
)
# ***** RUN A CI TEST *****
# Mark the check run as complete!
updated_check_run = @installation_client.patch(
"repos/#{@payload['repository']['full_name']}/check-runs/#{@payload['check_run']['id']}",
{
accept: 'application/vnd.github.v3+json',
name: 'Octo RuboCop',
@installation_client.update_check_run(
@payload['repository']['full_name'],
@payload['check_run']['id'],
status: 'completed',
conclusion: 'success',
completed_at: Time.now.utc.iso8601
}
accept: 'application/vnd.github.v3+json'
)
end
```
@@ -276,40 +262,30 @@ def initiate_check_run
# to 'in_progress' and run the CI process. When the CI finishes, you'll
# update the check run status to 'completed' and add the CI results.
# Octokit doesn't yet support the Checks API, but it does provide generic
# HTTP methods you can use:
# /rest/reference/checks#update-a-check-run
updated_check_run = @installation_client.patch(
"repos/#{@payload['repository']['full_name']}/check-runs/#{@payload['check_run']['id']}",
{
accept: 'application/vnd.github.antiope-preview+json', # This header is necessary for beta access to Checks API
name: 'Octo RuboCop',
@installation_client.update_check_run(
@payload['repository']['full_name'],
@payload['check_run']['id'],
status: 'in_progress',
started_at: Time.now.utc.iso8601
}
accept: 'application/vnd.github.antiope-preview+json'
)
# ***** RUN A CI TEST *****
# Mark the check run as complete!
updated_check_run = @installation_client.patch(
"repos/#{@payload['repository']['full_name']}/check-runs/#{@payload['check_run']['id']}",
{
# This header is necessary for beta access to Checks API
accept: 'application/vnd.github.antiope-preview+json',
name: 'Octo RuboCop',
@installation_client.update_check_run(
@payload['repository']['full_name'],
@payload['check_run']['id'],
status: 'completed',
conclusion: 'success',
completed_at: Time.now.utc.iso8601
}
accept: 'application/vnd.github.antiope-preview+json'
)
end
```
{% endif %}
The code above calls the "[Update a check run](/rest/reference/checks#update-a-check-run)" API endpoint using the generic [`patch` HTTP method](http://octokit.github.io/octokit.rb/Octokit/Connection.html#patch-instance_method) to update the check run that you already created.
The code above calls the "[Update a check run](/rest/reference/checks#update-a-check-run)" API endpoint using the [`update_check_run` Octokit method](https://rdoc.info/gems/octokit/Octokit%2FClient%2FChecks:update_check_run) to update the check run that you already created.
Here's what this code is doing. First, it updates the check run's status to `in_progress` and sets the `started_at` time to the current time. In [Part 2](#part-2-creating-the-octo-rubocop-ci-test) of this quickstart, you'll add code that kicks off a real CI test under `***** RUN A CI TEST *****`. For now, you'll leave that section as a placeholder, so the code that follows it will just simulate that the CI process succeeds and all tests pass. Finally, the code updates the status of the check run again to `completed`.
Here's what this code is doing. First, it updates the check run's status to `in_progress` and implicitly sets the `started_at` time to the current time. In [Part 2](#part-2-creating-the-octo-rubocop-ci-test) of this quickstart, you'll add code that kicks off a real CI test under `***** RUN A CI TEST *****`. For now, you'll leave that section as a placeholder, so the code that follows it will just simulate that the CI process succeeds and all tests pass. Finally, the code updates the status of the check run again to `completed`.
You'll notice in the "[Update a check run](/rest/reference/checks#update-a-check-run)" docs that when you provide a status of `completed`, the `conclusion` and `completed_at` parameters are required. The `conclusion` summarizes the outcome of a check run and can be `success`, `failure`, `neutral`, `cancelled`, `timed_out`, or `action_required`. You'll set the conclusion to `success`, the `completed_at` time to the current time, and the status to `completed`.
@@ -613,29 +589,23 @@ Now you've got all the information you need to update your check run. In the [fi
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" or currentVersion == "github-ae@latest" %}
``` ruby
# Mark the check run as complete!
updated_check_run = @installation_client.patch(
"repos/#{@payload['repository']['full_name']}/check-runs/#{@payload['check_run']['id']}",
{
accept: 'application/vnd.github.v3+json',
name: 'Octo RuboCop',
@installation_client.update_check_run(
@payload['repository']['full_name'],
@payload['check_run']['id'],
status: 'completed',
conclusion: 'success',
completed_at: Time.now.utc.iso8601
}
accept: 'application/vnd.github.v3+json'
)
```
{% else %}
``` ruby
# Mark the check run as complete!
updated_check_run = @installation_client.patch(
"repos/#{@payload['repository']['full_name']}/check-runs/#{@payload['check_run']['id']}",
{
accept: 'application/vnd.github.antiope-preview+json', # This header is necessary for beta access to Checks API
name: 'Octo RuboCop',
@installation_client.update_check_run(
@payload['repository']['full_name'],
@payload['check_run']['id'],
status: 'completed',
conclusion: 'success',
completed_at: Time.now.utc.iso8601
}
accept: 'application/vnd.github.antiope-preview+json' # This header is necessary for beta access to Checks API
)
```
{% endif %}
@@ -645,14 +615,11 @@ You'll need to update that code to use the `conclusion` variable you set based o
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" or currentVersion == "github-ae@latest" %}
``` ruby
# Mark the check run as complete! And if there are warnings, share them.
updated_check_run = @installation_client.patch(
"repos/#{@payload['repository']['full_name']}/check-runs/#{@payload['check_run']['id']}",
{
accept: 'application/vnd.github.v3+json',
name: 'Octo RuboCop',
@installation_client.update_check_run(
@payload['repository']['full_name'],
@payload['check_run']['id'],
status: 'completed',
conclusion: conclusion,
completed_at: Time.now.utc.iso8601,
output: {
title: 'Octo RuboCop',
summary: summary,
@@ -663,21 +630,18 @@ updated_check_run = @installation_client.patch(
label: 'Fix this',
description: 'Automatically fix all linter notices.',
identifier: 'fix_rubocop_notices'
}]
}
}],
accept: 'application/vnd.github.v3+json'
)
```
{% else %}
``` ruby
# Mark the check run as complete! And if there are warnings, share them.
updated_check_run = @installation_client.patch(
"repos/#{@payload['repository']['full_name']}/check-runs/#{@payload['check_run']['id']}",
{
accept: 'application/vnd.github.antiope-preview+json',
name: 'Octo RuboCop',
@installation_client.update_check_run(
@payload['repository']['full_name'],
@payload['check_run']['id'],
status: 'completed',
conclusion: conclusion,
completed_at: Time.now.utc.iso8601,
output: {
title: 'Octo RuboCop',
summary: summary,
@@ -688,8 +652,8 @@ updated_check_run = @installation_client.patch(
label: 'Fix this',
description: 'Automatically fix all linter notices.',
identifier: 'fix_rubocop_notices'
}]
}
}],
accept: 'application/vnd.github.antiope-preview+json'
)
```
{% endif %}

View File

@@ -88,6 +88,12 @@ We strongly recommend you implement signature validation in your secret alert se
{% endnote %}
Assuming you receive the following message, the code snippets below demonstrate how you could perform signature validation.
The code also assumes you've set an environment variable called `GITHUB_PRODUCTION_TOKEN` with a generated PAT (https://github.com/settings/tokens). The token does not need any permissions set.
**Sample message sent to verify endpoint**
```http
POST / HTTP/1.1
Host: HOST
Accept: */*
content-type: application/json
GITHUB-PUBLIC-KEY-IDENTIFIER: 90a421169f0a406205f1563a953312f0be898d3c7b6c06b681aa86a874555f4a
@@ -358,4 +364,3 @@ A few important points:
**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 %}

View File

@@ -199,7 +199,9 @@ Also, the `User-Agent` for the requests will have the prefix `GitHub-Hookshot/`.
Webhook events are triggered based on the specificity of the domain you register. For example, if you register a subdomain (`https://subdomain.example.com`) then only URLs for the subdomain trigger this event. If you register a domain (`https://example.com`) then URLs for domain and all subdomains trigger this event. See "[Create a content attachment](/rest/reference/apps#create-a-content-attachment)" to create a new content attachment.
Only {% data variables.product.prodname_github_app %}s can receive this event. {% data variables.product.prodname_github_app %}s must have the `content_references` `write` permission to subscribe to this event.
#### Availability
- {% data variables.product.prodname_github_app %}s with the `content_references:write` permission
#### Webhook payload example
@@ -1008,12 +1010,6 @@ Deliveries for `review_requested` and `review_request_removed` events will have
{% endnote %}
{% tip %}
**Note**: The webhook payload example following the table differs significantly from the Events API payload described in the table. Among other differences, the webhook payload includes both `sender` and `pusher` objects. Sender and pusher are the same user who initiated the `push` event, but the `sender` object contains more detail.
{% endtip %}
#### Availability
- Repository webhooks
@@ -1204,7 +1200,7 @@ Key | Type | Description
{% data reusables.webhooks.sponsorship_short_desc %}
You can only create a sponsorship webhook on {% data variables.product.prodname_dotcom %}. For more information, see "[Configuring webhooks for events in your sponsored account](/github/supporting-the-open-source-community-with-github-sponsors/configuring-webhooks-for-events-in-your-sponsored-account)".
You can only create a sponsorship webhook on {% data variables.product.prodname_dotcom %}. For more information, see "[Configuring webhooks for events in your sponsored account](/sponsors/integrating-with-github-sponsors/configuring-webhooks-for-events-in-your-sponsored-account)".
#### Availability

View File

@@ -85,3 +85,22 @@ You can disable all workflows for a repository or set a policy that configures w
{% data reusables.repositories.settings-sidebar-actions %}
{% data reusables.github-actions.private-repository-forks-configure %}
{% endif %}
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
### Setting the permissions of the `GITHUB_TOKEN` for your repository
{% data reusables.github-actions.workflow-permissions-intro %}
The default permissions can also be configured in the organization settings. If the more restricted default has been selected in the organization settings, the same option is auto-selected in your repository settings and the permissive option is disabled.
{% data reusables.github-actions.workflow-permissions-modifying %}
#### Configuring the default `GITHUB_TOKEN` permissions
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-settings %}
{% data reusables.repositories.settings-sidebar-actions %}
1. Under **Workflow permissions**, choose whether you want the `GITHUB_TOKEN` to have read and write access for all scopes, or just read access for the `contents` scope.
![Set GITHUB_TOKEN permissions for this repository](/assets/images/help/settings/actions-workflow-permissions-repository.png)
1. Click **Save** to apply the settings.
{% endif %}

View File

@@ -12,7 +12,7 @@ topics:
### About FUNDING files
You can configure your sponsor button by editing a _FUNDING.yml_ file in your repository's `.github` folder, on the default branch. You can configure the button to include sponsored developers in {% data variables.product.prodname_sponsors %}, external funding platforms, or a custom funding URL. For more information about {% data variables.product.prodname_sponsors %}, see "[About GitHub Sponsors](/articles/about-github-sponsors)."
You can configure your sponsor button by editing a _FUNDING.yml_ file in your repository's `.github` folder, on the default branch. You can configure the button to include sponsored developers in {% data variables.product.prodname_sponsors %}, external funding platforms, or a custom funding URL. For more information about {% data variables.product.prodname_sponsors %}, see "[About GitHub Sponsors](/sponsors/getting-started-with-github-sponsors/about-github-sponsors)."
You can add one username, package name, or project name per external funding platform and up to four custom URLs. You can add up to four sponsored developers or organizations in {% data variables.product.prodname_sponsors %}. Add each platform on a new line, using the following syntax:
@@ -79,5 +79,5 @@ Anyone with admin permissions can enable a sponsor button in a repository.
{% data reusables.files.propose_new_file %}
### Further reading
- "[About {% data variables.product.prodname_sponsors %} for open source contributors](/github/supporting-the-open-source-community-with-github-sponsors/about-github-sponsors-for-open-source-contributors)"
- "[About {% data variables.product.prodname_sponsors %} for open source contributors](/sponsors/receiving-sponsorships-through-github-sponsors/about-github-sponsors-for-open-source-contributors)"
- "[FAQ with the {% data variables.product.prodname_sponsors %} team](https://github.blog/2019-06-12-faq-with-the-github-sponsors-team/)" on {% data variables.product.prodname_blog %}

View File

@@ -87,6 +87,7 @@ After adding a new SSH key to your {% data variables.product.product_name %} acc
If your SSH public key file has a different name than the example code, modify the filename to match your current setup. When copying your key, don't add any newlines or whitespace.
```shell
$ sudo apt-get update
$ sudo apt-get install xclip
# Downloads and installs xclip. If you don't have `apt-get`, you might need to use another installer (like `yum`)

View File

@@ -91,7 +91,7 @@ Before adding a new SSH key to the ssh-agent to manage your keys, you should hav
$ touch ~/.ssh/config
```
* Open your `~/.ssh/config` file, then modify the file, replacing ` ~/.ssh/id_ed25519` if you are not using the default location and name for your `id_ed25519` key.
* Open your `~/.ssh/config` file, then modify the file to contain the following lines. If your SSH key file has a different name or path than the example code, modify the filename or path to match your current setup.
```
Host *

View File

@@ -54,7 +54,7 @@ The events listed in your security log are triggered by your actions. Actions ar
| [`project`](#project-category-actions) | Contains all activities related to project boards.
| [`public_key`](#public_key-category-actions) | Contains all activities related to [your public SSH keys](/articles/adding-a-new-ssh-key-to-your-github-account).
| [`repo`](#repo-category-actions) | Contains all activities related to the repositories you own.{% if currentVersion == "free-pro-team@latest" %}
| [`sponsors`](#sponsors-category-actions) | Contains all events related to {% data variables.product.prodname_sponsors %} and sponsor buttons (see "[About {% data variables.product.prodname_sponsors %}](/articles/about-github-sponsors)" and "[Displaying a sponsor button in your repository](/articles/displaying-a-sponsor-button-in-your-repository)"){% endif %}{% if enterpriseServerVersions contains currentVersion or currentVersion == "github-ae@latest" %}
| [`sponsors`](#sponsors-category-actions) | Contains all events related to {% data variables.product.prodname_sponsors %} and sponsor buttons (see "[About {% data variables.product.prodname_sponsors %}](/sponsors/getting-started-with-github-sponsors/about-github-sponsors)" and "[Displaying a sponsor button in your repository](/articles/displaying-a-sponsor-button-in-your-repository)"){% endif %}{% if enterpriseServerVersions contains currentVersion or currentVersion == "github-ae@latest" %}
| [`team`](#team-category-actions) | Contains all activities related to teams you are a part of.{% endif %}{% if currentVersion != "github-ae@latest" %}
| [`two_factor_authentication`](#two_factor_authentication-category-actions) | Contains all activities related to [two-factor authentication](/articles/securing-your-account-with-two-factor-authentication-2fa).{% endif %}
| [`user`](#user-category-actions) | Contains all activities related to your account.
@@ -93,6 +93,10 @@ An overview of some of the most common actions that are recorded as events in th
| Action | Description
|------------------|-------------------
| `create` | Triggered when you [create a codespace](/github/developing-online-with-codespaces/creating-a-codespace).
| `resume` | Triggered when you resume a suspended codespace.
| `delete` | Triggered when you [delete a codespace](/github/developing-online-with-codespaces/deleting-a-codespace).
| `manage_access_and_security` | Triggered when you update [the repositories a codespace has access to](/github/developing-online-with-codespaces/managing-access-and-security-for-codespaces).
| `trusted_repositories_access_update` | Triggered when you change your user account's [access and security setting for {% data variables.product.prodname_codespaces %}](/github/developing-online-with-codespaces/managing-access-and-security-for-codespaces).
#### `marketplace_agreement_signature` category actions
@@ -189,19 +193,19 @@ An overview of some of the most common actions that are recorded as events in th
| `custom_amount_settings_change` | Triggered when you enable or disable custom amounts, or when you change the suggested custom amount (see "[Managing your sponsorship tiers](/github/supporting-the-open-source-community-with-github-sponsors/managing-your-sponsorship-tiers)")
| `repo_funding_links_file_action` | Triggered when you change the FUNDING file in your repository (see "[Displaying a sponsor button in your repository](/articles/displaying-a-sponsor-button-in-your-repository)")
| `sponsor_sponsorship_cancel` | Triggered when you cancel a sponsorship (see "[Downgrading a sponsorship](/articles/downgrading-a-sponsorship)")
| `sponsor_sponsorship_create` | Triggered when you sponsor an account (see "[Sponsoring an open source contributor](/github/supporting-the-open-source-community-with-github-sponsors/sponsoring-an-open-source-contributor)")
| `sponsor_sponsorship_preference_change` | Triggered when you change whether you receive email updates from a sponsored developer (see "[Managing your sponsorship](/articles/managing-your-sponsorship)")
| `sponsor_sponsorship_create` | Triggered when you sponsor an account (see "[Sponsoring an open source contributor](/sponsors/sponsoring-open-source-contributors/sponsoring-an-open-source-contributor)")
| `sponsor_sponsorship_preference_change` | Triggered when you change whether you receive email updates from a sponsored developer (see "[Managing your sponsorship](/sponsors/sponsoring-open-source-contributors/managing-your-sponsorship)")
| `sponsor_sponsorship_tier_change` | Triggered when you upgrade or downgrade your sponsorship (see "[Upgrading a sponsorship](/articles/upgrading-a-sponsorship)" and "[Downgrading a sponsorship](/articles/downgrading-a-sponsorship)")
| `sponsored_developer_approve` | Triggered when your {% data variables.product.prodname_sponsors %} account is approved (see "[Setting up {% data variables.product.prodname_sponsors %} for your user account](/github/supporting-the-open-source-community-with-github-sponsors/setting-up-github-sponsors-for-your-user-account)")
| `sponsored_developer_create` | Triggered when your {% data variables.product.prodname_sponsors %} account is created (see "[Setting up {% data variables.product.prodname_sponsors %} for your user account](/github/supporting-the-open-source-community-with-github-sponsors/setting-up-github-sponsors-for-your-user-account)")
| `sponsored_developer_approve` | Triggered when your {% data variables.product.prodname_sponsors %} account is approved (see "[Setting up {% data variables.product.prodname_sponsors %} for your user account](/sponsors/receiving-sponsorships-through-github-sponsors/setting-up-github-sponsors-for-your-user-account)")
| `sponsored_developer_create` | Triggered when your {% data variables.product.prodname_sponsors %} account is created (see "[Setting up {% data variables.product.prodname_sponsors %} for your user account](/sponsors/receiving-sponsorships-through-github-sponsors/setting-up-github-sponsors-for-your-user-account)")
| `sponsored_developer_disable` | Triggered when your {% data variables.product.prodname_sponsors %} account is disabled
| `sponsored_developer_redraft` | Triggered when your {% data variables.product.prodname_sponsors %} account is returned to draft state from approved state
| `sponsored_developer_profile_update` | Triggered when you edit your sponsored developer profile (see "[Editing your profile details for {% data variables.product.prodname_sponsors %}](/github/supporting-the-open-source-community-with-github-sponsors/editing-your-profile-details-for-github-sponsors)")
| `sponsored_developer_request_approval` | Triggered when you submit your application for {% data variables.product.prodname_sponsors %} for approval (see "[Setting up {% data variables.product.prodname_sponsors %} for your user account](/github/supporting-the-open-source-community-with-github-sponsors/setting-up-github-sponsors-for-your-user-account)")
| `sponsored_developer_tier_description_update` | Triggered when you change the description for a sponsorship tier (see "[Managing your sponsorship tiers](/github/supporting-the-open-source-community-with-github-sponsors/managing-your-sponsorship-tiers)")
| `sponsored_developer_update_newsletter_send` | Triggered when you send an email update to your sponsors (see "[Contacting your sponsors](/articles/contacting-your-sponsors)")
| `waitlist_invite_sponsored_developer` | Triggered when you are invited to join {% data variables.product.prodname_sponsors %} from the waitlist (see "[Setting up {% data variables.product.prodname_sponsors %} for your user account](/github/supporting-the-open-source-community-with-github-sponsors/setting-up-github-sponsors-for-your-user-account)")
| `waitlist_join` | Triggered when you join the waitlist to become a sponsored developer (see "[Setting up {% data variables.product.prodname_sponsors %} for your user account](/github/supporting-the-open-source-community-with-github-sponsors/setting-up-github-sponsors-for-your-user-account)")
| `sponsored_developer_profile_update` | Triggered when you edit your sponsored developer profile (see "[Editing your profile details for {% data variables.product.prodname_sponsors %}](/sponsors/receiving-sponsorships-through-github-sponsors/editing-your-profile-details-for-github-sponsors)")
| `sponsored_developer_request_approval` | Triggered when you submit your application for {% data variables.product.prodname_sponsors %} for approval (see "[Setting up {% data variables.product.prodname_sponsors %} for your user account](/sponsors/receiving-sponsorships-through-github-sponsors/setting-up-github-sponsors-for-your-user-account)")
| `sponsored_developer_tier_description_update` | Triggered when you change the description for a sponsorship tier (see "[Managing your sponsorship tiers](/sponsors/receiving-sponsorships-through-github-sponsors/managing-your-sponsorship-tiers)")
| `sponsored_developer_update_newsletter_send` | Triggered when you send an email update to your sponsors (see "[Contacting your sponsors](/sponsors/receiving-sponsorships-through-github-sponsors/contacting-your-sponsors)")
| `waitlist_invite_sponsored_developer` | Triggered when you are invited to join {% data variables.product.prodname_sponsors %} from the waitlist (see "[Setting up {% data variables.product.prodname_sponsors %} for your user account](/sponsors/receiving-sponsorships-through-github-sponsors/setting-up-github-sponsors-for-your-user-account)")
| `waitlist_join` | Triggered when you join the waitlist to become a sponsored developer (see "[Setting up {% data variables.product.prodname_sponsors %} for your user account](/sponsors/receiving-sponsorships-through-github-sponsors/setting-up-github-sponsors-for-your-user-account)")
{% endif %}
{% if currentVersion == "free-pro-team@latest" %}

View File

@@ -11,7 +11,7 @@ topics:
{% tip %}
**GitHub Enterprise users**: Accessing GitHub Enterprise via SSH over the HTTPS port is currently not supported.
**{% data variables.product.prodname_ghe_server %} users**: Accessing {% data variables.product.prodname_ghe_server %} via SSH over the HTTPS port is currently not supported.
{% endtip %}

View File

@@ -25,6 +25,12 @@ When you enable access and security for a repository owned by your user account,
1. If you chose "Selected repositories", select the drop-down menu, then click a repository to allow the repository's codespaces to access other repositories you own. Repeat for all repositories whose codespaces you want to access other repositories you own.
!["Selected repositories" drop-down menu](/assets/images/help/settings/codespaces-access-and-security-repository-drop-down.png)
### Reviewing your security log for {% data variables.product.prodname_codespaces %}
The security log is where you can review {% data variables.product.prodname_codespaces %} actions that you have performed. For information about accessing the log, see "[Reviewing your security log](/github/authenticating-to-github/reviewing-your-security-log#accessing-your-security-log)."
The security log includes details on what action occured and when you performed it. For information about {% data variables.product.prodname_codespaces %} actions, see "[{% data variables.product.prodname_codespaces %} category actions](/github/authenticating-to-github/reviewing-your-security-log#codespaces-category-actions)".
### Managing security and access for your organization
Organization owners can manage security and access for {% data variables.product.prodname_codespaces %}.
@@ -41,3 +47,9 @@ When you enable access and security for a repository owned by your organization,
![Radio buttons to manage trusted repositories](/assets/images/help/settings/codespaces-access-and-security-radio-buttons.png)
1. If you chose "Selected repositories", select the drop-down menu, then click a repository to allow the repository's codespaces to access other repositories owned by your organization. Repeat for all repositories whose codespaces you want to access other repositories.
!["Selected repositories" drop-down menu](/assets/images/help/settings/codespaces-access-and-security-repository-drop-down.png)
### Reviewing your organization's audit logs for {% data variables.product.prodname_codespaces %}
The audit log is where you can review actions related to {% data variables.product.prodname_codespaces %} that have been performed by members of your organization. For information about accessing the log, see "[Reviewing your security log](/organizations/keeping-your-organization-secure/reviewing-the-audit-log-for-your-organization#accessing-the-audit-log)."
The audit log includes details such as who performed the action, what the action was, and when the action was performed. For information on {% data variables.product.prodname_codespaces %} actions, see "[{% data variables.product.prodname_codespaces %} category actions](/organizations/keeping-your-organization-secure/reviewing-the-audit-log-for-your-organization#codespaces-category-actions)."

View File

@@ -22,6 +22,7 @@ You can add encrypted secrets to your user account that you want to use in your
- Personal access tokens to cloud services
- Service principals
- Subscription identifiers
- [Credentials for a private image registry](#allowing-your-codespace-to-access-private-images)
You can choose which repositories should have access to each secret. Then, you can use the secret in any codespace you create for a repository that has access to the secret.
@@ -67,3 +68,22 @@ You can update the value of an existing secret, and you can change which reposit
!["Delete" button](/assets/images/help/settings/codespaces-secret-delete-button.png)
1. Read the warning, then click **OK**.
![Confirmation to delete secret](/assets/images/help/settings/codespaces-secret-delete-warning.png)
### Allowing your codespace to access private images
A registry is a secure space for storing and managing private container images, such as Azure Container Registry or DockerHub. By adding a secret, your codespace can access private images within the registry.
When a codespace launches, {% data variables.product.prodname_codespaces %} will check for the following three secrets, which define the server name, username, and personal access token (PAT) for the container registry. If those secrets are found, {% data variables.product.prodname_codespaces %} will make the registry available inside your codespace.
- `<*>_CONTAINER_REGISTRY_SERVER`
- `<*>_CONTAINER_REGISTRY_USER`
- `<*>_CONTAINER_REGISTRY_PASSWORD`
Use the steps in "[Adding a secret](#adding-a-secret)" to add a secret for each of these items. Replace the “<*>” in the name with a consistent identifier. For example, if you had a private image registry in Azure, it might look like the following:
```
ACR_CONTAINER_REGISTRY_SERVER = mycompany.azurecr.io
ACR_CONTAINER_REGISTRY_USER = acr-user-here
ACR_CONTAINER_REGISTRY_PASSWORD = <PAT>
```
![Image registry secret example](/assets/images/help/settings/codespaces-image-registry-secret-example.png)

View File

@@ -154,6 +154,51 @@ If your workflow does not contain a matrix called `language`, then {% data varia
with:
languages: cpp, csharp, python
```
{% if currentVersion == "free-pro-team@latest" %}
### Analyzing Python dependencies
For GitHub-hosted runners that use Linux only, the {% data variables.product.prodname_codeql_workflow %} will try to auto-install Python dependencies to give more results for the CodeQL analysis. You can control this behavior by specifying the `setup-python-dependencies` parameter for the action called by the "Initialize CodeQL" step. By default, this parameter is set to `true`:
- If the repository contains code written in Python, the "Initialize CodeQL" step installs the necessary dependencies on the GitHub-hosted runner. If the auto-install succeeds, the action also sets the environment variable `CODEQL_PYTHON` to the Python executable file that includes the dependencies.
- If the repository doesn't have any Python dependencies, or the dependencies are specified in an unexpected way, you'll get a warning and the action will continue with the remaining jobs. The action can run successfully even when there are problems interpreting dependencies, but the results may be incomplete.
Alternatively, you can install Python dependencies manually on any operating system. You will need to add `setup-python-dependencies` and set it to `false`, as well as set `CODEQL_PYTHON` to the Python executable that includes the dependencies, as shown in this workflow extract:
```yaml
jobs:
CodeQL-Build:
runs-on: ubuntu-latest{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
security-events: write
actions: read{% endif %}
steps:
- name: Checkout repository
uses: actions/checkout@v2
- name: Set up Python
uses: actions/setup-python@v2
with:
python-version: '3.x'
- name: Install dependencies
run: |
python -m pip install --upgrade pip
if [ -f requirements.txt ];
then pip install -r requirements.txt;
fi
# Set the `CODEQL-PYTHON` environment variable to the Python executable
# that includes the dependencies
echo "CODEQL_PYTHON=$(which python)" >> $GITHUB_ENV
- name: Initialize CodeQL
uses: github/codeql-action/init@v1
with:
languages: python
# Override the default behavior so that the action doesn't attempt
# to auto-install Python dependencies
setup-python-dependencies: false
```
{% endif %}
### Running additional queries

View File

@@ -44,7 +44,10 @@ on:
jobs:
analyze:
name: Analyze
runs-on: ubuntu-latest
runs-on: ubuntu-latest{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
security-events: write
actions: read{% endif %}
strategy:
fail-fast: false

View File

@@ -29,7 +29,10 @@ If an automatic build of code for a compiled language within your project fails,
```yaml
jobs:
analyze:
analyze:{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
security-events: write
actions: read{% endif %}
...
strategy:
fail-fast: false

View File

@@ -63,7 +63,9 @@ on:
jobs:
build:
runs-on: ubuntu-latest
runs-on: ubuntu-latest{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
security-events: write{% endif %}
steps:
# This step checks out a copy of your repository.
- name: Checkout repository
@@ -95,6 +97,9 @@ on:
jobs:
build:
runs-on: ubuntu-latest{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
security-events: write{% endif %}
steps:
- uses: actions/checkout@v2
- name: Run npm install

View File

@@ -21,7 +21,7 @@ Query parameters are optional parts of a URL you can customize to share a specif
You must have the proper permissions for any action to use the equivalent query parameter. For example, you must have permission to add a label to an issue to use the `labels` query parameter.
If you create an invalid URL using query parameters, or if you dont have the proper permissions, the URL will return a 404 error page.
If you create an invalid URL using query parameters, or if you dont have the proper permissions, the URL will return a `404 Not Found` error page. If you create a URL that exceeds the server limit, the URL will return a `414 URI Too Long` error page.
### Supported query parameters

View File

@@ -17,5 +17,5 @@ topics:
### Further reading
- "[About {% data variables.product.prodname_sponsors %}](/articles/about-github-sponsors)"
- "[Sponsoring open source contributors](/github/supporting-the-open-source-community-with-github-sponsors/sponsoring-open-source-contributors)"
- "[About {% data variables.product.prodname_sponsors %}](/sponsors/getting-started-with-github-sponsors/about-github-sponsors)"
- "[Sponsoring open source contributors](/sponsors/sponsoring-open-source-contributors)"

View File

@@ -49,3 +49,20 @@ You can disable all workflows for an enterprise or set a policy that configures
{% data reusables.enterprise-accounts.policies-tab %}
{% data reusables.enterprise-accounts.actions-tab %}
{% data reusables.github-actions.private-repository-forks-configure %}
### Setting the permissions of the `GITHUB_TOKEN` for your enterprise
{% data reusables.github-actions.workflow-permissions-intro %}
You can set the default permissions for the `GITHUB_TOKEN` in the settings for your enterprise, organizations, or repositories. If you choose the restricted option as the default in your enterprise settings, this prevents the more permissive setting being chosen in the organization or repository settings.
{% data reusables.github-actions.workflow-permissions-modifying %}
#### Configuring the default `GITHUB_TOKEN` permissions
{% data reusables.enterprise-accounts.access-enterprise %}
{% data reusables.enterprise-accounts.policies-tab %}
{% data reusables.enterprise-accounts.actions-tab %}
1. Under **Workflow permissions**, choose whether you want the `GITHUB_TOKEN` to have read and write access for all scopes, or just read access for the `contents` scope.
![Set GITHUB_TOKEN permissions for this enterprise](/assets/images/help/settings/actions-workflow-permissions-enterprise.png)
1. Click **Save** to apply the settings.

View File

@@ -141,69 +141,78 @@ You can disable some of the badges for {% data variables.product.prodname_dotcom
### List of qualifying repositories for Mars 2020 Helicopter Contributor badge
If you authored any commit(s) on the default branch of one or more of the repositories below, up to the specified version, you'll receive the Mars 2020 Helicopter Contributor badge on your profile. The list was built based on the information received from NASA's Jet Propulsion Laboratory.
If you authored any commit(s) present in the commit history for the listed tag of one or more of the repositories below, you'll receive the Mars 2020 Helicopter Contributor badge on your profile. The authored commit must be with a verified email address, associated with your account at the time {% data variables.product.prodname_dotcom %} determined the eligible contributions, in order to be attributed to you. Future changes to verified emails will not have an effect on the badge. We built the list based on information received from NASA's Jet Propulsion Laboratory.
| {% data variables.product.prodname_dotcom %} Repository | Version |
|---|---|
| [torvalds/linux](https://github.com/torvalds/linux) | 3.4 |
| [nasa/fprime](https://github.com/nasa/fprime) | 1.3 |
| [python/cpython](https://github.com/python/cpython) | 3.9.2 |
| [boto/boto3](https://github.com/boto/boto3) | 1.17.17 |
| [boto/botocore](https://github.com/boto/botocore) | 1.20.11 |
| [certifi/python-certifi](https://github.com/certifi/python-certifi) | 2020.12.5 |
| [chardet/chardet](https://github.com/chardet/chardet) | 4.0.0 |
| [matplotlib/cycler](https://github.com/matplotlib/cycler) | 0.10.0 |
| [elastic/elasticsearch-py](https://github.com/elastic/elasticsearch-py) | 6.8.1 |
| [ianare/exif-py](https://github.com/ianare/exif-py) | 2.3.2 |
| [kjd/idna](https://github.com/kjd/idna) | 2.10 |
| [jmespath/jmespath.py](https://github.com/jmespath/jmespath.py) | 0.10.0 |
| [nucleic/kiwi](https://github.com/nucleic/kiwi) | 1.3.1 |
| [matplotlib/matplotlib](https://github.com/matplotlib/matplotlib) | 3.3.4 |
| [numpy/numpy](https://github.com/numpy/numpy) | 1.20.1 |
| [opencv/opencv-python](https://github.com/opencv/opencv-python) | 4.5.1.48 |
| [python-pillow/Pillow](https://github.com/python-pillow/Pillow) | 8.1.0 |
| [pycurl/pycurl](https://github.com/pycurl/pycurl) | 7.43.0.6 |
| [pyparsing/pyparsing](https://github.com/pyparsing/pyparsing) | 2.4.7 |
| [pyserial/pyserial](https://github.com/pyserial/pyserial) | 3.5 |
| [dateutil/dateutil](https://github.com/dateutil/dateutil) | 2.8.1 |
| [yaml/pyyaml](https://github.com/yaml/pyyaml) | 5.4.1 |
| [psf/requests](https://github.com/psf/requests) | 2.25.1 |
| [boto/s3transfer](https://github.com/boto/s3transfer) | 0.3.4 |
| [enthought/scimath](https://github.com/enthought/scimath) | 4.2.0 |
| [scipy/scipy](https://github.com/scipy/scipy) | 1.6.1 |
| [benjaminp/six](https://github.com/benjaminp/six) | 1.15.0 |
| [enthought/traits](https://github.com/enthought/traits) | 6.2.0 |
| [urllib3/urllib3](https://github.com/urllib3/urllib3) | 1.26.3 |
| [python-attrs/attrs](https://github.com/python-attrs/attrs) | 19.3.0 |
| [CheetahTemplate3/cheetah3](https://github.com/CheetahTemplate3/cheetah3/) | 3.2.4 |
| [pallets/click](https://github.com/pallets/click) | 7.0 |
| [pallets/flask](https://github.com/pallets/flask) | 1.1.1 |
| [flask-restful/flask-restful](https://github.com/flask-restful/flask-restful) | 0.3.7 |
| [pytest-dev/iniconfig](https://github.com/pytest-dev/iniconfig) | 1.0.0 |
| [pallets/itsdangerous](https://github.com/pallets/itsdangerous) | 1.1.0 |
| [pallets/jinja](https://github.com/pallets/jinja) | 2.10.3 |
| [lxml/lxml](https://github.com/lxml/lxml) | 4.4.1 |
| [Python-Markdown/markdown](https://github.com/Python-Markdown/markdown) | 3.1.1 |
| [pallets/markupsafe](https://github.com/pallets/markupsafe) | 1.1.1 |
| [pypa/packaging](https://github.com/pypa/packaging) | 19.2 |
| [pexpect/pexpect](https://github.com/pexpect/pexpect) | 4.7.0 |
| [pytest-dev/pluggy](https://github.com/pytest-dev/pluggy) | 0.13.0 |
| [pexpect/ptyprocess](https://github.com/pexpect/ptyprocess) | 0.6.0 |
| [pytest-dev/py](https://github.com/pytest-dev/py) | 1.8.0 |
| [pyparsing/pyparsing](https://github.com/pyparsing/pyparsing) | 2.4.5 |
| [pytest-dev/pytest](https://github.com/pytest-dev/pytest) | 5.3.0 |
| [stub42/pytz](https://github.com/stub42/pytz) | 2019.3 |
| [uiri/toml](https://github.com/uiri/toml) | 0.10.0 |
| [pallets/werkzeug](https://github.com/pallets/werkzeug) | 0.16.0 |
| [dmnfarrell/tkintertable](https://github.com/dmnfarrell/tkintertable) | 1.2 |
| [wxWidgets/wxPython-Classic](https://github.com/wxWidgets/wxPython-Classic) | 2.9.1.1 |
| [opencv/opencv](https://github.com/opencv/opencv) | 4.5.1 |
| [curl/curl](https://github.com/curl/curl) | 7.19.0 |
| [madler/zlib](https://github.com/madler/zlib) | 1.2.11 |
| [apache/lucene](https://github.com/apache/lucene) | 7.7.3 |
| [yaml/libyaml](https://github.com/yaml/libyaml) | 0.2.5 |
| [elastic/elasticsearch](https://github.com/elastic/elasticsearch) | 6.8.1 |
| [nucleic/cppy](https://github.com/nucleic/cppy) | 1.1.0 |
| {% data variables.product.prodname_dotcom %} Repository | Version | Tag |
|---|---|---|
| [torvalds/linux](https://github.com/torvalds/linux) | 3.4 | [v3.4](https://github.com/torvalds/linux/releases/tag/v3.4) |
| [python/cpython](https://github.com/python/cpython) | 3.9.2 | [v3.9.2](https://github.com/python/cpython/releases/tag/v3.9.2) |
| [boto/boto3](https://github.com/boto/boto3) | 1.17.17 | [1.17.17](https://github.com/boto/boto3/releases/tag/1.17.17) |
| [boto/botocore](https://github.com/boto/botocore) | 1.20.11 | [1.20.11](https://github.com/boto/botocore/releases/tag/1.20.11) |
| [certifi/python-certifi](https://github.com/certifi/python-certifi) | 2020.12.5 | [2020.12.05](https://github.com/certifi/python-certifi/releases/tag/2020.12.05) |
| [chardet/chardet](https://github.com/chardet/chardet) | 4.0.0 | [4.0.0](https://github.com/chardet/chardet/releases/tag/4.0.0) |
| [matplotlib/cycler](https://github.com/matplotlib/cycler) | 0.10.0 | [v0.10.0](https://github.com/matplotlib/cycler/releases/tag/v0.10.0) |
| [elastic/elasticsearch-py](https://github.com/elastic/elasticsearch-py) | 6.8.1 | [6.8.1](https://github.com/elastic/elasticsearch-py/releases/tag/6.8.1) |
| [ianare/exif-py](https://github.com/ianare/exif-py) | 2.3.2 | [2.3.2](https://github.com/ianare/exif-py/releases/tag/2.3.2) |
| [kjd/idna](https://github.com/kjd/idna) | 2.10 | [v2.10](https://github.com/kjd/idna/releases/tag/v2.10) |
| [jmespath/jmespath.py](https://github.com/jmespath/jmespath.py) | 0.10.0 | [0.10.0](https://github.com/jmespath/jmespath.py/releases/tag/0.10.0) |
| [nucleic/kiwi](https://github.com/nucleic/kiwi) | 1.3.1 | [1.3.1](https://github.com/nucleic/kiwi/releases/tag/1.3.1) |
| [matplotlib/matplotlib](https://github.com/matplotlib/matplotlib) | 3.3.4 | [v3.3.4](https://github.com/matplotlib/matplotlib/releases/tag/v3.3.4) |
| [numpy/numpy](https://github.com/numpy/numpy) | 1.20.1 | [v1.20.1](https://github.com/numpy/numpy/releases/tag/v1.20.1) |
| [opencv/opencv-python](https://github.com/opencv/opencv-python) | 4.5.1.48 | [48](https://github.com/opencv/opencv-python/releases/tag/48) |
| [python-pillow/Pillow](https://github.com/python-pillow/Pillow) | 8.1.0 | [8.1.0](https://github.com/python-pillow/Pillow/releases/tag/8.1.0) |
| [pycurl/pycurl](https://github.com/pycurl/pycurl) | 7.43.0.6 | [REL_7_43_0_6](https://github.com/pycurl/pycurl/releases/tag/REL_7_43_0_6) |
| [pyparsing/pyparsing](https://github.com/pyparsing/pyparsing) | 2.4.7 | [pyparsing_2.4.7](https://github.com/pyparsing/pyparsing/releases/tag/pyparsing_2.4.7) |
| [pyserial/pyserial](https://github.com/pyserial/pyserial) | 3.5 | [v3.5](https://github.com/pyserial/pyserial/releases/tag/v3.5) |
| [dateutil/dateutil](https://github.com/dateutil/dateutil) | 2.8.1 | [2.8.1](https://github.com/dateutil/dateutil/releases/tag/2.8.1) |
| [yaml/pyyaml ](https://github.com/yaml/pyyaml) | 5.4.1 | [5.4.1](https://github.com/yaml/pyyaml/releases/tag/5.4.1) |
| [psf/requests](https://github.com/psf/requests) | 2.25.1 | [v2.25.1](https://github.com/psf/requests/releases/tag/v2.25.1) |
| [boto/s3transfer](https://github.com/boto/s3transfer) | 0.3.4 | [0.3.4](https://github.com/boto/s3transfer/releases/tag/0.3.4) |
| [enthought/scimath](https://github.com/enthought/scimath) | 4.2.0 | [4.2.0](https://github.com/enthought/scimath/releases/tag/4.2.0) |
| [scipy/scipy](https://github.com/scipy/scipy) | 1.6.1 | [v1.6.1](https://github.com/scipy/scipy/releases/tag/v1.6.1) |
| [benjaminp/six](https://github.com/benjaminp/six) | 1.15.0 | [1.15.0](https://github.com/benjaminp/six/releases/tag/1.15.0) |
| [enthought/traits](https://github.com/enthought/traits) | 6.2.0 | [6.2.0](https://github.com/enthought/traits/releases/tag/6.2.0) |
| [urllib3/urllib3](https://github.com/urllib3/urllib3) | 1.26.3 | [1.26.3](https://github.com/urllib3/urllib3/releases/tag/1.26.3) |
| [python-attrs/attrs](https://github.com/python-attrs/attrs) | 19.3.0 | [19.3.0](https://github.com/python-attrs/attrs/releases/tag/19.3.0) |
| [CheetahTemplate3/cheetah3](https://github.com/CheetahTemplate3/cheetah3/) | 3.2.4 | [3.2.4](https://github.com/CheetahTemplate3/cheetah3/releases/tag/3.2.4) |
| [pallets/click](https://github.com/pallets/click) | 7.0 | [7.0](https://github.com/pallets/click/releases/tag/7.0) |
| [pallets/flask](https://github.com/pallets/flask) | 1.1.1 | [1.1.1](https://github.com/pallets/flask/releases/tag/1.1.1) |
| [flask-restful/flask-restful](https://github.com/flask-restful/flask-restful) | 0.3.7 | [0.3.7](https://github.com/flask-restful/flask-restful/releases/tag/0.3.7) |
| [pytest-dev/iniconfig](https://github.com/pytest-dev/iniconfig) | 1.0.0 | [v1.0.0](https://github.com/pytest-dev/iniconfig/releases/tag/v1.0.0) |
| [pallets/itsdangerous](https://github.com/pallets/itsdangerous) | 1.1.0 | [1.1.0](https://github.com/pallets/itsdangerous/releases/tag/1.1.0) |
| [pallets/jinja](https://github.com/pallets/jinja) | 2.10.3 | [2.10.3](https://github.com/pallets/jinja/releases/tag/2.10.3) |
| [lxml/lxml](https://github.com/lxml/lxml) | 4.4.1 | [lxml-4.4.1](https://github.com/lxml/lxml/releases/tag/lxml-4.4.1) |
| [Python-Markdown/markdown](https://github.com/Python-Markdown/markdown) | 3.1.1 | [3.1.1](https://github.com/Python-Markdown/markdown/releases/tag/3.1.1) |
| [pallets/markupsafe](https://github.com/pallets/markupsafe) | 1.1.1 | [1.1.1](https://github.com/pallets/markupsafe/releases/tag/1.1.1) |
| [pypa/packaging](https://github.com/pypa/packaging) | 19.2 | [19.2](https://github.com/pypa/packaging/releases/tag/19.2) |
| [pexpect/pexpect](https://github.com/pexpect/pexpect) | 4.7.0 | [4.7.0](https://github.com/pexpect/pexpect/releases/tag/4.7.0) |
| [pytest-dev/pluggy](https://github.com/pytest-dev/pluggy) | 0.13.0 | [0.13.0](https://github.com/pytest-dev/pluggy/releases/tag/0.13.0) |
| [pexpect/ptyprocess](https://github.com/pexpect/ptyprocess) | 0.6.0 | [0.6.0](https://github.com/pexpect/ptyprocess/releases/tag/0.6.0) |
| [pytest-dev/py](https://github.com/pytest-dev/py) | 1.8.0 | [1.8.0](https://github.com/pytest-dev/py/releases/tag/1.8.0) |
| [pyparsing/pyparsing](https://github.com/pyparsing/pyparsing) | 2.4.5 | [pyparsing_2.4.5](https://github.com/pyparsing/pyparsing/releases/tag/pyparsing_2.4.5) |
| [pytest-dev/pytest](https://github.com/pytest-dev/pytest) | 5.3.0 | [5.3.0](https://github.com/pytest-dev/pytest/releases/tag/5.3.0) |
| [stub42/pytz](https://github.com/stub42/pytz) | 2019.3 | [release_2019.3](https://github.com/stub42/pytz/releases/tag/release_2019.3) |
| [uiri/toml](https://github.com/uiri/toml) | 0.10.0 | [0.10.0](https://github.com/uiri/toml/releases/tag/0.10.0) |
| [pallets/werkzeug](https://github.com/pallets/werkzeug) | 0.16.0 | [0.16.0](https://github.com/pallets/werkzeug/releases/tag/0.16.0) |
| [dmnfarrell/tkintertable](https://github.com/dmnfarrell/tkintertable) | 1.2 | [v1.2](https://github.com/dmnfarrell/tkintertable/releases/tag/v1.2) |
| [wxWidgets/wxPython-Classic](https://github.com/wxWidgets/wxPython-Classic) | 2.9.1.1 | [wxPy-2.9.1.1](https://github.com/wxWidgets/wxPython-Classic/releases/tag/wxPy-2.9.1.1) |
| [nasa/fprime](https://github.com/nasa/fprime) | 1.3 | [NASA-v1.3](https://github.com/nasa/fprime/releases/tag/NASA-v1.3) |
| [nucleic/cppy](https://github.com/nucleic/cppy) | 1.1.0 | [1.1.0](https://github.com/nucleic/cppy/releases/tag/1.1.0) |
| [opencv/opencv](https://github.com/opencv/opencv) | 4.5.1 | [4.5.1](https://github.com/opencv/opencv/releases/tag/4.5.1) |
| [curl/curl](https://github.com/curl/curl) | 7.72.0 | [curl-7_72_0](https://github.com/curl/curl/releases/tag/curl-7_72_0) |
| [madler/zlib](https://github.com/madler/zlib) | 1.2.11 | [v1.2.11](https://github.com/madler/zlib/releases/tag/v1.2.11) |
| [apache/lucene](https://github.com/apache/lucene) | 7.7.3 | [releases/lucene-solr/7.7.3](https://github.com/apache/lucene/releases/tag/releases%2Flucene-solr%2F7.7.3) |
| [yaml/libyaml](https://github.com/yaml/libyaml) | 0.2.5 | [0.2.5](https://github.com/yaml/libyaml/releases/tag/0.2.5) |
| [elastic/elasticsearch](https://github.com/elastic/elasticsearch) | 6.8.1 | [v6.8.1](https://github.com/elastic/elasticsearch/releases/tag/v6.8.1) |
| [twbs/bootstrap](https://github.com/twbs/bootstrap) | 4.3.1 | [v4.3.1](https://github.com/twbs/bootstrap/releases/tag/v4.3.1) |
| [vuejs/vue](https://github.com/vuejs/vue) | 2.6.10 | [v2.6.10](https://github.com/vuejs/vue/releases/tag/v2.6.10) |
| [carrotsearch/hppc](https://github.com/carrotsearch/hppc) | 0.7.1 | [0.7.1](https://github.com/carrotsearch/hppc/releases/tag/0.7.1) |
| [JodaOrg/joda-time](https://github.com/JodaOrg/joda-time) | 2.10.1 | [v2.10.1](https://github.com/JodaOrg/joda-time/releases/tag/v2.10.1) |
| [tdunning/t-digest](https://github.com/tdunning/t-digest) | 3.2 | [t-digest-3.2](https://github.com/tdunning/t-digest/releases/tag/t-digest-3.2) |
| [HdrHistogram/HdrHistogram](https://github.com/HdrHistogram/HdrHistogram) | 2.1.9 | [HdrHistogram-2.1.9](https://github.com/HdrHistogram/HdrHistogram/releases/tag/HdrHistogram-2.1.9) |
| [locationtech/spatial4j](https://github.com/locationtech/spatial4j) | 0.7 | [spatial4j-0.7](https://github.com/locationtech/spatial4j/releases/tag/spatial4j-0.7) |
| [locationtech/jts](https://github.com/locationtech/jts) | 1.15.0 | [jts-1.15.0](https://github.com/locationtech/jts/releases/tag/jts-1.15.0) |
| [apache/log4j](https://github.com/apache/log4j) | 2.11 | [v1_2_11](https://github.com/apache/log4j/releases/tag/v1_2_11) |
### Further reading

View File

@@ -64,7 +64,7 @@ We require some basic information at the time of account creation. When you crea
##### Payment information
If you sign on to a paid Account with us, send funds through the GitHub Sponsors Program, or buy an application on GitHub Marketplace, we collect your full name, address, and credit card information or PayPal information. Please note, GitHub does not process or store your credit card information or PayPal information, but our third-party payment processor does.
If you list and sell an application on [GitHub Marketplace](https://github.com/marketplace), we require your banking information. If you raise funds through the [GitHub Sponsors Program](https://github.com/sponsors), we require some [additional information](/github/supporting-the-open-source-community-with-github-sponsors/becoming-a-sponsored-developer#submitting-your-bank-information) through the registration process for you to participate in and receive funds through those services and for compliance purposes.
If you list and sell an application on [GitHub Marketplace](https://github.com/marketplace), we require your banking information. If you raise funds through the [GitHub Sponsors Program](https://github.com/sponsors), we require some [additional information](/sponsors/receiving-sponsorships-through-github-sponsors/setting-up-github-sponsors-for-your-user-account#submitting-your-bank-information) through the registration process for you to participate in and receive funds through those services and for compliance purposes.
##### Profile information
You may choose to give us more information for your Account profile, such as your full name, an avatar which may include a photograph, your biography, your location, your company, and a URL to a third-party website. This information may include User Personal Information. Please note that your profile information may be visible to other Users of our Service.

View File

@@ -1,33 +0,0 @@
---
title: Supporting the open source community with GitHub Sponsors
shortTitle: GitHub Sponsors
intro: 'You can support the people and organizations who design, build, and maintain the open source projects you depend on by compensating them via {% data variables.product.prodname_dotcom %}.'
redirect_from:
- /categories/supporting-the-open-source-community-with-github-sponsors
versions:
free-pro-team: '*'
topics:
- sponsors
---
### Table of Contents
{% topic_link_in_list /overview %}
{% link_in_list /about-github-sponsors %}
{% topic_link_in_list /sponsoring-open-source-contributors %}
{% link_in_list /sponsoring-an-open-source-contributor %}
{% link_in_list /managing-your-sponsorship %}
{% link_in_list /attributing-sponsorships-to-your-organization %}
{% topic_link_in_list /receiving-sponsorships-through-github-sponsors %}
{% link_in_list /about-github-sponsors-for-open-source-contributors %}
{% link_in_list /setting-up-github-sponsors-for-your-user-account %}
{% link_in_list /setting-up-github-sponsors-for-your-organization %}
{% link_in_list /editing-your-profile-details-for-github-sponsors %}
{% link_in_list /managing-your-sponsorship-goal %}
{% link_in_list /managing-your-sponsorship-tiers %}
{% link_in_list /viewing-your-sponsors-and-sponsorships %}
{% link_in_list /managing-your-payouts-from-github-sponsors %}
{% link_in_list /configuring-webhooks-for-events-in-your-sponsored-account %}
{% link_in_list /contacting-your-sponsors %}
{% link_in_list /tax-information-for-github-sponsors %}

View File

@@ -1,14 +0,0 @@
---
title: Receiving sponsorships through GitHub Sponsors
shortTitle: Receiving sponsorships
intro: 'You or your organization can become a sponsored open source contributor to receive payments for your work, update your sponsorship details, and view and contact your sponsors.'
mapTopic: true
redirect_from:
- /articles/receiving-sponsorships-as-a-sponsored-developer
- /github/supporting-the-open-source-community-with-github-sponsors/receiving-sponsorships-as-a-sponsored-developer
versions:
free-pro-team: '*'
topics:
- sponsors
---

View File

@@ -25,6 +25,7 @@ children:
- graphql
- insights
- discussions
- sponsors
- communities
- pages
- education
@@ -52,4 +53,3 @@ externalProducts:
href: 'https://codeql.github.com/docs'
external: true
---

View File

@@ -35,6 +35,7 @@ To search for specific events, use the `action` qualifier in your query. Actions
| [`account`](#account-category-actions) | Contains all activities related to your organization account.
| [`advisory_credit`](#advisory_credit-category-actions) | Contains all activities related to crediting a contributor for a security advisory in the {% data variables.product.prodname_advisory_database %}. For more information, see "[About {% data variables.product.prodname_dotcom %} Security Advisories](/github/managing-security-vulnerabilities/about-github-security-advisories)."
| [`billing`](#billing-category-actions) | Contains all activities related to your organization's billing.
| [`codespaces`](#codespaces-category-actions) | Contains all activities related to your organization's codespaces.
| [`dependabot_alerts`](#dependabot_alerts-category-actions) | Contains organization-level configuration activities for {% data variables.product.prodname_dependabot %} alerts in existing repositories. For more information, see "[About alerts for vulnerable dependencies](/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies)."
| [`dependabot_alerts_new_repos`](#dependabot_alerts_new_repos-category-actions) | Contains organization-level configuration activities for {% data variables.product.prodname_dependabot %} alerts in new repositories created in the organization.
| [`dependabot_security_updates`](#dependabot_security_updates-category-actions) | Contains organization-level configuration activities for {% data variables.product.prodname_dependabot_security_updates %} in existing repositories. For more information, see "[Configuring {% data variables.product.prodname_dependabot_security_updates %}](/github/managing-security-vulnerabilities/configuring-dependabot-security-updates)."
@@ -189,6 +190,20 @@ An overview of some of the most common actions that are recorded as events in th
| `change_billing_type` | Triggered when your organization [changes how it pays for {% data variables.product.prodname_dotcom %}](/articles/adding-or-editing-a-payment-method).
| `change_email` | Triggered when your organization's [billing email address](/articles/setting-your-billing-email) changes.
#### `codespaces` category actions
| Action | Description
|------------------|-------------------
| `create` | Triggered when a user [creates a codespace](/github/developing-online-with-codespaces/creating-a-codespace).
| `resume` | Triggered when a user resumes a suspended codespace.
| `delete` | Triggered when a user [deletes a codespace](/github/developing-online-with-codespaces/deleting-a-codespace).
| `create_an_org_secret` | Triggered when a user creates an organization-level [secret for {% data variables.product.prodname_codespaces %}](/github/developing-online-with-codespaces/managing-encrypted-secrets-for-codespaces#about-encrypted-secrets-for-codespaces)
| `update_an_org_secret` | Triggered when a user updates an organization-level [secret for {% data variables.product.prodname_codespaces %}](/github/developing-online-with-codespaces/managing-encrypted-secrets-for-codespaces#about-encrypted-secrets-for-codespaces).
| `remove_an_org_secret` | Triggered when a user removes an organization-level [secret for {% data variables.product.prodname_codespaces %}](/github/developing-online-with-codespaces/managing-encrypted-secrets-for-codespaces#about-encrypted-secrets-for-codespaces).
| `manage_access_and_security` | Triggered when a user updates [which repositories a codespace can access](/github/developing-online-with-codespaces/managing-access-and-security-for-codespaces).
#### `dependabot_alerts` category actions
| Action | Description
@@ -627,19 +642,19 @@ For more information, see "[Managing the publication of {% data variables.produc
| `custom_amount_settings_change` | Triggered when you enable or disable custom amounts, or when you change the suggested custom amount (see "[Managing your sponsorship tiers](/github/supporting-the-open-source-community-with-github-sponsors/managing-your-sponsorship-tiers)")
| `repo_funding_links_file_action` | Triggered when you change the FUNDING file in your repository (see "[Displaying a sponsor button in your repository](/articles/displaying-a-sponsor-button-in-your-repository)")
| `sponsor_sponsorship_cancel` | Triggered when you cancel a sponsorship (see "[Downgrading a sponsorship](/articles/downgrading-a-sponsorship)")
| `sponsor_sponsorship_create` | Triggered when you sponsor an account (see "[Sponsoring an open source contributor](/github/supporting-the-open-source-community-with-github-sponsors/sponsoring-an-open-source-contributor)")
| `sponsor_sponsorship_preference_change` | Triggered when you change whether you receive email updates from a sponsored account (see "[Managing your sponsorship](/articles/managing-your-sponsorship)")
| `sponsor_sponsorship_create` | Triggered when you sponsor an account (see "[Sponsoring an open source contributor](/sponsors/sponsoring-open-source-contributors/sponsoring-an-open-source-contributor)")
| `sponsor_sponsorship_preference_change` | Triggered when you change whether you receive email updates from a sponsored account (see "[Managing your sponsorship](/sponsors/sponsoring-open-source-contributors/managing-your-sponsorship)")
| `sponsor_sponsorship_tier_change` | Triggered when you upgrade or downgrade your sponsorship (see "[Upgrading a sponsorship](/articles/upgrading-a-sponsorship)" and "[Downgrading a sponsorship](/articles/downgrading-a-sponsorship)")
| `sponsored_developer_approve` | Triggered when your {% data variables.product.prodname_sponsors %} account is approved (see "[Setting up {% data variables.product.prodname_sponsors %} for your organization](/github/supporting-the-open-source-community-with-github-sponsors/setting-up-github-sponsors-for-your-organization)")
| `sponsored_developer_create` | Triggered when your {% data variables.product.prodname_sponsors %} account is created (see "[Setting up {% data variables.product.prodname_sponsors %} for your organization](/github/supporting-the-open-source-community-with-github-sponsors/setting-up-github-sponsors-for-your-organization)")
| `sponsored_developer_approve` | Triggered when your {% data variables.product.prodname_sponsors %} account is approved (see "[Setting up {% data variables.product.prodname_sponsors %} for your organization](/sponsors/receiving-sponsorships-through-github-sponsors/setting-up-github-sponsors-for-your-organization)")
| `sponsored_developer_create` | Triggered when your {% data variables.product.prodname_sponsors %} account is created (see "[Setting up {% data variables.product.prodname_sponsors %} for your organization](/sponsors/receiving-sponsorships-through-github-sponsors/setting-up-github-sponsors-for-your-organization)")
| `sponsored_developer_disable` | Triggered when your {% data variables.product.prodname_sponsors %} account is disabled
| `sponsored_developer_redraft` | Triggered when your {% data variables.product.prodname_sponsors %} account is returned to draft state from approved state
| `sponsored_developer_profile_update` | Triggered when you edit your sponsored organization profile (see "[Editing your profile details for {% data variables.product.prodname_sponsors %}](/github/supporting-the-open-source-community-with-github-sponsors/editing-your-profile-details-for-github-sponsors)")
| `sponsored_developer_request_approval` | Triggered when you submit your application for {% data variables.product.prodname_sponsors %} for approval (see "[Setting up {% data variables.product.prodname_sponsors %} for your organization](/github/supporting-the-open-source-community-with-github-sponsors/setting-up-github-sponsors-for-your-organization)")
| `sponsored_developer_tier_description_update` | Triggered when you change the description for a sponsorship tier (see "[Managing your sponsorship tiers](/github/supporting-the-open-source-community-with-github-sponsors/managing-your-sponsorship-tiers)")
| `sponsored_developer_update_newsletter_send` | Triggered when you send an email update to your sponsors (see "[Contacting your sponsors](/articles/contacting-your-sponsors)")
| `waitlist_invite_sponsored_developer` | Triggered when you are invited to join {% data variables.product.prodname_sponsors %} from the waitlist (see "[Setting up {% data variables.product.prodname_sponsors %} for your organization](/github/supporting-the-open-source-community-with-github-sponsors/setting-up-github-sponsors-for-your-organization)")
| `waitlist_join` | Triggered when you join the waitlist to become a sponsored organization (see "[Setting up {% data variables.product.prodname_sponsors %} for your organization](/github/supporting-the-open-source-community-with-github-sponsors/setting-up-github-sponsors-for-your-organization)")
| `sponsored_developer_profile_update` | Triggered when you edit your sponsored organization profile (see "[Editing your profile details for {% data variables.product.prodname_sponsors %}](/sponsors/receiving-sponsorships-through-github-sponsors/editing-your-profile-details-for-github-sponsors)")
| `sponsored_developer_request_approval` | Triggered when you submit your application for {% data variables.product.prodname_sponsors %} for approval (see "[Setting up {% data variables.product.prodname_sponsors %} for your organization](/sponsors/receiving-sponsorships-through-github-sponsors/setting-up-github-sponsors-for-your-organization)")
| `sponsored_developer_tier_description_update` | Triggered when you change the description for a sponsorship tier (see "[Managing your sponsorship tiers](/sponsors/receiving-sponsorships-through-github-sponsors/managing-your-sponsorship-tiers)")
| `sponsored_developer_update_newsletter_send` | Triggered when you send an email update to your sponsors (see "[Contacting your sponsors](/sponsors/receiving-sponsorships-through-github-sponsors/contacting-your-sponsors)")
| `waitlist_invite_sponsored_developer` | Triggered when you are invited to join {% data variables.product.prodname_sponsors %} from the waitlist (see "[Setting up {% data variables.product.prodname_sponsors %} for your organization](/sponsors/receiving-sponsorships-through-github-sponsors/setting-up-github-sponsors-for-your-organization)")
| `waitlist_join` | Triggered when you join the waitlist to become a sponsored organization (see "[Setting up {% data variables.product.prodname_sponsors %} for your organization](/sponsors/receiving-sponsorships-through-github-sponsors/setting-up-github-sponsors-for-your-organization)")
{% endif %}
#### `team` category actions

View File

@@ -82,3 +82,23 @@ You can disable all workflows for an organization or set a policy that configure
{% data reusables.organizations.settings-sidebar-actions %}
{% data reusables.github-actions.private-repository-forks-configure %}
{% endif %}
{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
### Setting the permissions of the `GITHUB_TOKEN` for your organization
{% data reusables.github-actions.workflow-permissions-intro %}
You can set the default permissions for the `GITHUB_TOKEN` in the settings for your organization or your repositories. If you choose the restricted option as the default in your organization settings, the same option is auto-selected in the settings for repositories within your organization, and the permissive option is disabled. If your organization belongs to a {% data variables.product.prodname_enterprise %} account and the more restricted default has been selected in the enterprise settings, you won't be able to choose the more permissive default in your organization settings.
{% data reusables.github-actions.workflow-permissions-modifying %}
#### Configuring the default `GITHUB_TOKEN` permissions
{% data reusables.profile.access_profile %}
{% data reusables.profile.access_org %}
{% data reusables.organizations.org_settings %}
{% data reusables.organizations.settings-sidebar-actions %}
1. Under **Workflow permissions**, choose whether you want the `GITHUB_TOKEN` to have read and write access for all scopes, or just read access for the `contents` scope.
![Set GITHUB_TOKEN permissions for this organization](/assets/images/help/settings/actions-workflow-permissions-organization.png)
1. Click **Save** to apply the settings.
{% endif %}

View File

@@ -15,7 +15,7 @@ topics:
The developers and organizations that your organization sponsors can send you updates about their work. You can manage the email address that receives these updates.
You can also disable updates from accounts your organization sponsors. For more information, see "[Managing your sponsorship](/github/supporting-the-open-source-community-with-github-sponsors/managing-your-sponsorship#managing-email-updates-for-your-sponsorship)."
You can also disable updates from accounts your organization sponsors. For more information, see "[Managing your sponsorship](/sponsors/sponsoring-open-source-contributors/managing-your-sponsorship#managing-email-updates-for-your-sponsorship)."
{% data reusables.profile.access_org %}
{% data reusables.organizations.org_settings %}
@@ -26,4 +26,4 @@ You can also disable updates from accounts your organization sponsors. For more
### Further reading
- "[Supporting the open source community with {% data variables.product.prodname_sponsors %}](/github/supporting-the-open-source-community-with-github-sponsors)"
- "[{% data variables.product.prodname_sponsors %}](/sponsors)"

View File

@@ -60,9 +60,9 @@ Organization members can have *owner*{% if currentVersion == "free-pro-team@late
| Disable team discussions for an organization (see "[Disabling team discussions for your organization](/articles/disabling-team-discussions-for-your-organization)" for details) | **X** | | |
| Manage viewing of organization dependency insights (see "[Changing the visibility of your organization's dependency insights](/articles/changing-the-visibility-of-your-organizations-dependency-insights)" for details) | **X** | | |
| Set a team profile picture in **all teams** (see "[Setting your team's profile picture](/articles/setting-your-team-s-profile-picture)" for details) | **X** | | |
| Sponsor accounts and manage the organization's sponsorships (see "[Sponsoring open-source contributors](/github/supporting-the-open-source-community-with-github-sponsors/sponsoring-open-source-contributors)" for details) | **X** | **X** | |
| Sponsor accounts and manage the organization's sponsorships (see "[Sponsoring open-source contributors](/sponsors/sponsoring-open-source-contributors)" for details) | **X** | **X** | |
| Manage email updates from sponsored accounts (see "[Managing updates from accounts your organization's sponsors](/organizations/managing-organization-settings/managing-updates-from-accounts-your-organization-sponsors)" for details) | **X** | | |
| Attribute your sponsorships to another organization (see "[Attributing sponsorships to your organization](/github/supporting-the-open-source-community-with-github-sponsors/attributing-sponsorships-to-your-organization)" for details ) | **X** | | |
| Attribute your sponsorships to another organization (see "[Attributing sponsorships to your organization](/sponsors/sponsoring-open-source-contributors/attributing-sponsorships-to-your-organization)" for details ) | **X** | | |
| Manage the publication of {% data variables.product.prodname_pages %} sites from repositories in the organization (see "[Managing the publication of {% data variables.product.prodname_pages %} sites for your organization](/organizations/managing-organization-settings/managing-the-publication-of-github-pages-sites-for-your-organization)" for details) | **X** | | |
| Manage security and analysis settings (see "[Managing security and analysis settings for your organization](/organizations/keeping-your-organization-secure/managing-security-and-analysis-settings-for-your-organization)" for details) | **X** | | |
| Enable and enforce [SAML single sign-on](/articles/about-identity-and-access-management-with-saml-single-sign-on) | **X** | | |

View File

@@ -35,7 +35,7 @@ For an authentication example, see "[Authenticating with the {% data variables.p
#### Authenticating to package registries on {% data variables.product.prodname_dotcom %}
{% if currentVersion == "free-pro-team@latest" %}If you want your workflow to authenticate to {% data variables.product.prodname_registry %} to access a package registry other than the {% data variables.product.prodname_container_registry %} on {% data variables.product.product_name %}, then{% else %}To authenticate to package registries on {% data variables.product.product_name %},{% endif %} we recommend using the `GITHUB_TOKEN` that {% data variables.product.product_name %} automatically creates for your repository when you enable {% data variables.product.prodname_actions %} instead of a personal access token for authentication. The `GITHUB_TOKEN` has `read:packages` and `write:packages` scopes to the current repository. For forks, the token also has the `read:packages` scope for the parent repository.
{% if currentVersion == "free-pro-team@latest" %}If you want your workflow to authenticate to {% data variables.product.prodname_registry %} to access a package registry other than the {% data variables.product.prodname_container_registry %} on {% data variables.product.product_name %}, then{% else %}To authenticate to package registries on {% data variables.product.product_name %},{% endif %} we recommend using the `GITHUB_TOKEN` that {% data variables.product.product_name %} automatically creates for your repository when you enable {% data variables.product.prodname_actions %} instead of a personal access token for authentication. {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}You should set the permissions for this access token in the workflow file to grant read access for the `contents` scope and write access for the `packages` scope. {% else %}It has read and write permissions for packages in the repository where the workflow runs. {% endif %}For forks, the `GITHUB_TOKEN` is granted read access for the parent repository. For more information, see "[Authenticating with the GITHUB_TOKEN](/actions/configuring-and-managing-workflows/authenticating-with-the-github_token)."
You can reference the `GITHUB_TOKEN` in your workflow file using the {% raw %}`{{secrets.GITHUB_TOKEN}}`{% endraw %} context. For more information, see "[Authenticating with the GITHUB_TOKEN](/actions/automating-your-workflow-with-github-actions/authenticating-with-the-github_token)."
@@ -87,7 +87,6 @@ You can use {% data variables.product.prodname_actions %} to automatically publi
The following example demonstrates how you can use {% data variables.product.prodname_actions %} to build and test your app, and then automatically create a Docker image and publish it to {% data variables.product.prodname_registry %}:
- Create a new workflow file in your repository (such as `.github/workflows/deploy-image.yml`), and add the following YAML:
{% raw %}
```yaml{:copy}
name: Create and publish a package
on:
@@ -114,12 +113,12 @@ The following example demonstrates how you can use {% data variables.product.pro
matrix:
os: [ubuntu-latest]
node-version: [12.x, 14.x]
steps:
steps: {% raw %}
- uses: actions/checkout@v2
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v1
with:
node-version: ${{ matrix.node-version }}
node-version: ${{ matrix.node-version }}{% endraw %}
- uses: actions/download-artifact@main
with:
name: webpack artifacts
@@ -132,22 +131,24 @@ The following example demonstrates how you can use {% data variables.product.pro
CI: true
build-and-push-image:
runs-on: ubuntu-latest
runs-on: ubuntu-latest {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
contents: read
packages: write {% endif %}
needs: run-npm-test
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Build container image
uses: docker/build-push-action@v1
with:
with: {% raw %}
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
registry: {% endraw %}{% if currentVersion == "github-ae@latest" %}docker.YOUR-HOSTNAME.com{% else %}docker.pkg.github.com{% endif %}{% raw %}
repository: ${{ github.repository }}/octo-image
repository: ${{ github.repository }}/octo-image {% endraw %}
tag_with_sha: true
tag_with_ref: true
```
{% endraw %}
The relevant settings are explained in the following table:
@@ -225,7 +226,22 @@ on:
<td>
This job uses <code>npm test</code> to test the code. The <code>needs: run-npm-build</code> command makes this job dependent on the <code>run-npm-build</code> job.
</td>
</tr>
</tr> {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
<tr>
<td>
{% raw %}
```yaml
permissions:
contents: read
packages: write
```
{% endraw %}
</td>
<td>
Sets the permissions granted to the <code>GITHUB_TOKEN</code> for the actions in this job.
</td>
</tr> {% endif %}
<tr>
<td>
@@ -351,9 +367,10 @@ tag_with_ref: true
You can install packages as part of your CI flow using {% data variables.product.prodname_actions %}. For example, you could configure a workflow so that anytime a developer pushes code to a pull request, the workflow resolves dependencies by downloading and installing packages hosted by {% data variables.product.prodname_registry %}. Then, the workflow can run CI tests that require the dependencies.
Installing packages hosted by the {% data variables.product.prodname_registry %} through {% data variables.product.prodname_actions %} requires minimal configuration or additional authentication when you use the `GITHUB_TOKEN`.{% if currentVersion == "free-pro-team@latest" %} Data transfer is also free when an action installs a package. For more information, see "[About billing for {% data variables.product.prodname_registry %}](/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-packages)."{% endif %}
Installing packages hosted by {% data variables.product.prodname_registry %} through {% data variables.product.prodname_actions %} requires minimal configuration or additional authentication when you use the `GITHUB_TOKEN`.{% if currentVersion == "free-pro-team@latest" %} Data transfer is also free when an action installs a package. For more information, see "[About billing for {% data variables.product.prodname_registry %}](/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-packages)."{% endif %}
{% if currentVersion == "free-pro-team@latest" %}
The `GITHUB_TOKEN` cannot install packages from any private repository besides the repository where the action runs. You cannot currently use the `GITHUB_TOKEN` to authenticate to {% data variables.product.prodname_github_container_registry %}.
{% endif %}
{% data reusables.package_registry.actions-configuration %}
@@ -381,7 +398,6 @@ Using the `GITHUB_TOKEN` instead of a PAT, which includes the `repo` scope, incr
For example, this workflow publishes a Docker container using {% raw %}`${{ secrets.GITHUB_TOKEN }}`{% endraw %} to authenticate.
{% raw %}
```yaml{:copy}
name: Demo Push
@@ -406,9 +422,12 @@ jobs:
# Push image to GitHub Packages.
# See also https://docs.docker.com/docker-hub/builds/
push:
runs-on: ubuntu-latest
runs-on: ubuntu-latest{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
packages: write
contents: read{% endif %}
steps:
{% raw %}steps:
- uses: actions/checkout@v2
- name: Build image
@@ -433,8 +452,7 @@ jobs:
echo IMAGE_ID=$IMAGE_ID
echo VERSION=$VERSION
docker tag $IMAGE_NAME $IMAGE_ID:$VERSION
docker push $IMAGE_ID:$VERSION
docker push $IMAGE_ID:$VERSION{% endraw %}
```
{% endraw %}
{% endif %}

View File

@@ -71,7 +71,10 @@ In this guide, you'll create a {% data variables.product.prodname_actions %} wor
publish-gpr:
needs: build
runs-on: ubuntu-latest
runs-on: ubuntu-latest{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}
permissions:
packages: write
contents: read{% endif %}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v1

View File

@@ -47,7 +47,7 @@ To set up a `www` or custom subdomain, such as `www.example.com` or `blog.exampl
![Save custom domain button](/assets/images/help/pages/save-custom-subdomain.png)
5. Navigate to your DNS provider and create a `CNAME` record that points your subdomain to the default domain for your site. For example, if you want to use the subdomain `www.example.com` for your user site, create a `CNAME` record that points `www.example.com` to `<user>.github.io`. If you want to use the subdomain `www.anotherexample.com` for your organization site, create a `CNAME` record that points `www.anotherexample.com` to `<organization>.github.io`. The `CNAME` record should always point to `<user>.github.io` or `<organization>.github.io`, excluding the repository name. {% data reusables.pages.contact-dns-provider %} {% data reusables.pages.default-domain-information %}
{% indented_data_reference site.data.reusables.pages.wildcard-dns-warning spaces=3 %}
{% indented_data_reference reusables.pages.wildcard-dns-warning spaces=3 %}
{% data reusables.command_line.open_the_multi_os_terminal %}
6. To confirm that your DNS record configured correctly, use the `dig` command, replacing _WWW.EXAMPLE.COM_ with your subdomain.
```shell
@@ -81,7 +81,7 @@ To set up an apex domain, such as `example.com`, you must configure a _CNAME_ fi
185.199.111.153
```
{% indented_data_reference site.data.reusables.pages.wildcard-dns-warning spaces=3 %}
{% indented_data_reference reusables.pages.wildcard-dns-warning spaces=3 %}
{% data reusables.command_line.open_the_multi_os_terminal %}
6. To confirm that your DNS record configured correctly, use the `dig` command, replacing _EXAMPLE.COM_ with your apex domain. Confirm that the results match the IP addresses for {% data variables.product.prodname_pages %} above.
```shell

View File

@@ -3,10 +3,13 @@ title: About GitHub Sponsors
intro: '{% data variables.product.prodname_sponsors %} allows the developer community to financially support the people and organizations who design, build, and maintain the open source projects they depend on, directly on {% data variables.product.product_name %}.'
redirect_from:
- /articles/about-github-sponsors
- /github/supporting-the-open-source-community-with-github-sponsors/about-github-sponsors
versions:
free-pro-team: '*'
type: 'overview'
topics:
- sponsors
- 'Open Source'
- 'Fundamentals'
---
### About {% data variables.product.prodname_sponsors %}
@@ -15,9 +18,9 @@ topics:
{% data reusables.sponsors.no-fees %} For more information, see "[About billing for {% data variables.product.prodname_sponsors %}](/articles/about-billing-for-github-sponsors)."
{% data reusables.sponsors.you-can-be-a-sponsored-developer %} For more information, see "[About {% data variables.product.prodname_sponsors %} for open source contributors](/github/supporting-the-open-source-community-with-github-sponsors/about-github-sponsors-for-open-source-contributors)" and "[Setting up {% data variables.product.prodname_sponsors %} for your user account](/github/supporting-the-open-source-community-with-github-sponsors/setting-up-github-sponsors-for-your-user-account)."
{% data reusables.sponsors.you-can-be-a-sponsored-developer %} For more information, see "[About {% data variables.product.prodname_sponsors %} for open source contributors](/sponsors/receiving-sponsorships-through-github-sponsors/about-github-sponsors-for-open-source-contributors)" and "[Setting up {% data variables.product.prodname_sponsors %} for your user account](/sponsors/receiving-sponsorships-through-github-sponsors/setting-up-github-sponsors-for-your-user-account)."
{% data reusables.sponsors.you-can-be-a-sponsored-organization %} For more information, see "[Setting up {% data variables.product.prodname_sponsors %} for your organization](/github/supporting-the-open-source-community-with-github-sponsors/setting-up-github-sponsors-for-your-organization)."
{% data reusables.sponsors.you-can-be-a-sponsored-organization %} For more information, see "[Setting up {% data variables.product.prodname_sponsors %} for your organization](/sponsors/receiving-sponsorships-through-github-sponsors/setting-up-github-sponsors-for-your-organization)."
When you become a sponsored developer or sponsored organization, additional terms for {% data variables.product.prodname_sponsors %} apply. For more information, see "[GitHub Sponsors Additional Terms](/github/site-policy/github-sponsors-additional-terms)."
@@ -31,7 +34,9 @@ When you become a sponsored developer or sponsored organization, additional term
The {% data variables.product.prodname_matching_fund %} aims to benefit members of the {% data variables.product.prodname_dotcom %} community who develop open source software that promotes the [{% data variables.product.prodname_dotcom %} Community Guidelines](/github/site-policy/github-community-guidelines). Payments to sponsored organizations and payments from organizations are not eligible for {% data variables.product.prodname_matching_fund %}.
To be eligible for the {% data variables.product.prodname_matching_fund %}, you must create a profile that will attract a community that will sustain you for the long term. For more information about creating a strong profile, see "[Editing your profile details for {% data variables.product.prodname_sponsors %}](/github/supporting-the-open-source-community-with-github-sponsors/editing-your-profile-details-for-github-sponsors)."
To be eligible for the {% data variables.product.prodname_matching_fund %}, you must create a profile that will attract a community that will sustain you for the long term. For more information about creating a strong profile, see "[Editing your profile details for {% data variables.product.prodname_sponsors %}](/sponsors/receiving-sponsorships-through-github-sponsors/editing-your-profile-details-for-github-sponsors)."
Donations between sponsored developers will not be matched.
{% data reusables.sponsors.legal-additional-terms %}
@@ -40,6 +45,6 @@ To be eligible for the {% data variables.product.prodname_matching_fund %}, you
{% data reusables.sponsors.feedback %}
### Further reading
- "[Sponsoring open source contributors](/github/supporting-the-open-source-community-with-github-sponsors/sponsoring-open-source-contributors)"
- "[Receiving sponsorships through {% data variables.product.prodname_sponsors %}](/github/supporting-the-open-source-community-with-github-sponsors/receiving-sponsorships-through-github-sponsors)"
- "[Sponsoring open source contributors](/sponsors/sponsoring-open-source-contributors)"
- "[Receiving sponsorships through {% data variables.product.prodname_sponsors %}](/sponsors/receiving-sponsorships-through-github-sponsors)"
- "[FAQ with the {% data variables.product.prodname_sponsors %} team](https://github.blog/2019-06-12-faq-with-the-github-sponsors-team/)" on {% data variables.product.prodname_blog %}

View File

@@ -1,10 +1,10 @@
---
title: Overview
title: Getting started with GitHub Sponsors
intro: 'Learn about {% data variables.product.prodname_sponsors %} and how you can get involved as a sponsor or open source contributor.'
mapTopic: true
versions:
free-pro-team: '*'
topics:
- sponsors
---
{% link_with_intro /about-github-sponsors %}
{% link_with_intro /quickstart-for-finding-contributors-to-sponsor %}

View File

@@ -0,0 +1,51 @@
---
title: Quickstart for finding contributors to sponsor
intro: 'Learn some best practices for finding open source contributors to sponsor.'
versions:
free-pro-team: '*'
type: 'quick_start'
topics:
- 'Open Source'
---
### Explore projects you depend on
As you consider where to find open source contributors to sponsor, consider starting at https://github.com/sponsors/community.
If you're logged in, the sponsors results will start with public dependencies that your repositories depend on.
![The Babel open source project with highlighted text that says "4 of your repositories depend on this"](/assets/images/help/sponsors/example-of-open-source-project-dependency.png)
You can also toggle which of your accounts to view results for and further filter or search.
![Search options on sponsors community search page](/assets/images/help/sponsors/sponsors-search-options.png)
### Explore whom others sponsor
You can see whom a user or organization sponsors on their {% data variables.product.prodname_dotcom %} profile page.
### Consider how you benefit from different contributions
Consider whether you benefit from the work of open source contributions, such as:
- Documentation
- Design
- Translation
- Newsletters
- Code reviews
- Tutorials
- Mentoring
- Triaging issues and helping with project management
- Answering questions
- Event planning
For more information on different types of open source contributions, see the [Open source guide](https://opensource.guide/how-to-contribute/#you-dont-have-to-contribute-code).
You can check if contributors you've benefited from have {% data variables.product.prodname_sponsors %} profiles by using search at https://github.com/sponsors/community.
### Search for a specific project or contributor
At https://github.com/sponsors/community, you can search by ecosystem, most used, recently updated, and more. You can filter search results for your personal user account or for organizations that you're a member of.
### Next steps
For more information on starting your sponsorship, see "[Sponsoring an open source contributor](/sponsors/sponsoring-open-source-contributors/sponsoring-an-open-source-contributor)."

View File

@@ -0,0 +1,17 @@
---
title: GitHub Sponsors guides
shortTitle: Guides
intro: 'Learn how to make the most of {% data variables.product.prodname_sponsors %}.'
allowTitleToDifferFromFilename: true
layout: product-sublanding
versions:
free-pro-team: '*'
includeGuides:
- /sponsors/getting-started-with-github-sponsors/quickstart-for-finding-contributors-to-sponsor
- /sponsors/sponsoring-open-source-contributors/attributing-sponsorships-to-your-organization
- /sponsors/sponsoring-open-source-contributors/managing-your-sponsorship
- /sponsors/receiving-sponsorships-through-github-sponsors/managing-your-payouts-from-github-sponsors
- /sponsors/receiving-sponsorships-through-github-sponsors/setting-up-github-sponsors-for-your-user-account
- /sponsors/receiving-sponsorships-through-github-sponsors/setting-up-github-sponsors-for-your-organization
- /sponsors/integrating-with-github-sponsors/configuring-webhooks-for-events-in-your-sponsored-account
---

35
content/sponsors/index.md Normal file
View File

@@ -0,0 +1,35 @@
---
title: GitHub Sponsors Documentation
shortTitle: GitHub Sponsors
intro: 'Invest in the open source projects you depend on, support digital infrastructure, and make open source careers possible by sponsoring open source contributors and their projects. Build a {% data variables.product.prodname_sponsors %} profile and receive compensation for your open source work.'
introLinks:
quickstart: /sponsors/getting-started-with-github-sponsors/quickstart-for-finding-contributors-to-sponsor
redirect_from:
- /categories/supporting-the-open-source-community-with-github-sponsors
- /github/supporting-the-open-source-community-with-github-sponsors
changelog:
label: 'sponsors'
featuredLinks:
guides:
- /sponsors/sponsoring-open-source-contributors/managing-your-sponsorship
- /sponsors/sponsoring-open-source-contributors/attributing-sponsorships-to-your-organization
- /sponsors/receiving-sponsorships-through-github-sponsors/managing-your-payouts-from-github-sponsors
guideCards:
- /sponsors/receiving-sponsorships-through-github-sponsors/setting-up-github-sponsors-for-your-user-account
- /sponsors/receiving-sponsorships-through-github-sponsors/setting-up-github-sponsors-for-your-organization
- /sponsors/integrating-with-github-sponsors/configuring-webhooks-for-events-in-your-sponsored-account
popular:
- /sponsors/sponsoring-open-source-contributors/sponsoring-an-open-source-contributor
- /sponsors/getting-started-with-github-sponsors/about-github-sponsors
- /sponsors/receiving-sponsorships-through-github-sponsors/tax-information-for-github-sponsors
- /sponsors/sponsoring-open-source-contributors
- /sponsors/about-github-sponsors-for-open-source-contributors
layout: product-landing
versions:
free-pro-team: '*'
---
<!--{% link_with_intro /getting-started-with-github-sponsors %}-->
<!--{% link_with_intro /sponsoring-open-source-contributors %}-->
<!--{% link_with_intro /receiving-sponsorships-through-github-sponsors%}-->
<!--{% link_with_intro /integrating-with-github-sponsors %}-->

View File

@@ -1,10 +1,15 @@
---
title: Configuring webhooks for events in your sponsored account
intro: You can configure webhooks to alert you when you receive new sponsorships or existing sponsors make changes to their sponsorships.
redirect_from:
- /github/supporting-the-open-source-community-with-github-sponsors/configuring-webhooks-for-events-in-your-sponsored-account
versions:
free-pro-team: '*'
type: 'how_to'
topics:
- sponsors
- 'Webhooks'
- 'Events'
- 'Open Source'
---
### About webhooks for events in your sponsored account

View File

@@ -0,0 +1,14 @@
---
title: Getting started with the Sponsors GraphQL API
intro: 'Using the GraphQL API, you can build custom integrations to manage or review your sponsorships.'
versions:
free-pro-team: '*'
type: 'overview'
topics:
- 'GraphQL'
- 'API'
---
To get started with the GraphQL API, see "[Introduction to GraphQL](/graphql/guides/introduction-to-graphql)."
You can find the details about the Sponsors GraphQL API in the reference docs. For more information, see "[GraphQL reference](/graphql/reference)." We recommend using the GraphQL explorer to build your GraphQL calls. For more information, see "[Using the explorer](/graphql/guides/using-the-explorer)."

View File

@@ -0,0 +1,9 @@
---
title: Integrating with GitHub Sponsors
intro: 'As an open source contributor, you can build custom tools to manage your GitHub sponsorships.'
versions:
free-pro-team: '*'
---
{% link_with_intro /configuring-webhooks-for-events-in-your-sponsored-account %}
{% link_with_intro /getting-started-with-the-sponsors-graphql-api %}

View File

@@ -6,25 +6,27 @@ redirect_from:
- /github/supporting-the-open-source-community-with-github-sponsors/about-github-sponsors-for-sponsored-developers
versions:
free-pro-team: '*'
type: 'overview'
topics:
- sponsors
- 'Open Source'
- 'Fundamentals'
---
### Joining {% data variables.product.prodname_sponsors %}
{% data reusables.sponsors.you-can-be-a-sponsored-developer %} For more information, see "[Setting up {% data variables.product.prodname_sponsors %} for your user account](/github/supporting-the-open-source-community-with-github-sponsors/setting-up-github-sponsors-for-your-user-account)."
{% data reusables.sponsors.you-can-be-a-sponsored-developer %} For more information, see "[Setting up {% data variables.product.prodname_sponsors %} for your user account](/sponsors/receiving-sponsorships-through-github-sponsors/setting-up-github-sponsors-for-your-user-account)."
{% data reusables.sponsors.you-can-be-a-sponsored-organization %} For more information, see "[Setting up {% data variables.product.prodname_sponsors %} for your organization](/github/supporting-the-open-source-community-with-github-sponsors/setting-up-github-sponsors-for-your-organization)."
{% data reusables.sponsors.you-can-be-a-sponsored-organization %} For more information, see "[Setting up {% data variables.product.prodname_sponsors %} for your organization](/sponsors/receiving-sponsorships-through-github-sponsors/setting-up-github-sponsors-for-your-organization)."
After you join {% data variables.product.prodname_sponsors %}, you can add a sponsor button to the open source repository you contribute to, to increase the visibility of your {% data variables.product.prodname_sponsors %} profile and other funding platforms. For more information, see "[Displaying a sponsor button in your repository](/articles/displaying-a-sponsor-button-in-your-repository)."
You can set a goal for your sponsorships. For more information, see "[Managing your sponsorship goal](/github/supporting-the-open-source-community-with-github-sponsors/managing-your-sponsorship-goal)."
You can set a goal for your sponsorships. For more information, see "[Managing your sponsorship goal](/sponsors/receiving-sponsorships-through-github-sponsors/managing-your-sponsorship-goal)."
{% data reusables.sponsors.github-contact-applicants %}
### Sponsorship tiers
{% data reusables.sponsors.tier-details %} For more information, see "[Setting up {% data variables.product.prodname_sponsors %} for your user account](/github/supporting-the-open-source-community-with-github-sponsors/setting-up-github-sponsors-for-your-user-account)," "[Setting up {% data variables.product.prodname_sponsors %} for your organization](/github/supporting-the-open-source-community-with-github-sponsors/setting-up-github-sponsors-for-your-organization), and "[Managing your sponsorship tiers](/github/supporting-the-open-source-community-with-github-sponsors/managing-your-sponsorship-tiers)."
{% data reusables.sponsors.tier-details %} For more information, see "[Setting up {% data variables.product.prodname_sponsors %} for your user account](/sponsors/receiving-sponsorships-through-github-sponsors/setting-up-github-sponsors-for-your-user-account)," "[Setting up {% data variables.product.prodname_sponsors %} for your organization](/sponsors/receiving-sponsorships-through-github-sponsors/setting-up-github-sponsors-for-your-organization), and "[Managing your sponsorship tiers](/sponsors/receiving-sponsorships-through-github-sponsors/managing-your-sponsorship-tiers)."
It's best to set up a range of different sponsorship options, including monthly and one-time tiers, to make it easy for anyone to support your work. In particular, one-time payments allow people to reward your efforts without worrying about whether their finances will support a regular payment schedule.
@@ -34,7 +36,7 @@ It's best to set up a range of different sponsorship options, including monthly
{% data reusables.sponsors.payout-info %}
For more information, see "[Managing your payouts from {% data variables.product.prodname_sponsors %}](/github/supporting-the-open-source-community-with-github-sponsors/managing-your-payouts-from-github-sponsors)."
For more information, see "[Managing your payouts from {% data variables.product.prodname_sponsors %}](/sponsors/receiving-sponsorships-through-github-sponsors/managing-your-payouts-from-github-sponsors)."
### Sharing feedback about {% data variables.product.prodname_sponsors %}

View File

@@ -3,20 +3,21 @@ title: Contacting your sponsors
intro: You can send an email to your sponsors who have opted in to receive updates about your work.
redirect_from:
- /articles/contacting-your-sponsors
- /github/supporting-the-open-source-community-with-github-sponsors/contacting-your-sponsors
versions:
free-pro-team: '*'
type: 'how_to'
topics:
- sponsors
- 'Open Source'
- 'Contacting sponsors'
---
### About sponsorship updates
Your sponsors can choose whether they receive email updates about your work. For more information, see "[Managing your sponsorship](/articles/managing-your-sponsorship)."
Your sponsors can choose whether they receive email updates about your work. For more information, see "[Managing your sponsorship](/sponsors/sponsoring-open-source-contributors/managing-your-sponsorship)."
For sponsored developer accounts, the update will come from your user account's primary email address. If you've enabled email address privacy on your user account, the update will come from `noreply@github.com` instead. For sponsored organizations, the update will come from the organization's `noreply@github.com` email address. For more information, see "[Setting your commit email address](/articles/setting-your-commit-email-address)."
You can also contact any one-time sponsors who contributed within the last 30 days and enabled updates.
### Contacting your sponsors
{% data reusables.sponsors.navigate-to-sponsors-dashboard %}

View File

@@ -4,10 +4,13 @@ intro: You can update the information that potential sponsors see about your wor
redirect_from:
- /articles/editing-your-sponsored-developer-profile
- /github/supporting-the-open-source-community-with-github-sponsors/editing-your-sponsored-developer-profile
- /github/supporting-the-open-source-community-with-github-sponsors/editing-your-profile-details-for-github-sponsors
versions:
free-pro-team: '*'
type: 'how_to'
topics:
- sponsors
- 'Sponsors profile'
- 'Open Source'
---
### About sponsor profiles

View File

@@ -0,0 +1,22 @@
---
title: Receiving sponsorships through GitHub Sponsors
shortTitle: Receiving sponsorships
intro: 'You or your organization can become a sponsored open source contributor to receive payments for your work, update your sponsorship details, and view and contact your sponsors.'
redirect_from:
- /articles/receiving-sponsorships-as-a-sponsored-developer
- /github/supporting-the-open-source-community-with-github-sponsors/receiving-sponsorships-as-a-sponsored-developer
- /github/supporting-the-open-source-community-with-github-sponsors/receiving-sponsorships-through-github-sponsors
versions:
free-pro-team: '*'
---
{% link_with_intro /about-github-sponsors-for-open-source-contributors %}
{% link_with_intro /setting-up-github-sponsors-for-your-user-account %}
{% link_with_intro /setting-up-github-sponsors-for-your-organization %}
{% link_with_intro /editing-your-profile-details-for-github-sponsors %}
{% link_with_intro /managing-your-sponsorship-goal %}
{% link_with_intro /managing-your-sponsorship-tiers %}
{% link_with_intro /viewing-your-sponsors-and-sponsorships %}
{% link_with_intro /managing-your-payouts-from-github-sponsors %}
{% link_with_intro /contacting-your-sponsors %}
{% link_with_intro /tax-information-for-github-sponsors %}

View File

@@ -3,15 +3,18 @@ title: Managing your payouts from GitHub Sponsors
intro: 'You can view information about past and future payouts from {% data variables.product.prodname_sponsors %} and edit your bank information.'
redirect_from:
- /articles/managing-your-payouts-from-github-sponsors
- /github/supporting-the-open-source-community-with-github-sponsors/managing-your-payouts-from-github-sponsors
versions:
free-pro-team: '*'
type: 'how_to'
topics:
- sponsors
- 'Sponsors payments'
- 'Open Source'
---
### About payouts from {% data variables.product.prodname_sponsors %}
You can only manage your payouts from {% data variables.product.prodname_sponsors %} if you are paid through Stripe Connect. If you are paid through ACH transfer or wire transfer for your sponsored user account, you will not see the **Payouts** tab on your sponsored open source contributor dashboard. Sponsored organizations can only use Stripe Connect for payouts. For more information, see "[About {% data variables.product.prodname_sponsors %} for open source contributors](/github/supporting-the-open-source-community-with-github-sponsors/about-github-sponsors-for-open-source-contributors#sponsorship-payouts)."
You can only manage your payouts from {% data variables.product.prodname_sponsors %} if you are paid through Stripe Connect. If you are paid through ACH transfer or wire transfer for your sponsored user account, you will not see the **Payouts** tab on your sponsored open source contributor dashboard. Sponsored organizations can only use Stripe Connect for payouts. For more information, see "[About {% data variables.product.prodname_sponsors %} for open source contributors](/sponsors/receiving-sponsorships-through-github-sponsors/about-github-sponsors-for-open-source-contributors#sponsorship-payouts)."
{% data reusables.sponsors.payout-info %}

View File

@@ -1,10 +1,15 @@
---
title: Managing your sponsorship goal
intro: You can set a goal for your sponsored developer or sponsored organization account to help the community understand the impact of sponsoring you.
redirect_from:
- /github/supporting-the-open-source-community-with-github-sponsors/manage-your-sponsorship-goal
- /github/supporting-the-open-source-community-with-github-sponsors/managing-your-sponsorship-goal
versions:
free-pro-team: '*'
type: 'how_to'
topics:
- sponsors
- 'Open Source'
- 'Sponsors profile'
---
### About sponsorship goals
@@ -13,12 +18,6 @@ You can set a funding goal for your sponsored account and share the goal with yo
Your goal can set a target for the number of sponsors you want to have or the amount of money you want to earn each month. You can only set one goal up at a time. After you reach a goal, you can set another goal.
{% note %}
**Note:** Goals are intended to help people track momentum so only monthly sponsors contribute toward your goal.
{% endnote %}
### Setting a goal
{% data reusables.sponsors.navigate-to-sponsors-dashboard %}

View File

@@ -4,10 +4,13 @@ intro: 'You can add a new sponsorship tier, or edit or retire an existing tier.'
redirect_from:
- /articles/changing-your-sponsorship-tiers
- /github/supporting-the-open-source-community-with-github-sponsors/changing-your-sponsorship-tiers
- /github/supporting-the-open-source-community-with-github-sponsors/managing-your-sponsorship-tiers
versions:
free-pro-team: '*'
type: 'how_to'
topics:
- sponsors
- 'Open Source'
- 'Sponsors profile'
---
### About sponsorship tiers

View File

@@ -4,11 +4,15 @@ intro: 'Your organization can join {% data variables.product.prodname_sponsors %
redirect_from:
- /articles/setting-up-github-sponsorship-for-your-organization
- /articles/receiving-sponsorships-as-a-sponsored-organization
- /github/supporting-the-open-source-community-with-github-sponsors/setting-up-github-sponsors-for-your-organization
permissions: 'Organization owners can set up {% data variables.product.prodname_sponsors %} for an organization.'
versions:
free-pro-team: '*'
type: 'how_to'
topics:
- sponsors
- 'Organizations'
- 'Sponsors profile'
- 'Open Source'
---
### Joining {% data variables.product.prodname_sponsors %}
@@ -17,7 +21,7 @@ topics:
After you receive an invitation for your organization to join {% data variables.product.prodname_sponsors %}, you can complete the steps below to become a sponsored organization.
To join {% data variables.product.prodname_sponsors %} as an individual contributor outside an organization, see "[Setting up {% data variables.product.prodname_sponsors %} for your user account](/github/supporting-the-open-source-community-with-github-sponsors/setting-up-github-sponsors-for-your-user-account)."
To join {% data variables.product.prodname_sponsors %} as an individual contributor outside an organization, see "[Setting up {% data variables.product.prodname_sponsors %} for your user account](/sponsors/receiving-sponsorships-through-github-sponsors/setting-up-github-sponsors-for-your-user-account)."
{% data reusables.sponsors.navigate-to-github-sponsors %}
{% data reusables.sponsors.view-eligible-accounts %}
@@ -48,7 +52,6 @@ To join {% data variables.product.prodname_sponsors %} as an individual contribu
{% data reusables.sponsors.tier-price-description %}
{% data reusables.sponsors.save-tier-draft %}
{% data reusables.sponsors.review-and-publish-tier %}
{% data reusables.sponsors.enable-custom-amounts %}
{% data reusables.sponsors.add-more-tiers %}
### Submitting your bank information
@@ -84,5 +87,5 @@ Before your organization can become a sponsored organization, you must enable 2F
{% data reusables.sponsors.github-review-app %}
### Further reading
- "[About {% data variables.product.prodname_sponsors %}](/articles/about-github-sponsors)"
- "[Receiving sponsorships through {% data variables.product.prodname_sponsors %}](/github/supporting-the-open-source-community-with-github-sponsors/receiving-sponsorships-through-github-sponsors)"
- "[About {% data variables.product.prodname_sponsors %}](/sponsors/getting-started-with-github-sponsors/about-github-sponsors)"
- "[Receiving sponsorships through {% data variables.product.prodname_sponsors %}](/sponsors/receiving-sponsorships-through-github-sponsors)"

View File

@@ -4,17 +4,20 @@ intro: 'You can become a sponsored developer by joining {% data variables.produc
redirect_from:
- /articles/becoming-a-sponsored-developer
- /github/supporting-the-open-source-community-with-github-sponsors/becoming-a-sponsored-developer
- /github/supporting-the-open-source-community-with-github-sponsors/setting-up-github-sponsors-for-your-user-account
versions:
free-pro-team: '*'
type: 'how_to'
topics:
- sponsors
- 'User account'
- 'Sponsors profile'
---
### Joining {% data variables.product.prodname_sponsors %}
{% data reusables.sponsors.you-can-be-a-sponsored-developer %} {% data reusables.sponsors.stripe-supported-regions %}
To join {% data variables.product.prodname_sponsors %} as an organization, see "[Setting up {% data variables.product.prodname_sponsors %} for your organization](/github/supporting-the-open-source-community-with-github-sponsors/setting-up-github-sponsors-for-your-organization)."
To join {% data variables.product.prodname_sponsors %} as an organization, see "[Setting up {% data variables.product.prodname_sponsors %} for your organization](/sponsors/receiving-sponsorships-through-github-sponsors/setting-up-github-sponsors-for-your-organization)."
{% data reusables.sponsors.navigate-to-github-sponsors %}
2. If you are an organization owner, you have more than one eligible account. Click **View your eligible accounts**, then in the list of accounts, find your user account.
@@ -48,7 +51,6 @@ After {% data variables.product.prodname_dotcom %} reviews your application, you
{% data reusables.sponsors.tier-price-description %}
{% data reusables.sponsors.save-tier-draft %}
{% data reusables.sponsors.review-and-publish-tier %}
{% data reusables.sponsors.enable-custom-amounts %}
{% data reusables.sponsors.add-more-tiers %}
### Submitting your bank information

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