1
0
mirror of synced 2026-01-02 03:04:13 -05:00

Merge branch 'main' into patch-2

This commit is contained in:
Ramya Parimi
2022-05-13 09:36:31 -05:00
committed by GitHub
30 changed files with 338 additions and 51 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 225 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 42 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 80 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 190 KiB

View File

@@ -64,8 +64,8 @@ For more information, see "[About code owners](/github/creating-cloning-and-arch
When creating workflows, [custom actions](/actions/creating-actions/about-actions), and [composite actions](/actions/creating-actions/creating-a-composite-action) actions, you should always consider whether your code might execute untrusted input from attackers. This can occur when an attacker adds malicious commands and scripts to a context. When your workflow runs, those strings might be interpreted as code which is then executed on the runner.
Attackers can add their own malicious content to the [`github` context](/actions/reference/context-and-expression-syntax-for-github-actions#github-context), which should be treated as potentially untrusted input. These contexts typically end with `body`, `default_branch`, `email`, `head_ref`, `label`, `message`, `name`, `page_name`,`ref`, and `title`. For example: `github.event.issue.title`, or `github.event.pull_request.body`.
Attackers can add their own malicious content to the [`github` context](/actions/reference/context-and-expression-syntax-for-github-actions#github-context), which should be treated as potentially untrusted input. These contexts typically end with `body`, `default_branch`, `email`, `head_ref`, `label`, `message`, `name`, `page_name`,`ref`, and `title`. For example: `github.event.issue.title`, or `github.event.pull_request.body`.
You should ensure that these values do not flow directly into workflows, actions, API calls, or anywhere else where they could be interpreted as executable code. By adopting the same defensive programming posture you would use for any other privileged application code, you can help security harden your use of {% data variables.product.prodname_actions %}. For information on some of the steps an attacker could take, see ["Potential impact of a compromised runner](/actions/learn-github-actions/security-hardening-for-github-actions#potential-impact-of-a-compromised-runner)."
In addition, there are other less obvious sources of potentially untrusted input, such as branch names and email addresses, which can be quite flexible in terms of their permitted content. For example, `zzz";echo${IFS}"hello";#` would be a valid branch name and would be a possible attack vector for a target repository.
@@ -91,7 +91,7 @@ A script injection attack can occur directly within a workflow's inline script.
```
{% endraw %}
This example is vulnerable to script injection because the `run` command executes within a temporary shell script on the runner. Before the shell script is run, the expressions inside {% raw %}`${{ }}`{% endraw %} are evaluated and then substituted with the resulting values, which can make it vulnerable to shell command injection.
This example is vulnerable to script injection because the `run` command executes within a temporary shell script on the runner. Before the shell script is run, the expressions inside {% raw %}`${{ }}`{% endraw %} are evaluated and then substituted with the resulting values, which can make it vulnerable to shell command injection.
To inject commands into this workflow, the attacker could create a pull request with a title of `a"; ls $GITHUB_WORKSPACE"`:
@@ -179,7 +179,7 @@ You can help mitigate this risk by following these good practices:
Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload.
* **Audit the source code of the action**
@@ -192,7 +192,7 @@ You can help mitigate this risk by following these good practices:
{% ifversion fpt or ghes > 3.3 or ghae-issue-4757 or ghec %}
## Reusing third-party workflows
The same principles described above for using third-party actions also apply to using third-party workflows. You can help mitigate the risks associated with reusing workflows by following the same good practices outlined above. For more information, see "[Reusing workflows](/actions/learn-github-actions/reusing-workflows)."
The same principles described above for using third-party actions also apply to using third-party workflows. You can help mitigate the risks associated with reusing workflows by following the same good practices outlined above. For more information, see "[Reusing workflows](/actions/learn-github-actions/reusing-workflows)."
{% endif %}
{% if internal-actions %}
@@ -201,17 +201,25 @@ The same principles described above for using third-party actions also apply to
{% data reusables.actions.outside-collaborators-internal-actions %} For more information, see "[Sharing actions and workflows with your enterprise](/actions/creating-actions/sharing-actions-and-workflows-with-your-enterprise)."
{% endif %}
{% if allow-actions-to-approve-pr %}
## Preventing {% data variables.product.prodname_actions %} from {% if allow-actions-to-approve-pr-with-ent-repo %}creating or {% endif %}approving pull requests
{% data reusables.actions.workflow-pr-approval-permissions-intro %} Allowing workflows, or any other automation, to {% if allow-actions-to-approve-pr-with-ent-repo %}create or {% endif %}approve pull requests could be a security risk if the pull request is merged without proper oversight.
For more information on how to configure this setting, see {% if allow-actions-to-approve-pr-with-ent-repo %}{% ifversion ghes or ghec or ghae %}"[Enforcing policies for {% data variables.product.prodname_actions %} in your enterprise](/enterprise-cloud@latest/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#preventing-github-actions-from-creating-or-approving-pull-requests)",{% endif %}{% endif %} "[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#preventing-github-actions-from-{% if allow-actions-to-approve-pr-with-ent-repo %}creating-or-{% endif %}approving-pull-requests)"{% if allow-actions-to-approve-pr-with-ent-repo %}, and "[Managing {% data variables.product.prodname_actions %} settings for a repository](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#preventing-github-actions-from-creating-or-approving-pull-requests)"{% endif %}.
{% endif %}
## Using OpenSSF Scorecards to secure workflows
[Scorecards](https://github.com/ossf/scorecard) is an automated security tool that flags risky supply chain practices. You can use the [Scorecards action](https://github.com/marketplace/actions/ossf-scorecard-action) and [starter workflow](https://github.com/actions/starter-workflows) to follow best security practices. Once configured, the Scorecards action runs automatically on repository changes, and alerts developers about risky supply chain practices using the built-in code scanning experience. The Scorecards project runs a number of checks, including script injection attacks, token permissions, and pinned actions.
## Potential impact of a compromised runner
These sections consider some of the steps an attacker can take if they're able to run malicious commands on a {% data variables.product.prodname_actions %} runner.
These sections consider some of the steps an attacker can take if they're able to run malicious commands on a {% data variables.product.prodname_actions %} runner.
### Accessing secrets
Workflows triggered using the `pull_request` event have read-only permissions and have no access to secrets. However, these permissions differ for various event triggers such as `issue_comment`, `issues` and `push`, where the attacker could attempt to steal repository secrets or use the write permission of the job's [`GITHUB_TOKEN`](/actions/reference/authentication-in-a-workflow#permissions-for-the-github_token).
Workflows triggered using the `pull_request` event have read-only permissions and have no access to secrets. However, these permissions differ for various event triggers such as `issue_comment`, `issues` and `push`, where the attacker could attempt to steal repository secrets or use the write permission of the job's [`GITHUB_TOKEN`](/actions/reference/authentication-in-a-workflow#permissions-for-the-github_token).
- If the secret or token is set to an environment variable, it can be directly accessed through the environment using `printenv`.
- If the secret is used directly in an expression, the generated shell script is stored on-disk and is accessible.
@@ -284,11 +292,11 @@ Some customers might attempt to partially mitigate these risks by implementing s
A self-hosted runner can be added to various levels in your {% data variables.product.prodname_dotcom %} hierarchy: the enterprise, organization, or repository level. This placement determines who will be able to manage the runner:
**Centralized management:**
- If you plan to have a centralized team own the self-hosted runners, then the recommendation is to add your runners at the highest mutual organization or enterprise level. This gives your team a single location to view and manage your runners.
- If you plan to have a centralized team own the self-hosted runners, then the recommendation is to add your runners at the highest mutual organization or enterprise level. This gives your team a single location to view and manage your runners.
- If you only have a single organization, then adding your runners at the organization level is effectively the same approach, but you might encounter difficulties if you add another organization in the future.
**Decentralized management:**
- If each team will manage their own self-hosted runners, then the recommendation is to add the runners at the highest level of team ownership. For example, if each team owns their own organization, then it will be simplest if the runners are added at the organization level too.
- If each team will manage their own self-hosted runners, then the recommendation is to add the runners at the highest level of team ownership. For example, if each team owns their own organization, then it will be simplest if the runners are added at the organization level too.
- You could also add runners at the repository level, but this will add management overhead and also increases the numbers of runners you need, since you cannot share runners between repositories.
{% ifversion fpt or ghec or ghae-issue-4856 or ghes > 3.4 %}

View File

@@ -1,6 +1,6 @@
---
title: Installing GitHub Enterprise Server on Azure
intro: 'To install {% data variables.product.prodname_ghe_server %} on Azure, you must deploy onto a DS-series instance and use Premium-LRS storage.'
intro: 'To install {% data variables.product.prodname_ghe_server %} on Azure, you must deploy onto a memory-optimized instance that supports premium storage.'
redirect_from:
- /enterprise/admin/guides/installation/installing-github-enterprise-on-azure
- /enterprise/admin/installation/installing-github-enterprise-server-on-azure
@@ -29,7 +29,8 @@ You can deploy {% data variables.product.prodname_ghe_server %} on global Azure
## Determining the virtual machine type
Before launching {% data variables.product.product_location %} on Azure, you'll need to determine the machine type that best fits the needs of your organization. To review the minimum requirements for {% data variables.product.product_name %}, see "[Minimum requirements](#minimum-requirements)."
Before launching {% data variables.product.product_location %} on Azure, you'll need to determine the machine type that best fits the needs of your organization. For more information about memory optimized machines, see "[Memory optimized virtual machine sizes](https://docs.microsoft.com/en-gb/azure/virtual-machines/sizes-memory)" in the Microsoft Azure documentation. To review the minimum resource requirements for {% data variables.product.product_name %}, see "[Minimum requirements](#minimum-requirements)."
{% data reusables.enterprise_installation.warning-on-scaling %}

View File

@@ -121,17 +121,40 @@ If a policy is enabled for an enterprise, the policy can be selectively disabled
{% data reusables.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.
You can set the default permissions for the `GITHUB_TOKEN` in the settings for your enterprise, organizations, or repositories. If you choose a 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.actions.workflow-permissions-modifying %}
### Configuring the default `GITHUB_TOKEN` permissions
{% if allow-actions-to-approve-pr-with-ent-repo %}
By default, when you create a new enterprise, `GITHUB_TOKEN` only has read access for the `contents` scope.
{% endif %}
{% 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. 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{% if allow-actions-to-approve-pr-with-ent-repo %}-with-pr-approval{% endif %}.png)
1. Click **Save** to apply the settings.
{% if allow-actions-to-approve-pr-with-ent-repo %}
### Preventing {% data variables.product.prodname_actions %} from creating or approving pull requests
{% data reusables.actions.workflow-pr-approval-permissions-intro %}
By default, when you create a new enterprise, workflows are not allowed to create or approve pull requests.
{% data reusables.enterprise-accounts.access-enterprise %}
{% data reusables.enterprise-accounts.policies-tab %}
{% data reusables.enterprise-accounts.actions-tab %}
1. Under "Workflow permissions", use the **Allow GitHub Actions to create and approve pull requests** setting to configure whether `GITHUB_TOKEN` can create and approve pull requests.
![Set GITHUB_TOKEN permissions for this enterprise](/assets/images/help/settings/actions-workflow-permissions-enterprise-with-pr-approval.png)
1. Click **Save** to apply the settings.
{% endif %}
{% endif %}
{% if actions-cache-policy-apis %}

View File

@@ -452,9 +452,9 @@ jobs:
### Enable auto-merge on a pull request
If you want to auto-merge your pull requests, you can use {% data variables.product.prodname_dotcom %}'s auto-merge functionality. This enables the pull request to be merged when all required tests and approvals are successfully met. For more information on auto-merge, see "[Automatically merging a pull request](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request)."
If you want to allow maintainers to mark certain pull requests for auto-merge, you can use {% data variables.product.prodname_dotcom %}'s auto-merge functionality. This enables the pull request to be merged when all required tests and approvals are successfully met. For more information on auto-merge, see "[Automatically merging a pull request](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request)."
Here is an example of enabling auto-merge for all patch updates to `my-dependency`:
You can instead use {% data variables.product.prodname_actions %} and the {% data variables.product.prodname_cli %}. Here is an example that auto merges all patch updates to `my-dependency`:
{% ifversion ghes = 3.3 %}

View File

@@ -52,7 +52,7 @@ Wikis are part of Git repositories, so you can make changes locally and push the
### Cloning wikis to your computer
Every wiki provides an easy way to clone its contents down to your computer.
You can clone the repository to your computer with the provided URL:
Once you've created an initial page on {% data variables.product.product_name %}, you can clone the repository to your computer with the provided URL:
```shell
$ git clone https://github.com/<em>YOUR_USERNAME</em>/<em>YOUR_REPOSITORY</em>.wiki.git

View File

@@ -103,17 +103,40 @@ You can configure this behavior for an organization using the procedure below. M
{% data reusables.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.
You can set the default permissions for the `GITHUB_TOKEN` in the settings for your organization or your repositories. If you select a restrictive option as the default in your organization settings, the same option is 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 a more restrictive default has been selected in the enterprise settings, you won't be able to select the more permissive default in your organization settings.
{% data reusables.actions.workflow-permissions-modifying %}
### Configuring the default `GITHUB_TOKEN` permissions
{% if allow-actions-to-approve-pr-with-ent-repo %}
By default, when you create a new organization, `GITHUB_TOKEN` only has read access for the `contents` scope.
{% endif %}
{% data reusables.profile.access_profile %}
{% data reusables.profile.access_org %}
{% data reusables.profile.org_settings %}
{% data reusables.organizations.settings-sidebar-actions-general %}
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. 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{% if allow-actions-to-approve-pr %}-with-pr-{% if allow-actions-to-approve-pr-with-ent-repo %}creation-{% endif %}approval{% endif %}.png)
1. Click **Save** to apply the settings.
{% if allow-actions-to-approve-pr %}
### Preventing {% data variables.product.prodname_actions %} from {% if allow-actions-to-approve-pr-with-ent-repo %}creating or {% endif %}approving pull requests
{% data reusables.actions.workflow-pr-approval-permissions-intro %}
By default, when you create a new organization, workflows are not allowed to {% if allow-actions-to-approve-pr-with-ent-repo %}create or {% endif %}approve pull requests.
{% data reusables.profile.access_profile %}
{% data reusables.profile.access_org %}
{% data reusables.profile.org_settings %}
{% data reusables.organizations.settings-sidebar-actions-general %}
1. Under "Workflow permissions", use the **Allow GitHub Actions to {% if allow-actions-to-approve-pr-with-ent-repo %}create and {% endif %}approve pull requests** setting to configure whether `GITHUB_TOKEN` can {% if allow-actions-to-approve-pr-with-ent-repo %}create and {% endif %}approve pull requests.
![Set GITHUB_TOKEN pull request approval permission for this organization](/assets/images/help/settings/actions-workflow-permissions-organization{% if allow-actions-to-approve-pr %}-with-pr-{% if allow-actions-to-approve-pr-with-ent-repo %}creation-{% endif %}approval{% endif %}.png)
1. Click **Save** to apply the settings.
{% endif %}
{% endif %}

View File

@@ -106,20 +106,40 @@ If a policy is disabled for an {% ifversion ghec or ghae or ghes %}enterprise or
{% data reusables.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.
The default permissions can also be configured in the organization settings. If your repository belongs to an organization and a more restrictive default has been selected in the organization settings, the same option is selected in your repository settings and the permissive option is disabled.
{% data reusables.actions.workflow-permissions-modifying %}
### Configuring the default `GITHUB_TOKEN` permissions
{% if allow-actions-to-approve-pr-with-ent-repo %}
By default, when you create a new repository in your personal account, `GITHUB_TOKEN` only has read access for the `contents` scope. If you create a new repository in an organization, the setting is inherited from what is configured in the organization settings.
{% endif %}
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-settings %}
{% data reusables.repositories.settings-sidebar-actions-general %}
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.
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)
![Set GITHUB_TOKEN permissions for this repository](/assets/images/help/settings/actions-workflow-permissions-repository{% if allow-actions-to-approve-pr-with-ent-repo %}-with-pr-approval{% endif %}.png)
1. Click **Save** to apply the settings.
{% if allow-actions-to-approve-pr-with-ent-repo %}
### Preventing {% data variables.product.prodname_actions %} from creating or approving pull requests
{% data reusables.actions.workflow-pr-approval-permissions-intro %}
By default, when you create a new repository in your personal account, workflows are not allowed to create or approve pull requests. If you create a new repository in an organization, the setting is inherited from what is configured in the organization settings.
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-settings %}
{% data reusables.repositories.settings-sidebar-actions-general %}
1. Under "Workflow permissions", use the **Allow GitHub Actions to create and approve pull requests** setting to configure whether `GITHUB_TOKEN` can create and approve pull requests.
![Set GITHUB_TOKEN permissions for this repository](/assets/images/help/settings/actions-workflow-permissions-repository-with-pr-approval.png)
1. Click **Save** to apply the settings.
{% endif %}
{% endif %}
{% ifversion ghes > 3.3 or ghae-issue-4757 or ghec %}
@@ -133,9 +153,9 @@ You can use the steps below to configure whether {% if internal-actions%}actions
1. Under your repository name, click {% octicon "gear" aria-label="The gear icon" %} **Settings**.
{% data reusables.repositories.settings-sidebar-actions-general %}
1. Under **Access**, choose one of the access settings:
{% ifversion ghes > 3.4 or ghae-issue-6090 or ghec %}![Set the access to Actions components](/assets/images/help/settings/actions-access-settings.png){% else %}![Set the access to Actions components](/assets/images/enterprise/3.4/actions-access-settings.png){% endif %}
* **Not accessible** - Workflows in other repositories cannot access this repository.
* **Accessible from repositories in the 'ORGANIZATION NAME' organization** - {% ifversion ghes > 3.4 or ghae-issue-6090 or ghec %}Workflows in other repositories that are part of the 'ORGANIZATION NAME' organization can access the actions and workflows in this repository. Access is allowed only from private or internal repositories.{% else %}Workflows in other repositories can use workflows in this repository if they are part of the same organization and their visibility is private or internal.{% endif %}
* **Accessible from repositories in the 'ENTERPRISE NAME' enterprise** - {% ifversion ghes > 3.4 or ghae-issue-6090 or ghec %}Workflows in other repositories that are part of the 'ENTERPRISE NAME' enterprise can access the actions and workflows in this repository. Access is allowed only from private or internal repositories.{% else %}Workflows in other repositories can use workflows in this repository if they are part of the same enterprise and their visibility is private or internal.{% endif %}

View File

@@ -0,0 +1,7 @@
# Reference: #6926.
# Versioning for enterprise/repository policy settings for workflow PR creation or approval permission. This is only the enterprise and repo settings! For the previous separate ship for the org setting (that only overed approvals), see the allow-actions-to-approve-pr flag.
versions:
fpt: '*'
ghec: '*'
ghes: '>=3.6'
ghae: 'issue-6926'

View File

@@ -0,0 +1,7 @@
# Reference: #6926.
# Versioning for org policy settings for workflow PR approval permission. This is only org setting! For the later separate ship for the enterprise and repo setting, see the allow-actions-to-approve-pr-with-ent-repo flag.
versions:
fpt: '*'
ghec: '*'
ghes: '>=3.5'
ghae: 'issue-6926'

View File

@@ -51,7 +51,7 @@ sections:
notes:
# https://github.com/github/releases/issues/2183
- |
You can now analyze how your team works, understand the value you get from GitHub Enterprise Server, and help us improve our products by reviewing your instance's usage data and sharing this aggregate data with GitHub. You can use your own tools to analyze your usage over time by downloading your data in a CSV or JSON file or by accessing it using the REST API. To see the list of aggregate metrics collected, see "[About Server Statistics](/admin/monitoring-activity-in-your-enterprise/analyzing-how-your-team-works-with-server-statistics/about-server-statistics#server-statistics-data-collected)." **Server Statistics data includes no personal data nor GitHub content, such as code, issues, comments, or pull requests content. For a better understanding of how we store and secure Server Statistics data, see "[GitHub Security](https://github.com/security)."** For more information about Server Statistics, see "[Analyzing how your team works with Server Statistics](/admin/monitoring-activity-in-your-enterprise/analyzing-how-your-team-works-with-server-statistics)." This feature is available in public beta.
You can now analyze how your team works, understand the value you get from GitHub Enterprise Server, and help us improve our products by reviewing your instance's usage data and sharing this aggregate data with GitHub. You can use your own tools to analyze your usage over time by downloading your data in a CSV or JSON file or by accessing it using the REST API. To see the list of aggregate metrics collected, see "[About Server Statistics](/admin/monitoring-activity-in-your-enterprise/analyzing-how-your-team-works-with-server-statistics/about-server-statistics#server-statistics-data-collected)." Server Statistics data includes no personal data nor GitHub content, such as code, issues, comments, or pull requests content. For a better understanding of how we store and secure Server Statistics data, see "[GitHub Security](https://github.com/security)." For more information about Server Statistics, see "[Analyzing how your team works with Server Statistics](/admin/monitoring-activity-in-your-enterprise/analyzing-how-your-team-works-with-server-statistics)." This feature is available in public beta.
- heading: GitHub Actions rate limiting is now configurable
notes:

View File

@@ -1 +1 @@
You can set the default permissions granted to the `GITHUB_TOKEN`. For more information about the `GITHUB_TOKEN`, see "[Automatic token authentication](/actions/security-guides/automatic-token-authentication)." You can choose between a restricted set of permissions as the default or a permissive setting.
You can set the default permissions granted to the `GITHUB_TOKEN`. For more information about the `GITHUB_TOKEN`, see "[Automatic token authentication](/actions/security-guides/automatic-token-authentication)." You can choose a restricted set of permissions as the default, or apply permissive settings.

View File

@@ -0,0 +1 @@
You can choose to allow or prevent {% data variables.product.prodname_actions %} workflows from{% if allow-actions-to-approve-pr-with-ent-repo %} creating or{% endif %} approving pull requests.

View File

@@ -28575,12 +28575,25 @@
}
}
],
"bodyParameters": [],
"bodyParameters": [
{
"type": "boolean",
"default": false,
"description": "<p>Whether to enable debug logging for the re-run.</p>",
"name": "enable_debug_logging",
"in": "body",
"rawType": "boolean",
"rawDescription": "Whether to enable debug logging for the re-run.",
"isRequired": false,
"childParamsGroups": []
}
],
"enabledForGitHubApps": true,
"codeExamples": [
{
"key": "default",
"request": {
"contentType": "application/json",
"description": "Example",
"acceptHeader": "application/vnd.github.v3+json",
"parameters": {
@@ -46586,12 +46599,25 @@
}
}
],
"bodyParameters": [],
"bodyParameters": [
{
"type": "boolean",
"default": false,
"description": "<p>Whether to enable debug logging for the re-run.</p>",
"name": "enable_debug_logging",
"in": "body",
"rawType": "boolean",
"rawDescription": "Whether to enable debug logging for the re-run.",
"isRequired": false,
"childParamsGroups": []
}
],
"enabledForGitHubApps": false,
"codeExamples": [
{
"key": "default",
"request": {
"contentType": "application/json",
"description": "Example",
"acceptHeader": "application/vnd.github.v3+json",
"parameters": {
@@ -46651,12 +46677,25 @@
}
}
],
"bodyParameters": [],
"bodyParameters": [
{
"type": "boolean",
"default": false,
"description": "<p>Whether to enable debug logging for the re-run.</p>",
"name": "enable_debug_logging",
"in": "body",
"rawType": "boolean",
"rawDescription": "Whether to enable debug logging for the re-run.",
"isRequired": false,
"childParamsGroups": []
}
],
"enabledForGitHubApps": true,
"codeExamples": [
{
"key": "default",
"request": {
"contentType": "application/json",
"description": "Example",
"acceptHeader": "application/vnd.github.v3+json",
"parameters": {

View File

@@ -33826,6 +33826,7 @@
{
"key": "default",
"request": {
"contentType": "application/json",
"description": "Example",
"acceptHeader": "application/vnd.github.v3+json",
"parameters": {

View File

@@ -36261,6 +36261,7 @@
{
"key": "default",
"request": {
"contentType": "application/json",
"description": "Example",
"acceptHeader": "application/vnd.github.v3+json",
"parameters": {

View File

@@ -36398,6 +36398,7 @@
{
"key": "default",
"request": {
"contentType": "application/json",
"description": "Example",
"acceptHeader": "application/vnd.github.v3+json",
"parameters": {

View File

@@ -38531,6 +38531,7 @@
{
"key": "default",
"request": {
"contentType": "application/json",
"description": "Example",
"acceptHeader": "application/vnd.github.v3+json",
"parameters": {

View File

@@ -28544,6 +28544,7 @@
{
"key": "default",
"request": {
"contentType": "application/json",
"description": "Example",
"acceptHeader": "application/vnd.github.v3+json",
"parameters": {
@@ -46482,6 +46483,7 @@
{
"key": "default",
"request": {
"contentType": "application/json",
"description": "Example",
"acceptHeader": "application/vnd.github.v3+json",
"parameters": {
@@ -46547,6 +46549,7 @@
{
"key": "default",
"request": {
"contentType": "application/json",
"description": "Example",
"acceptHeader": "application/vnd.github.v3+json",
"parameters": {

View File

@@ -37292,6 +37292,7 @@
{
"key": "default",
"request": {
"contentType": "application/json",
"description": "Example",
"acceptHeader": "application/vnd.github.v3+json",
"parameters": {

View File

@@ -161875,6 +161875,26 @@
}
}
],
"requestBody": {
"required": false,
"content": {
"application/json": {
"schema": {
"type": [
"object",
"null"
],
"properties": {
"enable_debug_logging": {
"type": "boolean",
"default": false,
"description": "Whether to enable debug logging for the re-run."
}
}
}
}
}
},
"responses": {
"201": {
"description": "Response",
@@ -186268,6 +186288,26 @@
}
}
],
"requestBody": {
"required": false,
"content": {
"application/json": {
"schema": {
"type": [
"object",
"null"
],
"properties": {
"enable_debug_logging": {
"type": "boolean",
"default": false,
"description": "Whether to enable debug logging for the re-run."
}
}
}
}
}
},
"responses": {
"201": {
"description": "Response",
@@ -186286,11 +186326,9 @@
"x-github": {
"githubCloudOnly": false,
"enabledForGitHubApps": false,
"deprecationDate": "2021-09-14",
"category": "actions",
"subcategory": "workflow-runs"
},
"deprecated": true
}
}
},
"/repos/{owner}/{repo}/actions/runs/{run_id}/rerun-failed-jobs": {
@@ -186334,6 +186372,26 @@
}
}
],
"requestBody": {
"required": false,
"content": {
"application/json": {
"schema": {
"type": [
"object",
"null"
],
"properties": {
"enable_debug_logging": {
"type": "boolean",
"default": false,
"description": "Whether to enable debug logging for the re-run."
}
}
}
}
}
},
"responses": {
"201": {
"description": "Response",

View File

@@ -146367,6 +146367,19 @@
}
}
],
"requestBody": {
"required": false,
"content": {
"application/json": {
"schema": {
"type": [
"object",
"null"
]
}
}
}
},
"responses": {
"201": {
"description": "Response",
@@ -146385,11 +146398,9 @@
"x-github": {
"githubCloudOnly": false,
"enabledForGitHubApps": false,
"deprecationDate": "2021-09-14",
"category": "actions",
"subcategory": "workflow-runs"
},
"deprecated": true
}
}
},
"/repos/{owner}/{repo}/actions/secrets": {

View File

@@ -150684,6 +150684,19 @@
}
}
],
"requestBody": {
"required": false,
"content": {
"application/json": {
"schema": {
"type": [
"object",
"null"
]
}
}
}
},
"responses": {
"201": {
"description": "Response",
@@ -150702,11 +150715,9 @@
"x-github": {
"githubCloudOnly": false,
"enabledForGitHubApps": false,
"deprecationDate": "2021-09-14",
"category": "actions",
"subcategory": "workflow-runs"
},
"deprecated": true
}
}
},
"/repos/{owner}/{repo}/actions/secrets": {

View File

@@ -153644,6 +153644,19 @@
}
}
],
"requestBody": {
"required": false,
"content": {
"application/json": {
"schema": {
"type": [
"object",
"null"
]
}
}
}
},
"responses": {
"201": {
"description": "Response",
@@ -153662,11 +153675,9 @@
"x-github": {
"githubCloudOnly": false,
"enabledForGitHubApps": false,
"deprecationDate": "2021-09-14",
"category": "actions",
"subcategory": "workflow-runs"
},
"deprecated": true
}
}
},
"/repos/{owner}/{repo}/actions/secrets": {

View File

@@ -166570,6 +166570,19 @@
}
}
],
"requestBody": {
"required": false,
"content": {
"application/json": {
"schema": {
"type": [
"object",
"null"
]
}
}
}
},
"responses": {
"201": {
"description": "Response",
@@ -166588,11 +166601,9 @@
"x-github": {
"githubCloudOnly": false,
"enabledForGitHubApps": false,
"deprecationDate": "2021-09-14",
"category": "actions",
"subcategory": "workflow-runs"
},
"deprecated": true
}
}
},
"/repos/{owner}/{repo}/actions/secrets": {

View File

@@ -153682,6 +153682,19 @@
}
}
],
"requestBody": {
"required": false,
"content": {
"application/json": {
"schema": {
"type": [
"object",
"null"
]
}
}
}
},
"responses": {
"201": {
"description": "Response",
@@ -177809,6 +177822,19 @@
}
}
],
"requestBody": {
"required": false,
"content": {
"application/json": {
"schema": {
"type": [
"object",
"null"
]
}
}
}
},
"responses": {
"201": {
"description": "Response",
@@ -177827,11 +177853,9 @@
"x-github": {
"githubCloudOnly": false,
"enabledForGitHubApps": false,
"deprecationDate": "2021-09-14",
"category": "actions",
"subcategory": "workflow-runs"
},
"deprecated": true
}
}
},
"/repos/{owner}/{repo}/actions/runs/{run_id}/rerun-failed-jobs": {
@@ -177875,6 +177899,19 @@
}
}
],
"requestBody": {
"required": false,
"content": {
"application/json": {
"schema": {
"type": [
"object",
"null"
]
}
}
}
},
"responses": {
"201": {
"description": "Response",

View File

@@ -132740,6 +132740,19 @@
}
}
],
"requestBody": {
"required": false,
"content": {
"application/json": {
"schema": {
"type": [
"object",
"null"
]
}
}
}
},
"responses": {
"201": {
"description": "Response",
@@ -132758,11 +132771,9 @@
"x-github": {
"githubCloudOnly": false,
"enabledForGitHubApps": false,
"deprecationDate": "2021-09-14",
"category": "actions",
"subcategory": "workflow-runs"
},
"deprecated": true
}
}
},
"/repos/{owner}/{repo}/actions/runs/{run_id}/timing": {