Octomerger Bot
@@ -12,6 +12,12 @@ shortTitle: Skip workflow runs
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** If a workflow is skipped due to [path filtering](/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore), [branch filtering](/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore) or a commit message (see below), then checks associated with that workflow will remain in a "Pending" state. A pull request that requires those checks to be successful will be blocked from merging.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
Workflows that would otherwise be triggered using `on: push` or `on: pull_request` won't be triggered if you add any of the following strings to the commit message in a push, or the HEAD commit of a pull request:
|
||||
|
||||
* `[skip ci]`
|
||||
|
||||
@@ -201,6 +201,14 @@ 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.
|
||||
|
||||
@@ -15,4 +15,14 @@ miniTocMaxHeadingLevel: 4
|
||||
|
||||
## 概要
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** A job that is skipped will report its status as "Success". It will not prevent a pull request from merging, even if it is a required check.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{% data reusables.actions.jobs.section-using-conditions-to-control-job-execution %}
|
||||
|
||||
You would see the following status on a skipped job:
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Azure で GitHub Enterprise Server をインストールする
|
||||
intro: 'Azure に {% data variables.product.prodname_ghe_server %} をインストールするには、DS シリーズのインスタンスにデプロイし、Premium-LRS ストレージを使用する必要があります。'
|
||||
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
|
||||
@@ -30,7 +30,8 @@ shortTitle: Install on Azure
|
||||
|
||||
## 仮想マシンタイプの決定
|
||||
|
||||
Azure で{% data variables.product.product_location %} を起動する前に、Organization のニーズに最適なマシンタイプを決定する必要があります。 {% data variables.product.product_name %} の最小要件を確認するには、「[最小要件](#minimum-requirements)」を参照してください。
|
||||
Azure で{% data variables.product.product_location %} を起動する前に、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 %}
|
||||
|
||||
|
||||
@@ -121,16 +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 %}
|
||||
|
||||
### デフォルトの`GITHUB_TOKEN`権限の設定
|
||||
|
||||
{% 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. [**Workflow permissions**]の下で、`GITHUB_TOKEN`にすべてのスコープに対する読み書きアクセスを持たせたいか、あるいは`contents`スコープに対する読み取りアクセスだけを持たせたいかを選択してください。 
|
||||
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. **Save（保存）**をクリックして、設定を適用してください。
|
||||
|
||||
{% 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.
|
||||
|
||||
|
||||
1. **Save（保存）**をクリックして、設定を適用してください。
|
||||
|
||||
{% endif %}
|
||||
{% endif %}
|
||||
|
||||
{% if actions-cache-policy-apis %}
|
||||
|
||||
@@ -16,15 +16,15 @@ shortTitle: Azureサブスクリプションの接続
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** If your enterprise account is on a Microsoft Enterprise Agreement, connecting an Azure subscription is the only way to use {% data variables.product.prodname_actions %} and {% data variables.product.prodname_registry %} beyond the included amounts, or to use {% data variables.product.prodname_codespaces %} at all.
|
||||
**ノート:** EnterpriseアカウントがMicrosoft Enterprise Agreement上にあるなら、含まれている量を超えて{% data variables.product.prodname_actions %}及び{% data variables.product.prodname_registry %}を使う、あるいは{% data variables.product.prodname_codespaces %}を使う唯一の方法は、Azureサブスクリプションに接続することです。
|
||||
|
||||
{% endnote %}
|
||||
|
||||
After you connect an Azure subscription, you can also manage your spending limits.
|
||||
Azure サブスクリプションに接続した後、利用上限を管理することもできます。
|
||||
|
||||
- "[Managing your spending limit for {% data variables.product.prodname_registry %}](/billing/managing-billing-for-github-packages/managing-your-spending-limit-for-github-packages)"
|
||||
- "[Managing your spending limit for {% data variables.product.prodname_actions %}](/billing/managing-billing-for-github-actions/managing-your-spending-limit-for-github-actions)"
|
||||
- "[Managing your spending limit for {% data variables.product.prodname_codespaces %}](/billing/managing-billing-for-github-codespaces/managing-spending-limits-for-codespaces)"
|
||||
- 「[{% data variables.product.prodname_registry %}の利用上限の管理](/billing/managing-billing-for-github-packages/managing-your-spending-limit-for-github-packages)」
|
||||
- 「[{% data variables.product.prodname_actions %}の利用上限の管理](/billing/managing-billing-for-github-actions/managing-your-spending-limit-for-github-actions)」
|
||||
- 「[{% data variables.product.prodname_codespaces %}の利用上限の管理](/billing/managing-billing-for-github-codespaces/managing-spending-limits-for-codespaces)」
|
||||
|
||||
## Azure サブスクリプションを Enterprise アカウントに接続する
|
||||
|
||||
|
||||
@@ -98,7 +98,7 @@ topics:
|
||||
|
||||
ワークフローでエラー `No source code was seen during the build` または `The process '/opt/hostedtoolcache/CodeQL/0.0.0-20200630/x64/codeql/codeql' failed with exit code 32` が発生した場合、{% data variables.product.prodname_codeql %} がコードを監視できなかったことを示しています。 このようなエラーが発生する理由として、次のようなものがあります。
|
||||
|
||||
1. The repository may not contain source code that is written in languages supported by {% data variables.product.prodname_codeql %}. Check the list of supported languages and, if this is the case, remove the {% data variables.product.prodname_codeql %} workflow. For more information, see "[About code scanning with CodeQL](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning-with-codeql#about-codeql)
|
||||
1. リポジトリには、{% data variables.product.prodname_codeql %}にサポートされている言語で書かれたソースコードは含まれていないかもしれません。 サポートされている言語のリストを確認し、{% data variables.product.prodname_codeql %}ワークフローを削除してください。 詳しい情報については「[CodeQLでのコードスキャンニングについて](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning-with-codeql#about-codeql)」を参照してください。
|
||||
|
||||
1. 自動言語検出により、サポートされている言語が特定されたが、リポジトリにその言語の分析可能なコードがない。 一般的な例としては、言語検出サービスが `.h` や `.gyp` ファイルなどの特定のプログラミング言語に関連付けられたファイルを見つけたが、対応する実行可能コードがリポジトリに存在しない場合です。 この問題を解決するには、`language` マトリクスにある言語のリストを更新し、解析する言語を手動で定義します。 たとえば、次の設定では Go と JavaScript のみを分析します。
|
||||
|
||||
|
||||
@@ -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 %}
|
||||
|
||||
|
||||
@@ -44,7 +44,7 @@ shortTitle: Wikiページの管理
|
||||
|
||||
### 手元のコンピュータへウィキをクローンする
|
||||
|
||||
すべてのウィキは、その内容をあなたのコンピュータにクローンする簡単な方法を提供しています。 提供されている次の 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
|
||||
|
||||
@@ -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.
|
||||
|
||||
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. 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.
|
||||
|
||||
|
||||
1. Click **Save** to apply the settings.
|
||||
|
||||
{% endif %}
|
||||
{% endif %}
|
||||
|
||||
@@ -48,13 +48,17 @@ remote: error: Required status check "ci-build" is failing
|
||||
|
||||
## Handling skipped but required checks
|
||||
|
||||
Sometimes a required status check is skipped on pull requests due to path filtering. For example, a Node.JS test will be skipped on a pull request that just fixes a typo in your README file and makes no changes to the JavaScript and TypeScript files in the `scripts` directory.
|
||||
{% note %}
|
||||
|
||||
If this check is required and it gets skipped, then the check's status is shown as pending, because it's required. In this situation you won't be able to merge the pull request.
|
||||
**Note:** If a workflow is skipped due to [path filtering](/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore), [branch filtering](/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore) or a [commit message](/actions/managing-workflow-runs/skipping-workflow-runs), then checks associated with that workflow will remain in a "Pending" state. A pull request that requires those checks to be successful will be blocked from merging.
|
||||
|
||||
If a job in a workflow is skipped due to a conditional, it will report its status as "Success". For more information see [Skipping workflow runs](/actions/managing-workflow-runs/skipping-workflow-runs) and [Using conditions to control job execution](/actions/using-jobs/using-conditions-to-control-job-execution).
|
||||
|
||||
{% endnote %}
|
||||
|
||||
### サンプル
|
||||
|
||||
In this example you have a workflow that's required to pass.
|
||||
The following example shows a workflow that requires a "Successful" completion status for the `build` job, but the workflow will be skipped if the pull request does not change any files in the `scripts` directory.
|
||||
|
||||
```yaml
|
||||
name: ci
|
||||
@@ -62,7 +66,6 @@ on:
|
||||
pull_request:
|
||||
paths:
|
||||
- 'scripts/**'
|
||||
- 'middleware/**'
|
||||
jobs:
|
||||
build:
|
||||
runs-on: ubuntu-latest
|
||||
@@ -81,7 +84,7 @@ jobs:
|
||||
- run: npm test
|
||||
```
|
||||
|
||||
If someone submits a pull request that changes a markdown file in the root of the repository, then the workflow above won't run at all because of the path filtering. As a result you won't be able to merge the pull request. You would see the following status on the pull request:
|
||||
Due to [path filtering](/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore), a pull request that only changes a file in the root of the repository will not trigger this workflow and is blocked from merging. You would see the following status on the pull request:
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -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 %}
|
||||
|
||||
### デフォルトの`GITHUB_TOKEN`権限の設定
|
||||
|
||||
{% 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. [**Workflow permissions**]の下で、`GITHUB_TOKEN`にすべてのスコープに対する読み書きアクセスを持たせたいか、あるいは`contents`スコープに対する読み取りアクセスだけを持たせたいかを選択してください。
|
||||
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. **Save（保存）**をクリックして、設定を適用してください。
|
||||
|
||||
{% 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.
|
||||
|
||||
|
||||
1. **Save（保存）**をクリックして、設定を適用してください。
|
||||
{% endif %}
|
||||
{% endif %}
|
||||
|
||||
{% ifversion ghes > 3.3 or ghae-issue-4757 or ghec %}
|
||||
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
#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'
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
#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'
|
||||
@@ -46,7 +46,7 @@ sections:
|
||||
heading: Server Statistics in public beta
|
||||
notes:
|
||||
- |
|
||||
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:
|
||||
|
||||
@@ -1 +1 @@
|
||||
`GITHUB_TOKEN`に付与されるデフォルトの権限を設定できます。 For more information about the `GITHUB_TOKEN`, see "[Automatic token authentication](/actions/security-guides/automatic-token-authentication)." デフォルトとして制限された権限セットか、より幅広く許可をする設定を選択できます。
|
||||
`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.
|
||||
|
||||
@@ -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.
|
||||
@@ -51,7 +51,7 @@ If you define a branch with the `!` character, you must also define at least one
|
||||
- 肯定のマッチングパターンの後に否定のマッチングパターン ("`!`" のプレフィクス) を定義すると、Git ref を除外します。
|
||||
- 否定のマッチングパターンの後に肯定のマッチングパターンを定義すると、Git ref を再び含めます。
|
||||
|
||||
The following workflow will run on `pull_request` events for pull requests that target `releases/10` or `releases/beta/mona`, but for pull requests that target `releases/10-alpha` or `releases/beta/3-alpha` because the negative pattern `!releases/**-alpha` follows the positive pattern.
|
||||
The following workflow will run on `pull_request` events for pull requests that target `releases/10` or `releases/beta/mona`, but not for pull requests that target `releases/10-alpha` or `releases/beta/3-alpha` because the negative pattern `!releases/**-alpha` follows the positive pattern.
|
||||
|
||||
```yaml
|
||||
on:
|
||||
|
||||
@@ -20,7 +20,7 @@ on:
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** If a workflow is skipped due to path filtering, but the workflow is set as a required check, then the check will remain as "Pending". To work around this, you can create a corresponding workflow with the same name that always passes whenever the original workflow is skipped because of path filtering. For more information, see "[Handling skipped but required checks](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/troubleshooting-required-status-checks#handling-skipped-but-required-checks)."
|
||||
**Note:** If a workflow is skipped due to [path filtering](/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore), [branch filtering](/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore) or a [commit message](/actions/managing-workflow-runs/skipping-workflow-runs), then checks associated with that workflow will remain in a "Pending" state. A pull request that requires those checks to be successful will be blocked from merging. For more information, see "[Handling skipped but required checks](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/troubleshooting-required-status-checks#handling-skipped-but-required-checks)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
|
||||
@@ -22,6 +22,10 @@
|
||||
| Contributed Systems | Contributed Systems Credentials |
|
||||
| Databricks | Databricks Access Token |
|
||||
| Datadog | Datadog API Key |
|
||||
| DigitalOcean | DigitalOcean Personal Access Token |
|
||||
| DigitalOcean | DigitalOcean OAuth Token |
|
||||
| DigitalOcean | DigitalOcean Refresh Token |
|
||||
| DigitalOcean | DigitalOcean System Token |
|
||||
| Discord | Discord Bot Token |
|
||||
| Doppler | Doppler Personal Token |
|
||||
| Doppler | Doppler Service Token |
|
||||
|
||||
@@ -84,6 +84,7 @@ translations/zh-CN/content/admin/identity-and-access-management/using-saml-for-e
|
||||
translations/zh-CN/content/admin/identity-and-access-management/using-saml-for-enterprise-iam/index.md,broken liquid tags
|
||||
translations/zh-CN/content/admin/index.md,broken liquid tags
|
||||
translations/zh-CN/content/admin/installation/setting-up-a-github-enterprise-server-instance/installing-github-enterprise-server-on-aws.md,broken liquid tags
|
||||
translations/zh-CN/content/admin/monitoring-activity-in-your-enterprise/analyzing-how-your-team-works-with-server-statistics/requesting-server-statistics-using-the-rest-api.md,broken liquid tags
|
||||
translations/zh-CN/content/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/audit-log-events-for-your-enterprise.md,broken liquid tags
|
||||
translations/zh-CN/content/admin/overview/about-enterprise-accounts.md,Listed in localization-support#489
|
||||
translations/zh-CN/content/admin/overview/about-enterprise-accounts.md,rendering error
|
||||
|
||||
|
@@ -12,6 +12,12 @@ shortTitle: 跳过工作流程运行
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** If a workflow is skipped due to [path filtering](/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore), [branch filtering](/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore) or a commit message (see below), then checks associated with that workflow will remain in a "Pending" state. A pull request that requires those checks to be successful will be blocked from merging.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
本来会触发使用 `on: push` 或 `on: pull_request` 的工作流程，如果您将以下任何字符串添加到推送中的提交消息或者拉取请求的 HEAD 提交，则不会触发：
|
||||
|
||||
* `[skip ci]`
|
||||
|
||||
@@ -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 %}
|
||||
|
||||
@@ -15,4 +15,14 @@ miniTocMaxHeadingLevel: 4
|
||||
|
||||
## 概览
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** A job that is skipped will report its status as "Success". It will not prevent a pull request from merging, even if it is a required check.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{% data reusables.actions.jobs.section-using-conditions-to-control-job-execution %}
|
||||
|
||||
You would see the following status on a skipped job:
|
||||
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ redirect_from:
|
||||
- /early-access/github/analyze-how-your-team-works-with-server-statistics/about-server-statistics/enabling-server-statistics
|
||||
topics:
|
||||
- Enterprise
|
||||
shortTitle: Server Statistics
|
||||
shortTitle: 服务器统计信息
|
||||
---
|
||||
|
||||
{% data reusables.server-statistics.release-phase %}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: 在 Azure 上安装 GitHub Enterprise Server
|
||||
intro: '要在 Azure 上安装 {% data variables.product.prodname_ghe_server %}，您必须部署到 DS 系列实例上并使用 Premium-LRS 存储。'
|
||||
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
|
||||
@@ -30,7 +30,8 @@ shortTitle: 在 Azure 上安装
|
||||
|
||||
## 确定虚拟机类型
|
||||
|
||||
在 Azure 上启动 {% data variables.product.product_location %} 之前，您需要确定最符合您的组织需求的设备类型。 要查看 {% data variables.product.product_name %} 的最低要求，请参阅“[最低要求](#minimum-requirements)”。
|
||||
在 Azure 上启动 {% data variables.product.product_location %} 之前，您需要确定最符合您的组织需求的设备类型。 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 %}
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@ redirect_from:
|
||||
|
||||
{% data reusables.server-statistics.release-phase %}
|
||||
|
||||
You can download up to the last 365 days of {% data variables.product.prodname_server_statistics %} data in a CSV or JSON file. This data, which includes aggregate metrics on repositories, issues, and pull requests, can help you anticipate the needs of your organization, understand how your team works, and show the value you get from {% data variables.product.prodname_ghe_server %}.
|
||||
You can download up to the last 365 days of {% data variables.product.prodname_server_statistics %} data in a CSV or JSON file. 此数据（包括有关存储库、问题和拉取请求的汇总指标）可以帮助您预测组织的需求，了解团队的工作方式，并显示您从 {% data variables.product.prodname_ghe_server %} 中获得的价值。
|
||||
|
||||
Before you can download this data, you must enable {% data variables.product.prodname_server_statistics %}. 更多信息请参阅“[为企业启用 {% data variables.product.prodname_server_statistics %}](/admin/configuration/configuring-github-connect/enabling-server-statistics-for-your-enterprise)”。
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Analyzing how your team works with Server Statistics
|
||||
shortTitle: Server Statistics
|
||||
intro: 'To analyze how your team works, understand the value you get from {% data variables.product.prodname_ghe_server %}, and help us improve our products, you can use {% data variables.product.prodname_server_statistics %} to review your usage data for {% data variables.product.prodname_ghe_server %} and share this aggregate data with {% data variables.product.company_short %}.'
|
||||
title: 分析团队如何使用服务器统计信息
|
||||
shortTitle: 服务器统计信息
|
||||
intro: '要分析您的团队的工作方式，了解您从 {% data variables.product.prodname_ghe_server %}中获得的价值，并帮助我们改进我们的产品，您可以使用 {% data variables.product.prodname_server_statistics %} 来查看 {% data variables.product.prodname_ghe_server %} 的使用数据，并与 {% data variables.product.company_short %} 共享此汇总数据。'
|
||||
versions:
|
||||
feature: server-statistics
|
||||
children:
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Requesting Server Statistics using the REST API
|
||||
shortTitle: Server Statistics and REST API
|
||||
intro: 'You can use your own tools to analyze your {% data variables.product.prodname_ghe_server %} usage over time by requesting the {% data variables.product.prodname_server_statistics %} metrics collected using the REST API.'
|
||||
versions:
|
||||
feature: server-statistics
|
||||
feature: 'server-statistics'
|
||||
redirect_from:
|
||||
- /early-access/github/analyze-how-your-team-works-with-server-statistics/requesting-server-statistics-using-the-rest-api
|
||||
---
|
||||
@@ -12,6 +12,6 @@ redirect_from:
|
||||
|
||||
You can request up to 365 days of metrics in a single {% data variables.product.prodname_server_statistics %} REST API request. This data, which includes aggregate metrics on repositories, issues, and pull requests, can help you anticipate the needs of your organization, understand how your team works, and show the value you get from {% data variables.product.prodname_ghe_server %}. For a list of the metrics collected, see "[{% data variables.product.prodname_server_statistics %} data collected](/admin/monitoring-activity-in-your-enterprise/analyzing-how-your-team-works-with-server-statistics/about-server-statistics#server-statistics-data-collected)."
|
||||
|
||||
Before you can use the {% data variables.product.prodname_server_statistics %} REST API, you must enable {% data variables.product.prodname_server_statistics %}. 更多信息请参阅“[为企业启用 {% data variables.product.prodname_server_statistics %}](/admin/configuration/configuring-github-connect/enabling-server-statistics-for-your-enterprise)”。
|
||||
Before you can use the {% data variables.product.prodname_server_statistics %} REST API, you must enable {% data variables.product.prodname_server_statistics %}. For more information, see "[Enabling {% data variables.product.prodname_server_statistics %} for your enterprise](/admin/configuration/configuring-github-connect/enabling-server-statistics-for-your-enterprise)."
|
||||
|
||||
For more information about using the REST API to request server statistics, see "[Get {% data variables.product.prodname_ghe_server %} statistics](/enterprise-cloud@latest/rest/enterprise-admin/admin-stats#get-github-enterprise-server-statistics)" in the {% data variables.product.prodname_ghe_cloud %} REST API documentation.
|
||||
|
||||
@@ -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.
|
||||
|
||||
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. 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.
|
||||
|
||||
|
||||
1. Click **Save** to apply the settings.
|
||||
|
||||
{% endif %}
|
||||
{% endif %}
|
||||
|
||||
{% if actions-cache-policy-apis %}
|
||||
|
||||
@@ -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 %}
|
||||
|
||||
|
||||
@@ -143,8 +143,8 @@ aAAAe9
|
||||
|
||||
{% if secret-scanning-enterprise-dry-runs %}
|
||||
**注意：**
|
||||
- At the enterprise level, only the creator of a custom pattern can edit the pattern, and use it in a dry run.
|
||||
- Enterprise owners can only make use of dry runs on repositories that they have access to, and enterprise owners do not necessarily have access to all the organizations or repositories within the enterprise.
|
||||
- 在企业级别，只有自定义模式的创建者才能编辑该模式，并在试运行中使用它。
|
||||
- 企业所有者只能使用他们有权访问的存储库上的试运行，而企业所有者不一定有权访问企业内的所有组织或存储库。
|
||||
{% else %}
|
||||
**注意：** 由于没有试运行功能，我们建议您先在存储库中测试自定义模式，然后再为整个企业定义它们。 这样，可以避免创建过多的误报 {% data variables.product.prodname_secret_scanning %} 警报。
|
||||
|
||||
|
||||
@@ -44,7 +44,7 @@ Wiki 是 Git 仓库的一部分，因此您可以在本地进行更改，然后
|
||||
|
||||
### 克隆 wiki 到计算机
|
||||
|
||||
每个 wiki 都提供一种将其内容克隆到计算机的简易方式。 您可以选择使用提供的 URL 将仓库克隆到计算机：
|
||||
每个 wiki 都提供一种将其内容克隆到计算机的简易方式。 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
|
||||
|
||||
@@ -22,7 +22,7 @@ topics:
|
||||
|
||||
议题让您可以在进行开发的 {% data variables.product.company_short %} 上跟踪您的工作。 当您在议题中提到另一个议题或拉取请求时，该议题的时间表会反映交叉参考，以便你能够跟踪相关的工作。 要表示工作正在进行中，您可以将议题链接到拉取请求。 当拉取请求合并时，链接的议题会自动关闭。
|
||||
|
||||
For more information on keywords, see "[Linking a pull request to an issue](issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)."
|
||||
有关关键词的更多信息，请参阅“[将拉取请求链接到议题](issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)”。
|
||||
|
||||
## 快速创建议题
|
||||
|
||||
|
||||
@@ -35,7 +35,7 @@ shortTitle: 将 PR 链接到议题
|
||||
|
||||
## 使用关键词将拉取请求链接到议题
|
||||
|
||||
You can link a pull request to an issue by using a supported keyword in the pull request's description or in a commit message. The pull request **must be** on the default branch.
|
||||
您可以通过在拉取请求说明或提交消息中使用支持的关键词将拉取请求链接到议题。 拉取请求**必须**在默认分支上。
|
||||
|
||||
* close
|
||||
* closes
|
||||
@@ -47,7 +47,7 @@ You can link a pull request to an issue by using a supported keyword in the pull
|
||||
* resolves
|
||||
* resolved
|
||||
|
||||
如果使用关键字在另一个拉取请求中引用拉取请求注释，则将链接拉取请求。 Merging the referencing pull request also closes the referenced pull request.
|
||||
如果使用关键字在另一个拉取请求中引用拉取请求注释，则将链接拉取请求。 合并引用拉取请求也会关闭引用的拉取请求。
|
||||
|
||||
关闭关键词的语法取决于议题是否与拉取请求在同一仓库中。
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
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. 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.
|
||||
|
||||
|
||||
1. Click **Save** to apply the settings.
|
||||
|
||||
{% endif %}
|
||||
{% endif %}
|
||||
|
||||
@@ -22,10 +22,10 @@ shortTitle: 配置提交压缩
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
3. 在 {% ifversion fpt or ghec or ghes > 3.4 or ghae-issue-6069 %}"拉取请求"{% else %}"合并按钮"{% endif %} 下，可以选择 **Allow merge commits（允许合并提交）**。 这将允许贡献者合并具有完整提交历史记录的拉取请求。 
|
||||
4. 在 {% ifversion fpt or ghec or ghes > 3.4 or ghae-issue-6069 %}“拉取请求”{% else %}“合并按钮”{% endif %} 下，选择 **Allow squash merging（允许压缩合并）**。 这将允许贡献者通过将所有提交压缩到单个提交中来合并拉取请求。 The squash message automatically defaults to the title of the pull request if it contains more than one commit. {% ifversion fpt or ghec or ghes > 3.5 or ghae-issue-7042 %}If you want to use the title of the pull request as the default merge message for all squashed commits, regardless of the number of commits in the pull request, select **Default to PR title for squash merge commits**. {% else %}
|
||||
4. 在 {% ifversion fpt or ghec or ghes > 3.4 or ghae-issue-6069 %}“拉取请求”{% else %}“合并按钮”{% endif %} 下，选择 **Allow squash merging（允许压缩合并）**。 这将允许贡献者通过将所有提交压缩到单个提交中来合并拉取请求。 压缩消息如果包含多个提交，则自动默认为拉取请求的标题。 {% ifversion fpt or ghec or ghes > 3.5 or ghae-issue-7042 %}如果要将拉取请求的标题用作所有压缩提交的默认合并消息，而不考虑拉取请求中的提交次数，请选择 **Default to PR title for squash merge commits（默认为压缩合并提交的 PR 标题）**。 {% else %}
|
||||
{% endif %}
|
||||
|
||||
If you select more than one merge method, collaborators can choose which type of merge commit to use when they merge a pull request. {% data reusables.repositories.squash-and-rebase-linear-commit-hisitory %}
|
||||
如果选择多种合并方法，则协作者可以选择在合并拉取请求时要使用的合并提交类型。 {% data reusables.repositories.squash-and-rebase-linear-commit-hisitory %}
|
||||
|
||||
## 延伸阅读
|
||||
|
||||
|
||||
@@ -48,13 +48,17 @@ remote: error: Required status check "ci-build" is failing
|
||||
|
||||
## 处理已跳过但需要检查
|
||||
|
||||
有时，由于路径筛选，在拉取请求上会跳过所需的状态检查。 例如，Node.JS 测试在仅修复自述文件中拼写错误的拉取请求上将跳过，并且不会更改 `scripts` 目录中的 JavaScript 和 TypeScript 文件。
|
||||
{% note %}
|
||||
|
||||
如果此检查是必需的，并且被跳过，则检查的状态将显示为挂起，因为它是必需的。 在此情况下，您将无法合并拉取请求。
|
||||
**Note:** If a workflow is skipped due to [path filtering](/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore), [branch filtering](/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore) or a [commit message](/actions/managing-workflow-runs/skipping-workflow-runs), then checks associated with that workflow will remain in a "Pending" state. A pull request that requires those checks to be successful will be blocked from merging.
|
||||
|
||||
If a job in a workflow is skipped due to a conditional, it will report its status as "Success". For more information see [Skipping workflow runs](/actions/managing-workflow-runs/skipping-workflow-runs) and [Using conditions to control job execution](/actions/using-jobs/using-conditions-to-control-job-execution).
|
||||
|
||||
{% endnote %}
|
||||
|
||||
### 示例
|
||||
|
||||
在此示例中，您有一个需要通过的工作流程。
|
||||
The following example shows a workflow that requires a "Successful" completion status for the `build` job, but the workflow will be skipped if the pull request does not change any files in the `scripts` directory.
|
||||
|
||||
```yaml
|
||||
name: ci
|
||||
@@ -62,7 +66,6 @@ on:
|
||||
pull_request:
|
||||
paths:
|
||||
- 'scripts/**'
|
||||
- 'middleware/**'
|
||||
jobs:
|
||||
build:
|
||||
runs-on: ubuntu-latest
|
||||
@@ -81,7 +84,7 @@ jobs:
|
||||
- run: npm test
|
||||
```
|
||||
|
||||
如果有人提交更改存储库根目录中 Markdown 文件的拉取请求，则上述工作流程将因路径筛选而完全不会运行。 因此，您将无法合并拉取请求。 您将在拉取请求上看到以下状态：
|
||||
Due to [path filtering](/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore), a pull request that only changes a file in the root of the repository will not trigger this workflow and is blocked from merging. 您将在拉取请求上看到以下状态：
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -106,20 +106,40 @@ miniTocMaxHeadingLevel: 3
|
||||
|
||||
{% data reusables.actions.workflow-permissions-intro %}
|
||||
|
||||
默认权限也可以在组织设置中配置。 如果在组织设置中选择了更受限制的默认值，则在仓库设置中自动选择相同的选项，并禁用许可的选项。
|
||||
默认权限也可以在组织设置中配置。 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 %}
|
||||
|
||||
### 配置默认 `GITHUB_TOKENN` 权限
|
||||
|
||||
{% 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. 在 **Workflow permissions（工作流程权限）**下，选择您是否想要 `GITHUB_TOKENN` 读写所有范围限， 或者只读`内容`范围。
|
||||
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. 单击 **Save（保存）**以应用设置。
|
||||
|
||||
{% 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.
|
||||
|
||||
|
||||
1. 单击 **Save（保存）**以应用设置。
|
||||
{% endif %}
|
||||
{% endif %}
|
||||
|
||||
{% ifversion ghes > 3.3 or ghae-issue-4757 or ghec %}
|
||||
|
||||
@@ -300,10 +300,10 @@ shortTitle: 搜索议题和 PR
|
||||
|
||||
您可以使用 `is` 限定符基于拉取请求已合并还是未合并进行过滤。
|
||||
|
||||
| 限定符 | 示例 |
|
||||
| ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `is:merged` | [**bug is:pr is:merged**](https://github.com/search?utf8=%E2%9C%93&q=bugfix+is%3Apr+is%3Amerged&type=) 匹配含有 "bug" 字样的已合并拉取请求。 |
|
||||
| `is:unmerged` | [**error is:unmerged**](https://github.com/search?utf8=%E2%9C%93&q=error+is%3Aunmerged&type=) matches pull requests with the word "error" that are either open or were closed without being merged. |
|
||||
| 限定符 | 示例 |
|
||||
| ------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `is:merged` | [**bug is:pr is:merged**](https://github.com/search?utf8=%E2%9C%93&q=bugfix+is%3Apr+is%3Amerged&type=) 匹配含有 "bug" 字样的已合并拉取请求。 |
|
||||
| `is:unmerged` | [**error is:unmerged**](https://github.com/search?utf8=%E2%9C%93&q=error+is%3Aunmerged&type=) 将拉取请求与单词“error”匹配，这些请求的状态为打开或关闭，但未合并。 |
|
||||
|
||||
## 基于仓库是否已存档搜索
|
||||
|
||||
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
#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'
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
#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'
|
||||
@@ -46,7 +46,7 @@ sections:
|
||||
heading: Server Statistics in public beta
|
||||
notes:
|
||||
- |
|
||||
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:
|
||||
|
||||
@@ -1 +1 @@
|
||||
您可以设置授予 `GITHUB_TOKEN` 的默认权限。 For more information about the `GITHUB_TOKEN`, see "[Automatic token authentication](/actions/security-guides/automatic-token-authentication)." 您可以选择一组有限的权限作为默认或权限设置。
|
||||
您可以设置授予 `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.
|
||||
|
||||
@@ -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.
|
||||
@@ -51,7 +51,7 @@ If you define a branch with the `!` character, you must also define at least one
|
||||
- 肯定匹配后的匹配否定模式（前缀为 `!`）将排除 Git 引用。
|
||||
- 否定匹配后的匹配肯定模式将再次包含 Git 引用。
|
||||
|
||||
The following workflow will run on `pull_request` events for pull requests that target `releases/10` or `releases/beta/mona`, but for pull requests that target `releases/10-alpha` or `releases/beta/3-alpha` because the negative pattern `!releases/**-alpha` follows the positive pattern.
|
||||
The following workflow will run on `pull_request` events for pull requests that target `releases/10` or `releases/beta/mona`, but not for pull requests that target `releases/10-alpha` or `releases/beta/3-alpha` because the negative pattern `!releases/**-alpha` follows the positive pattern.
|
||||
|
||||
```yaml
|
||||
on:
|
||||
|
||||
@@ -20,7 +20,7 @@ on:
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** If a workflow is skipped due to path filtering, but the workflow is set as a required check, then the check will remain as "Pending". To work around this, you can create a corresponding workflow with the same name that always passes whenever the original workflow is skipped because of path filtering. For more information, see "[Handling skipped but required checks](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/troubleshooting-required-status-checks#handling-skipped-but-required-checks)."
|
||||
**Note:** If a workflow is skipped due to [path filtering](/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore), [branch filtering](/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore) or a [commit message](/actions/managing-workflow-runs/skipping-workflow-runs), then checks associated with that workflow will remain in a "Pending" state. A pull request that requires those checks to be successful will be blocked from merging. For more information, see "[Handling skipped but required checks](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/troubleshooting-required-status-checks#handling-skipped-but-required-checks)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
|
||||
@@ -22,6 +22,10 @@
|
||||
| Contributed Systems | Contributed Systems 凭据 |
|
||||
| Databricks | Databricks 访问令牌 |
|
||||
| Datadog | Datadog API 密钥 |
|
||||
| DigitalOcean | DigitalOcean Personal Access Token |
|
||||
| DigitalOcean | DigitalOcean OAuth Token |
|
||||
| DigitalOcean | DigitalOcean Refresh Token |
|
||||
| DigitalOcean | DigitalOcean System Token |
|
||||
| Discord | Discord 自动程序令牌 |
|
||||
| Doppler | Doppler 个人令牌 |
|
||||
| Doppler | Doppler 服务令牌 |
|
||||
|
||||
@@ -159,7 +159,7 @@ prodname_copilot_short: 'Copilot'
|
||||
#Command Palette
|
||||
prodname_command_palette: 'GitHub 命令面板'
|
||||
#Server Statistics
|
||||
prodname_server_statistics: 'Server Statistics'
|
||||
prodname_server_statistics: '服务器统计信息'
|
||||
#Links
|
||||
product_url: >-
|
||||
{% ifversion fpt or ghec %}github.com{% else %}[hostname]{% endif %}
|
||||
|
||||
Reference in New Issue
Block a user