New translation batch for cn (#26386)
* Add crowdin translations * Run script/i18n/homogenize-frontmatter.js * Run script/i18n/lint-translation-files.js --check rendering * run script/i18n/reset-files-with-broken-liquid-tags.js --language=cn * run script/i18n/reset-known-broken-translation-files.js * Check in cn CSV report Co-authored-by: Peter Bengtsson <mail@peterbe.com>
This commit is contained in:
docubot
@@ -138,6 +138,7 @@ translations/zh-CN/content/codespaces/customizing-your-codespace/personalizing-c
|
||||
translations/zh-CN/content/codespaces/developing-in-codespaces/developing-in-a-codespace.md,broken liquid tags
|
||||
translations/zh-CN/content/codespaces/developing-in-codespaces/forwarding-ports-in-your-codespace.md,broken liquid tags
|
||||
translations/zh-CN/content/codespaces/developing-in-codespaces/using-codespaces-in-visual-studio-code.md,broken liquid tags
|
||||
translations/zh-CN/content/codespaces/developing-in-codespaces/using-codespaces-with-github-cli.md,broken liquid tags
|
||||
translations/zh-CN/content/codespaces/managing-codespaces-for-your-organization/enabling-codespaces-for-your-organization.md,broken liquid tags
|
||||
translations/zh-CN/content/codespaces/the-githubdev-web-based-editor.md,broken liquid tags
|
||||
translations/zh-CN/content/codespaces/troubleshooting/troubleshooting-your-connection-to-codespaces.md,broken liquid tags
|
||||
|
||||
|
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: About security hardening with OpenID Connect
|
||||
shortTitle: About security hardening with OpenID Connect
|
||||
intro: OpenID Connect allows your workflows to exchange short-lived tokens directly from your cloud provider.
|
||||
title: 关于使用 OpenID Connect 进行安全强化
|
||||
shortTitle: 关于使用 OpenID Connect 进行安全强化
|
||||
intro: OpenID Connect 允许您的工作流程直接从云提供商交换短期令牌。
|
||||
miniTocMaxHeadingLevel: 4
|
||||
versions:
|
||||
fpt: '*'
|
||||
@@ -15,45 +15,45 @@ topics:
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
## Overview of OpenID Connect
|
||||
## OpenID Connect 概述
|
||||
|
||||
{% data variables.product.prodname_actions %} workflows are often designed to access a cloud provider (such as AWS, Azure, GCP, or HashiCorp Vault) in order to deploy software or use the cloud's services. Before the workflow can access these resources, it will supply credentials, such as a password or token, to the cloud provider. These credentials are usually stored as a secret in {% data variables.product.prodname_dotcom %}, and the workflow presents this secret to the cloud provider every time it runs.
|
||||
{% data variables.product.prodname_actions %} 工作流程通常设计为访问云提供商（如 AWS、Azure、GCP 或 HashiCorp Vault），以便部署软件或使用云的服务。 在工作流程可以访问这些资源之前，它将向云提供商提供凭据（如密码或令牌）。 这些凭据通常作为机密存储在 {% data variables.product.prodname_dotcom %} 中，工作流程在每次运行时都会将此机密呈现给云提供商。
|
||||
|
||||
However, using hardcoded secrets requires you to create credentials in the cloud provider and then duplicate them in {% data variables.product.prodname_dotcom %} as a secret.
|
||||
但是，使用硬编码的机密需要在云提供商中创建凭据，然后在 {% data variables.product.prodname_dotcom %} 中将其复制为机密。
|
||||
|
||||
With OpenID Connect (OIDC), you can take a different approach by configuring your workflow to request a short-lived access token directly from the cloud provider. Your cloud provider also needs to support OIDC on their end, and you must configure a trust relationship that controls which workflows are able to request the access tokens. Providers that currently support OIDC include Amazon Web Services, Azure, Google Cloud Platform, and HashiCorp Vault, among others.
|
||||
借助 OpenID Connect (OIDC)，您可以采用不同的方法，将工作流程配置为直接从云提供商请求短期访问令牌。 您的云提供商还需要在其终端上支持 OIDC，并且您必须配置信任关系，以控制哪些工作流程能够请求访问令牌。 目前支持 OIDC 的提供商包括 Amazon Web Services、Azure、Google Cloud Platform 和 HashiCorp Vault 等。
|
||||
|
||||
### Benefits of using OIDC
|
||||
### 使用 OIDC 的好处
|
||||
|
||||
By updating your workflows to use OIDC tokens, you can adopt the following good security practices:
|
||||
通过更新工作流程以使用 OIDC 令牌，您可以采用以下良好的安全实践：
|
||||
|
||||
- **No cloud secrets**: You won't need to duplicate your cloud credentials as long-lived {% data variables.product.prodname_dotcom %} secrets. Instead, you can configure the OIDC trust on your cloud provider, and then update your workflows to request a short-lived access token from the cloud provider through OIDC.
|
||||
- **Authentication and authorization management**: You have more granular control over how workflows can use credentials, using your cloud provider's authentication (authN) and authorization (authZ) tools to control access to cloud resources.
|
||||
- **Rotating credentials**: With OIDC, your cloud provider issues a short-lived access token that is only valid for a single job, and then automatically expires.
|
||||
- **无云机密**：无需将云凭据复制为长期 {% data variables.product.prodname_dotcom %} 机密。 相反，您可以在云提供商上配置 OIDC 信任，然后更新您的工作流程，通过 OIDC 向云提供商请求短期访问令牌。
|
||||
- **身份验证和授权管理**：您可以更细致地控制工作流程如何使用凭据，使用云提供商的身份验证 (authN) 和授权 (authZ) 工具来控制对云资源的访问。
|
||||
- **轮换凭证**：借助 OIDC，您的云提供商会颁发仅对单个作业有效的短期访问令牌，然后自动过期。
|
||||
|
||||
### Getting started with OIDC
|
||||
### 开始使用 OIDC
|
||||
|
||||
The following diagram gives an overview of how {% data variables.product.prodname_dotcom %}'s OIDC provider integrates with your workflows and cloud provider:
|
||||
下图概述了 {% data variables.product.prodname_dotcom %} 的 OIDC 提供商如何与您的工作流程和云提供商集成：
|
||||
|
||||
|
||||
|
||||
|
||||
1. In your cloud provider, create an OIDC trust between your cloud role and your {% data variables.product.prodname_dotcom %} workflow(s) that need access to the cloud.
|
||||
2. Every time your job runs, {% data variables.product.prodname_dotcom %}'s OIDC Provider auto-generates an OIDC token. This token contains multiple claims to establish a security-hardened and verifiable identity about the specific workflow that is trying to authenticate.
|
||||
3. You could include a step or action in your job to request this token from {% data variables.product.prodname_dotcom %}'s OIDC provider, and present it to the cloud provider.
|
||||
4. Once the cloud provider successfully validates the claims presented in the token, it then provides a short-lived cloud access token that is available only for the duration of the job.
|
||||
1. 在云提供商中，在您的云角色和需要访问云的 {% data variables.product.prodname_dotcom %} 工作流程之间创建 OIDC 信任。
|
||||
2. 每次作业运行时，{% data variables.product.prodname_dotcom %}的 OIDC 提供商都会自动生成一个 OIDC 令牌。 此令牌包含多个声明，用于建立有关尝试进行身份验证的特定工作流程的经安全强化且可验证的身份。
|
||||
3. 您可以在作业中包含一个步骤或操作，以从 {% data variables.product.prodname_dotcom %} 的 OIDC 提供商请求此令牌，并将其提供给云提供商。
|
||||
4. 云提供商成功验证令牌中提供的声明后，将提供仅在作业期间可用的短期云访问令牌。
|
||||
|
||||
## Configuring the OIDC trust with the cloud
|
||||
## 通过云配置 OIDC 信任
|
||||
|
||||
When you configure your cloud to trust {% data variables.product.prodname_dotcom %}'s OIDC provider, you **must** add conditions that filter incoming requests, so that untrusted repositories or workflows can’t request access tokens for your cloud resources:
|
||||
将云配置为信任 {% data variables.product.prodname_dotcom %} 的 OIDC 提供商时，**必须**添加过滤传入请求的条件，使不受信任的存储库或工作流程无法为您的云资源请求访问令牌：
|
||||
|
||||
- Before granting an access token, your cloud provider checks that the [`subject`](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) and other claims used to set conditions in its trust settings match those in the request's JSON Web Token (JWT). As a result, you must take care to correctly define the _subject_ and other conditions in your cloud provider.
|
||||
- The OIDC trust configuration steps and the syntax to set conditions for cloud roles (using _Subject_ and other claims) will vary depending on which cloud provider you're using. For some examples, see "[Example subject claims](#example-subject-claims)."
|
||||
- 在授予访问令牌之前，云提供商会检查[`主题`](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims)以及用于在其信任设置中设置条件的其他声明是否与请求的 JSON Web 令牌 (JWT) 中的声明匹配。 因此，您必须注意正确定义云提供商中的_主题_和其他条件。
|
||||
- OIDC 信任配置步骤和为云角色设置条件的语法（使用_主题_和其他声明）将因您使用的云提供商而异。 有关一些示例，请参阅“[示例主题声明](#example-subject-claims)”。
|
||||
|
||||
### Understanding the OIDC token
|
||||
### 了解 OIDC 令牌
|
||||
|
||||
Each job requests an OIDC token from {% data variables.product.prodname_dotcom %}'s OIDC provider, which responds with an automatically generated JSON web token (JWT) that is unique for each workflow job where it is generated. When the job runs, the OIDC token is presented to the cloud provider. To validate the token, the cloud provider checks if the OIDC token's subject and other claims are a match for the conditions that were preconfigured on the cloud role's OIDC trust definition.
|
||||
每个作业都从 {% data variables.product.prodname_dotcom %} 的 OIDC 提供商请求一个 OIDC 令牌，提供商使用自动生成的 JSON Web 令牌 (JWT) 进行响应，该令牌对于生成它的每个工作流程作业都是唯一的。 当作业运行时，OIDC 令牌将呈现给云提供商。 要验证令牌，云提供商会检查 OIDC 令牌的主题和其他声明是否与云角色的 OIDC 信任定义上预配置的条件匹配。
|
||||
|
||||
The following example OIDC token uses a subject (`sub`) that references a job environment named `prod` in the `octo-org/octo-repo` repository.
|
||||
以下示例 OIDC 令牌使用引用 `octo-org/octo-repo` 存储库中名为 `prod` 的作业环境的主题 (`sub`)。
|
||||
|
||||
```yaml
|
||||
{
|
||||
@@ -88,116 +88,116 @@ The following example OIDC token uses a subject (`sub`) that references a job en
|
||||
}
|
||||
```
|
||||
|
||||
To see all the claims supported by {% data variables.product.prodname_dotcom %}'s OIDC provider, review the `claims_supported` entries at https://token.actions.githubusercontent.com/.well-known/openid-configuration.
|
||||
要查看 {% data variables.product.prodname_dotcom %} 的 OIDC 提供商支持的所有声明，请查看 https://token.actions.githubusercontent.com/.well-known/openid-configuration 中的 `claims_supported` 条目。
|
||||
|
||||
The token includes the standard audience, issuer, and subject claims:
|
||||
令牌包括标准受众、颁发者和主题声明：
|
||||
|
||||
| Claim | 描述 |
|
||||
| ----- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| `aud` | _(Audience)_ By default, this is the URL of the repository owner, such as the organization that owns the repository. This is the only claim that can be customized. You can set a custom audience with a toolkit command: [`core.getIDToken(audience)`](https://www.npmjs.com/package/@actions/core/v/1.6.0) |
|
||||
| `iss` | _(Issuer)_ The issuer of the OIDC token: `https://token.actions.githubusercontent.com` |
|
||||
| `sub` | _(Subject)_ Defines the subject claim that is to be validated by the cloud provider. This setting is essential for making sure that access tokens are only allocated in a predictable way. |
|
||||
| 声明 | 描述 |
|
||||
| ----- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `aud` | _（受众）_ 默认情况下，这是存储库所有者（如拥有存储库的组织）的 URL。 这是唯一可以自定义的声明。 您可以使用工具包命令设置自定义受众：[`core.getIDToken(audience)`](https://www.npmjs.com/package/@actions/core/v/1.6.0) |
|
||||
| `iss` | _（发行人）_ OIDC 令牌的发行人：`https://token.actions.githubusercontent.com` |
|
||||
| `sub` | _（主题）_ 定义要由云提供商验证的主题声明。 此设置对于确保仅以可预测的方式分配访问令牌至关重要。 |
|
||||
|
||||
The OIDC token also includes additional standard claims:
|
||||
OIDC 令牌还包括其他标准声明：
|
||||
|
||||
| Claim | 描述 |
|
||||
| ----- | --------------------------------------------------------------------- |
|
||||
| `alg` | _(Algorithm)_ The algorithm used by the OIDC provider. |
|
||||
| `exp` | _(Expires at)_ Identifies the expiry time of the JWT. |
|
||||
| `iat` | _(Issued at)_ The time when the JWT was issued. |
|
||||
| `jti` | _(JWT token identifier)_ Unique identifier for the OIDC token. |
|
||||
| `kid` | _(Key identifier)_ Unique key for the OIDC token. |
|
||||
| `nbf` | _(Not before)_ JWT is not valid for use before this time. |
|
||||
| `typ` | _(Type)_ Describes the type of token. This is a JSON Web Token (JWT). |
|
||||
| 声明 | 描述 |
|
||||
| ----- | ------------------------------------- |
|
||||
| `alg` | _（算法）_OIDC 提供商使用的算法。 |
|
||||
| `exp` | _（到期时间）_ 标识 JWT 的到期时间。 |
|
||||
| `iat` | _（发行时间）_ JWT 的发行时间。 |
|
||||
| `jti` | _（JWT 令牌标识符）_ OIDC 令牌的唯一标识符。 |
|
||||
| `kid` | _（密钥标识符）_ OIDC 令牌的唯一密钥。 |
|
||||
| `nbf` | _（在此之前无效）_ JWT 在此时间之前无效。 |
|
||||
| `typ` | _（类型）_ 描述令牌的类型。 这是 JSON Web 令牌 (JWT)。 |
|
||||
|
||||
The token also includes custom claims provided by {% data variables.product.prodname_dotcom %}:
|
||||
令牌还包括 {% data variables.product.prodname_dotcom %} 提供的自定义声明：
|
||||
|
||||
| Claim | 描述 |
|
||||
| ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `actor` | The user account that initiated the workflow run. |
|
||||
| `base_ref` | The target branch of the pull request in a workflow run. |
|
||||
| `environment` | The name of the environment used by the job. |
|
||||
| `event_name` | 触发工作流程运行的事件的名称。 |
|
||||
| `head_ref` | The source branch of the pull request in a workflow run. |
|
||||
| `job_workflow_ref` | This is the ref path to the reusable workflow used by this job. For more information, see "["Using OpenID Connect with reusable workflows"](/actions/deployment/security-hardening-your-deployments/using-openid-connect-with-reusable-workflows)." |
|
||||
| `ref` | _(Reference)_ The git ref that triggered the workflow run. |
|
||||
| `ref_type` | The type of `ref`, for example: "branch". |
|
||||
| `仓库` | The repository from where the workflow is running. |
|
||||
| `repository_owner` | The name of the organization in which the `repository` is stored. |
|
||||
| `run_id` | The ID of the workflow run that triggered the workflow. |
|
||||
| `run_number` | The number of times this workflow has been run. |
|
||||
| `run_attempt` | The number of times this workflow run has been retried. |
|
||||
| `工作流程` | 工作流程的名称。 |
|
||||
| 声明 | 描述 |
|
||||
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| `actor` | 发起工作流程运行的用户帐户。 |
|
||||
| `base_ref` | 工作流程运行中拉取请求的目标分支。 |
|
||||
| `environment` | 作业使用的环境的名称。 |
|
||||
| `event_name` | 触发工作流程运行的事件的名称。 |
|
||||
| `head_ref` | 工作流程运行中拉取请求的来源分支。 |
|
||||
| `job_workflow_ref` | 这是此作业使用的可重用工作流程的引用路径。 更多信息请参阅“[使用 OpenID 连接和可重用工作流程](/actions/deployment/security-hardening-your-deployments/using-openid-connect-with-reusable-workflows)”。 |
|
||||
| `ref` | _（引用）_ 触发工作流程运行的 git 引用。 |
|
||||
| `ref_type` | `ref` 的类型，例如："branch"。 |
|
||||
| `仓库` | 运行工作流程的存储库。 |
|
||||
| `repository_owner` | 存储 `repository` 的组织的名称。 |
|
||||
| `run_id` | 触发工作流程的工作流程运行的 ID。 |
|
||||
| `run_number` | 此工作流程已运行的次数。 |
|
||||
| `run_attempt` | 此工作流程运行的重试次数。 |
|
||||
| `工作流程` | 工作流程的名称。 |
|
||||
|
||||
### Defining trust conditions on cloud roles using OIDC claims
|
||||
### 使用 OIDC 声明定义云角色的信任条件
|
||||
|
||||
With OIDC, a {% data variables.product.prodname_actions %} workflow requires a token in order to access resources in your cloud provider. The workflow requests an access token from your cloud provider, which checks the details presented by the JWT. If the trust configuration in the JWT is a match, your cloud provider responds by issuing a temporary token to the workflow, which can then be used to access resources in your cloud provider. You can configure your cloud provider to only respond to requests that originate from a specific organization's repository; you can also specify additional conditions, described below.
|
||||
借助 OIDC，{% data variables.product.prodname_actions %} 工作流程需要令牌才能访问云提供商中的资源。 工作流程从云提供商请求访问令牌，以检查 JWT 提供的详细信息。 如果 JWT 中的信任配置匹配，则云提供商将通过向工作流程颁发临时令牌来做出响应，然后可以使用该令牌访问云提供商中的资源。 您可以将云提供商配置为仅响应来自特定组织的存储库的请求；您还可以指定其他条件，如下所述。
|
||||
|
||||
Audience and Subject claims are typically used in combination while setting conditions on the cloud role/resources to scope its access to the GitHub workflows.
|
||||
- **Audience**: By default, this value uses the URL of the organization or repository owner. This can be used to set a condition that only the workflows in the specific organization can access the cloud role.
|
||||
- **Subject**: Has a predefined format and is a concatenation of some of the key metadata about the workflow, such as the {% data variables.product.prodname_dotcom %} organization, repository, branch, or associated [`job`](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idenvironment) environment. See "[Example subject claims](#example-subject-claims)" to see how the subject claim is assembled from concatenated metadata.
|
||||
在云角色/资源上设置条件以限定其对 GitHub 工作流程的访问范围时，受众和主题声明通常结合使用。
|
||||
- **受众**：默认情况下，此值使用组织或存储库所有者的 URL。 这可用于设置只有特定组织中的工作流程才能访问云角色的条件。
|
||||
- **主题**：具有预定义的格式，并且是有关工作流程的某些关键元数据的串联，如 {% data variables.product.prodname_dotcom %} 组织、存储库、分支或关联的[`作业`](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idenvironment)环境。 请参阅“[示例主题声明](#example-subject-claims)”，了解如何从串联的元数据汇编主题声明。
|
||||
|
||||
There are also many additional claims supported in the OIDC token that can also be used for setting these conditions.
|
||||
OIDC 令牌中还支持许多其他声明，这些声明也可用于设置这些条件。
|
||||
|
||||
In addition, your cloud provider could allow you to assign a role to the access tokens, letting you specify even more granular permissions.
|
||||
此外，云提供商可以允许你为访问令牌分配角色，从而允许你指定更精细的权限。
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note**: To control how your cloud provider issues access tokens, you **must** define at least one condition, so that untrusted repositories can’t request access tokens for your cloud resources.
|
||||
**注意**：要控制云提供商颁发访问令牌的方式，**必须**至少定义一个条件，使不受信任的存储库无法为云资源请求访问令牌。
|
||||
|
||||
{% endnote %}
|
||||
|
||||
### Example subject claims
|
||||
### 示例主题声明
|
||||
|
||||
The following examples demonstrate how to use "Subject" as a condition, and explain how the "Subject" is assembled from concatenated metadata. The [subject](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) uses information from the [`job` context](/actions/learn-github-actions/contexts#job-context), and instructs your cloud provider that access token requests may only be granted for requests from workflows running in specific branches, environments. The following sections describe some common subjects you can use.
|
||||
以下示例演示如何使用“主题”作为条件，并说明如何从串联的元数据汇编“主题”。 [主题](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims)使用 [`作业`上下文](/actions/learn-github-actions/contexts#job-context)中的信息，并指示云提供商只能为来自特定分支、环境中运行的工作流程的请求授予访问令牌请求。 以下各节介绍了您可以使用的一些常见主题。
|
||||
|
||||
#### Filtering for a specific environment
|
||||
#### 筛选特定环境
|
||||
|
||||
The subject claim includes the environment name when the job references an environment.
|
||||
当作业引用环境时，主题声明包括环境名称。
|
||||
|
||||
You can configure a subject that filters for a specific [environment](/actions/deployment/using-environments-for-deployment) name. In this example, the workflow run must have originated from a job that has an environment named `Production`, in a repository named `octo-repo` that is owned by the `octo-org` organization:
|
||||
您可以配置针对特定[环境](/actions/deployment/using-environments-for-deployment)进行筛选的主题名称。 在此示例中，工作流程运行必须源自具有环境 `Production`、位于 `octo-org` 组织拥有的存储库 `octo-repo` 中的作业：
|
||||
|
||||
| | |
|
||||
| --- | ------------------------------------------------------------------- |
|
||||
| 语法: | `repo:<orgName/repoName>:environment:<environmentName>` |
|
||||
| 示例： | `repo:octo-org/octo-repo:environment:Production` |
|
||||
|
||||
#### Filtering for `pull_request` events
|
||||
#### 筛选 `pull_request` 事件
|
||||
|
||||
The subject claim includes the `pull_request` string when the workflow is triggered by a pull request event, but only if the job doesn't reference an environment.
|
||||
当工作流程由拉取请求事件触发时，主题声明包括 `pull_request` 字符串，但前提是作业未引用环境。
|
||||
|
||||
You can configure a subject that filters for the [`pull_request`](/actions/learn-github-actions/events-that-trigger-workflows#pull_request) event. In this example, the workflow run must have been triggered by a `pull_request` event in a repository named `octo-repo` that is owned by the `octo-org` organization:
|
||||
您可以配置筛选 [`pull_request`](/actions/learn-github-actions/events-that-trigger-workflows#pull_request) 事件的主题。 在此示例中，工作流程运行必须由 `octo-org` 组织拥有的存储库 `octo-repo` 中的 `pull_request` 事件触发：
|
||||
|
||||
| | |
|
||||
| --- | -------------------------------------------- |
|
||||
| 语法: | `repo:<orgName/repoName>:pull_request` |
|
||||
| 示例： | `repo:octo-org/octo-repo:pull_request` |
|
||||
|
||||
#### Filtering for a specific branch
|
||||
#### 筛选特定分支
|
||||
|
||||
The subject claim includes the branch name of the workflow, but only if the job doesn't reference an environment, and if the workflow is not triggered by a pull request event.
|
||||
主题声明包括工作流程的分支名称，但前提是作业未引用环境，并且工作流程不是由拉取请求事件触发的。
|
||||
|
||||
You can configure a subject that filters for a specific branch name. In this example, the workflow run must have originated from a branch named `demo-branch`, in a repository named `octo-repo` that is owned by the `octo-org` organization:
|
||||
您可以配置筛选特定分支名称的主题。 在此示例中，工作流程运行必须源自 `octo-org` 组织拥有的存储库 `octo-repo` 中的 `demo-branch` 分支：
|
||||
|
||||
| | |
|
||||
| --- | --------------------------------------------------------- |
|
||||
| 语法: | `repo:<orgName/repoName>:ref:refs/heads/branchName` |
|
||||
| 示例： | `repo:octo-org/octo-repo:ref:refs/heads/demo-branch` |
|
||||
|
||||
#### Filtering for a specific tag
|
||||
#### 筛选特定标记
|
||||
|
||||
The subject claim includes the tag name of the workflow, but only if the job doesn't reference an environment, and if the workflow is not triggered by a pull request event.
|
||||
主题声明包括工作流程的标记名称，但前提是作业未引用环境，并且工作流程不是由拉取请求事件触发的。
|
||||
|
||||
You can create a subject that filters for specific tag. In this example, the workflow run must have originated with a tag named `demo-tag`, in a repository named `octo-repo` that is owned by the `octo-org` organization:
|
||||
您可以创建筛选特定标记的主题。 在此示例中，工作流程运行必须源自 `octo-org` 组织拥有的存储库 `octo-repo` 中的 `demo-tag` 标记：
|
||||
|
||||
| | |
|
||||
| --- | ------------------------------------------------------------- |
|
||||
| 语法: | `repo:<orgName/repoName>:ref:refs/tags/<tagName>` |
|
||||
| 示例： | `repo:octo-org/octo-repo:ref:refs/tags/demo-tag` |
|
||||
|
||||
### Configuring the subject in your cloud provider
|
||||
### 在云提供商中配置主题
|
||||
|
||||
To configure the subject in your cloud provider's trust relationship, you must add the subject string to its trust configuration. The following examples demonstrate how various cloud providers can accept the same `repo:octo-org/octo-repo:ref:refs/heads/demo-branch` subject in different ways:
|
||||
要在云提供商的信任关系中配置主题，必须将主题字符串添加到其信任配置中。 以下示例演示了各种云提供商如何以不同的方式接受相同的 `repo:octo-org/octo-repo:ref:refs/heads/demo-branch` 主题：
|
||||
|
||||
| | |
|
||||
| ------------------- | ------------------------------------------------------------------------------------------------- |
|
||||
@@ -206,18 +206,18 @@ To configure the subject in your cloud provider's trust relationship, you must a
|
||||
| Google Cloud 平台 | `(assertion.sub=='repo:octo-org/octo-repo:ref:refs/heads/demo-branch')` |
|
||||
| HashiCorp Vault | `bound_subject="repo:octo-org/octo-repo:ref:refs/heads/demo-branch"` |
|
||||
|
||||
For more information, see the guides listed in "[Enabling OpenID Connect for your cloud provider](#enabling-openid-connect-for-your-cloud-provider)."
|
||||
更多信息请参阅“[为云提供商启用 OpenID Connect](#enabling-openid-connect-for-your-cloud-provider)”中列出的指南。
|
||||
|
||||
## Updating your actions for OIDC
|
||||
## 更新用于 OIDC 的操作
|
||||
|
||||
To update your custom actions to authenticate using OIDC, you can use `getIDToken()` from the Actions toolkit to request a JWT from {% data variables.product.prodname_dotcom %}'s OIDC provider. For more information, see "OIDC Token" in the [npm package documentation](https://www.npmjs.com/package/@actions/core/v/1.6.0).
|
||||
要更新您的自定义操作以使用 OIDC 进行身份验证，您可以使用 Actions 工具包中的 `getIDToken()` 从 {% data variables.product.prodname_dotcom %} 的 OIDC 提供商请求 JWT。 更多信息请参阅 [npm 包文档](https://www.npmjs.com/package/@actions/core/v/1.6.0)中的“OIDC 令牌”。
|
||||
|
||||
You could also use a `curl` command to request the JWT, using the following environment variables:
|
||||
您还可以使用 `curl` 命令来请求 JWT，方法是使用以下环境变量：
|
||||
|
||||
| | |
|
||||
| -------------------------------- | ------------------------------------------------------------------------- |
|
||||
| `ACTIONS_ID_TOKEN_REQUEST_URL` | The URL for {% data variables.product.prodname_dotcom %}'s OIDC provider. |
|
||||
| `ACTIONS_ID_TOKEN_REQUEST_TOKEN` | Bearer token for the request to the OIDC provider. |
|
||||
| | |
|
||||
| -------------------------------- | ------------------------------------------------------------- |
|
||||
| `ACTIONS_ID_TOKEN_REQUEST_URL` | {% data variables.product.prodname_dotcom %} 的 OIDC 提供商的 URL。 |
|
||||
| `ACTIONS_ID_TOKEN_REQUEST_TOKEN` | 向 OIDC 提供商发出请求的持有者令牌。 |
|
||||
|
||||
|
||||
例如：
|
||||
@@ -230,20 +230,20 @@ curl -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" "$ACTIONS_ID_TOK
|
||||
|
||||
{% data reusables.actions.oidc-permissions-token %}
|
||||
|
||||
## Updating your workflows for OIDC
|
||||
## 更新 OIDC 的工作流程
|
||||
|
||||
You can now update your YAML workflows to use OIDC access tokens instead of secrets. Popular cloud providers have published their official login actions that make it easy for you to get started with OIDC. For more information about updating your workflows, see the cloud-specific guides listed below in "[Enabling OpenID Connect for your cloud provider](#enabling-openid-connect-for-your-cloud-provider)."
|
||||
现在，您可以更新 YAML 工作流程，以使用 OIDC 访问令牌而不是机密。 常用的云提供商已发布其官方登录操作，使您可以轻松开始使用 OIDC。 有关更新工作流程的详细信息，请参阅下面“[为云提供商启用 OpenID Connect ](#enabling-openid-connect-for-your-cloud-provider)”中列出的云特定指南。
|
||||
|
||||
|
||||
## Enabling OpenID Connect for your cloud provider
|
||||
## 为云提供商启用 OpenID Connect
|
||||
|
||||
To enable and configure OIDC for your specific cloud provider, see the following guides:
|
||||
要为您的特定云提供商启用和配置 OIDC，请参阅以下指南：
|
||||
|
||||
- ["Configuring OpenID Connect in Amazon Web Services"](/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)
|
||||
- ["Configuring OpenID Connect in Azure"](/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-azure)
|
||||
- ["Configuring OpenID Connect in Google Cloud Platform"](/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-google-cloud-platform)
|
||||
- ["Configuring OpenID Connect in Hashicorp Vault"](/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-hashicorp-vault)
|
||||
- ["在 Amazon Web Services 中配置 OpenID Connect"](/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)
|
||||
- ["在 Azure 中配置 OpenID Connect"](/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-azure)
|
||||
- ["在 Google Cloud Platform 中配置 OpenID Connect"](/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-google-cloud-platform)
|
||||
- ["在 Hashicorp Vault 中配置 OpenID Connect"](/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-hashicorp-vault)
|
||||
|
||||
To enable and configure OIDC for another cloud provider, see the following guide:
|
||||
要为其他云提供商启用和配置 OIDC，请参阅以下指南：
|
||||
|
||||
- ["Configuring OpenID Connect in cloud providers"](/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-cloud-providers)
|
||||
- ["在云提供商中配置 OpenID Connect"](/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-cloud-providers)
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Configuring OpenID Connect in Amazon Web Services
|
||||
shortTitle: Configuring OpenID Connect in Amazon Web Services
|
||||
intro: Use OpenID Connect within your workflows to authenticate with Amazon Web Services.
|
||||
title: 在 Amazon Web Services 中配置 OpenID Connect
|
||||
shortTitle: 在 Amazon Web Services 中配置 OpenID Connect
|
||||
intro: 在工作流程中使用 OpenID Connect 向 Amazon Web Services 进行身份验证。
|
||||
miniTocMaxHeadingLevel: 3
|
||||
versions:
|
||||
fpt: '*'
|
||||
@@ -17,9 +17,9 @@ topics:
|
||||
|
||||
## 概览
|
||||
|
||||
OpenID Connect (OIDC) allows your {% data variables.product.prodname_actions %} workflows to access resources in Amazon Web Services (AWS), without needing to store the AWS credentials as long-lived {% data variables.product.prodname_dotcom %} secrets.
|
||||
OpenID Connect (OIDC) 允许您的 {% data variables.product.prodname_actions %} 工作流程访问 Amazon Web Services (AWS) 中的资源，而无需将任何 AWS 凭据存储为长期 {% data variables.product.prodname_dotcom %} 机密。
|
||||
|
||||
This guide explains how to configure AWS to trust {% data variables.product.prodname_dotcom %}'s OIDC as a federated identity, and includes a workflow example for the [`aws-actions/configure-aws-credentials`](https://github.com/aws-actions/configure-aws-credentials) that uses tokens to authenticate to AWS and access resources.
|
||||
本指南介绍如何配置 AWS 信任 {% data variables.product.prodname_dotcom %} 的 OIDC 作为联合标识，并包括使用令牌向 AWS 验证并访问资源的 [`aws-actions/configure-aws-credentials`](https://github.com/aws-actions/configure-aws-credentials) 工作流程示例。
|
||||
|
||||
## 基本要求
|
||||
|
||||
@@ -27,18 +27,18 @@ This guide explains how to configure AWS to trust {% data variables.product.prod
|
||||
|
||||
{% data reusables.actions.oidc-security-notice %}
|
||||
|
||||
## Adding the identity provider to AWS
|
||||
## 将身份提供商添加到 AWS
|
||||
|
||||
To add the {% data variables.product.prodname_dotcom %} OIDC provider to IAM, see the [AWS documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html).
|
||||
要将 {% data variables.product.prodname_dotcom %} OIDC 提供商添加到 IAM，请参阅 [AWS 文档](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html)。
|
||||
|
||||
- For the provider URL: Use `https://token.actions.githubusercontent.com`
|
||||
- For the "Audience": Use `sts.amazonaws.com` if you are using the [official action](https://github.com/aws-actions/configure-aws-credentials).
|
||||
- 对于提供商 URL：使用 `https://token.actions.githubusercontent.com`
|
||||
- 对于“受众”：如果您使用的是[官方操作](https://github.com/aws-actions/configure-aws-credentials)，请使用 `sts.amazonaws.com`。
|
||||
|
||||
### Configuring the role and trust policy
|
||||
### 配置角色和信任策略
|
||||
|
||||
To configure the role and trust in IAM, see the AWS documentation for ["Assuming a Role"](https://github.com/aws-actions/configure-aws-credentials#assuming-a-role) and ["Creating a role for web identity or OpenID connect federation"](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html).
|
||||
要在 IAM 中配置角色和信任，请参阅 AWS 文档中的[“假定角色”](https://github.com/aws-actions/configure-aws-credentials#assuming-a-role)和[“为 Web 身份或 OpenID Connect Federation 创建角色”](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html)。
|
||||
|
||||
Edit the trust relationship to add the `sub` field to the validation conditions. 例如：
|
||||
编辑信任关系以将 `sub` 字段添加到验证条件。 例如：
|
||||
|
||||
```json{:copy}
|
||||
"Condition": {
|
||||
@@ -53,19 +53,19 @@ Edit the trust relationship to add the `sub` field to the validation conditions.
|
||||
|
||||
要更新 OIDC 的工作流程，您需要对 YAML 进行两项更改：
|
||||
1. 为令牌添加权限设置。
|
||||
2. Use the [`aws-actions/configure-aws-credentials`](https://github.com/aws-actions/configure-aws-credentials) action to exchange the OIDC token (JWT) for a cloud access token.
|
||||
2. 使用 [`aws-actions/configure-aws-credentials`](https://github.com/aws-actions/configure-aws-credentials) 操作将 OIDC 令牌 (JWT) 交换为云访问令牌。
|
||||
|
||||
### 添加权限设置
|
||||
|
||||
{% data reusables.actions.oidc-permissions-token %}
|
||||
|
||||
### Requesting the access token
|
||||
### 请求访问令牌
|
||||
|
||||
The `aws-actions/configure-aws-credentials` action receives a JWT from the {% data variables.product.prodname_dotcom %} OIDC provider, and then requests an access token from AWS. For more information, see the AWS [documentation](https://github.com/aws-actions/configure-aws-credentials).
|
||||
`aws-actions/configure-aws-credentials` 操作从 {% data variables.product.prodname_dotcom %} OIDC 提供商接收 JWT，然后从 AWS 请求访问令牌。 更多信息请参阅 AWS [文档](https://github.com/aws-actions/configure-aws-credentials)。
|
||||
|
||||
- `<example-bucket-name>`: Add the name of your S3 bucket here.
|
||||
- `<role-to-assume>`: Replace the example with your AWS role.
|
||||
- `<example-aws-region>`: Add the name of your AWS region here.
|
||||
- `<example-bucket-name>`：在此处添加 S3 存储桶的名称。
|
||||
- `<role-to-assume>`：将示例替换为您的 AWS 角色。
|
||||
- `<example-aws-region>`：在此处添加您的 AWS 区域的名称。
|
||||
|
||||
```yaml{:copy}
|
||||
# Sample workflow to access AWS resources when workflow is tied to branch
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Configuring OpenID Connect in Azure
|
||||
shortTitle: Configuring OpenID Connect in Azure
|
||||
intro: Use OpenID Connect within your workflows to authenticate with Azure.
|
||||
title: 在 Azure 中配置 OpenID Connect
|
||||
shortTitle: 在 Azure 中配置 OpenID Connect
|
||||
intro: 在工作流程中使用 OpenID Connect 向 Azure 进行身份验证。
|
||||
miniTocMaxHeadingLevel: 3
|
||||
versions:
|
||||
fpt: '*'
|
||||
@@ -17,9 +17,9 @@ topics:
|
||||
|
||||
## 概览
|
||||
|
||||
OpenID Connect (OIDC) allows your {% data variables.product.prodname_actions %} workflows to access resources in Azure, without needing to store the Azure credentials as long-lived {% data variables.product.prodname_dotcom %} secrets.
|
||||
OpenID Connect (OIDC) 允许您的 {% data variables.product.prodname_actions %} 工作流程访问 Azure 中的资源，而无需将任何 Azure 凭据存储为长期 {% data variables.product.prodname_dotcom %} 机密。
|
||||
|
||||
This guide gives an overview of how to configure Azure to trust {% data variables.product.prodname_dotcom %}'s OIDC as a federated identity, and includes a workflow example for the [`azure/login`](https://github.com/Azure/login) action that uses tokens to authenticate to Azure and access resources.
|
||||
本指南概述了如何配置 Azure 信任 {% data variables.product.prodname_dotcom %} 的 OIDC 作为联合标识，并包括 [`azure/login`](https://github.com/Azure/login) 操作的工作流程示例，该操作使用令牌向 Azure 进行身份验证和访问资源。
|
||||
|
||||
## 基本要求
|
||||
|
||||
@@ -27,36 +27,36 @@ This guide gives an overview of how to configure Azure to trust {% data variable
|
||||
|
||||
{% data reusables.actions.oidc-security-notice %}
|
||||
|
||||
## Adding the Federated Credentials to Azure
|
||||
## 将联合凭据添加到 Azure
|
||||
|
||||
{% data variables.product.prodname_dotcom %}'s OIDC provider works with Azure's workload identity federation. For an overview, see Microsoft's documentation at "[Workload identity federation](https://docs.microsoft.com/en-us/azure/active-directory/develop/workload-identity-federation)."
|
||||
{% data variables.product.prodname_dotcom %} 的 OIDC 提供商与 Azure 的工作负载联合身份验证配合使用。 有关概述，请参阅 Microsoft 的文档“[工作负载联合身份验证](https://docs.microsoft.com/en-us/azure/active-directory/develop/workload-identity-federation)”。
|
||||
|
||||
To configure the OIDC identity provider in Azure, you will need to perform the following configuration. For instructions on making these changes, refer to [the Azure documentation](https://docs.microsoft.com/en-us/azure/developer/github/connect-from-azure).
|
||||
要在 Azure 中配置 OIDC 身份提供商，您需要执行以下配置。 有关进行这些更改的说明，请参阅 [Azure 文档](https://docs.microsoft.com/en-us/azure/developer/github/connect-from-azure)。
|
||||
|
||||
1. Create an Azure Active Directory application and a service principal.
|
||||
2. Add federated credentials for the Azure Active Directory application.
|
||||
3. Create {% data variables.product.prodname_dotcom %} secrets for storing Azure configuration.
|
||||
1. 创建 Azure Active Directory 应用程序和服务主体。
|
||||
2. 为 Azure Active Directory 应用程序添加联合凭据。
|
||||
3. 创建用于存储 Azure 配置的 {% data variables.product.prodname_dotcom %} 机密。
|
||||
|
||||
Additional guidance for configuring the identity provider:
|
||||
配置身份提供商的附加指导：
|
||||
|
||||
- For security hardening, make sure you've reviewed ["Configuring the OIDC trust with the cloud"](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-oidc-trust-with-the-cloud). For an example, see ["Configuring the subject in your cloud provider"](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-subject-in-your-cloud-provider).
|
||||
- For the `audience` setting, `api://AzureADTokenExchange` is the recommended value, but you can also specify other values here.
|
||||
- 为强化安全，请确保您已查看[“使用云配置 OIDC 信任”](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-oidc-trust-with-the-cloud)。 有关示例，请参阅[“在云提供商中配置主题”](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-subject-in-your-cloud-provider)。
|
||||
- 对于`受众`设置，建议的值为 `api://AzureADTokenExchange`，但您也可以在此处指定其他值。
|
||||
|
||||
## 更新 {% data variables.product.prodname_actions %} 工作流程
|
||||
|
||||
要更新 OIDC 的工作流程，您需要对 YAML 进行两项更改：
|
||||
1. 为令牌添加权限设置。
|
||||
2. Use the [`azure/login`](https://github.com/Azure/login) action to exchange the OIDC token (JWT) for a cloud access token.
|
||||
2. 使用 [`azure/login`](https://github.com/Azure/login) 操作将 OIDC 令牌 (JWT) 交换为云访问令牌。
|
||||
|
||||
### 添加权限设置
|
||||
|
||||
{% data reusables.actions.oidc-permissions-token %}
|
||||
|
||||
### Requesting the access token
|
||||
### 请求访问令牌
|
||||
|
||||
The [`azure/login`](https://github.com/Azure/login) action receives a JWT from the {% data variables.product.prodname_dotcom %} OIDC provider, and then requests an access token from Azure. For more information, see the [`azure/login`](https://github.com/Azure/login) documentation.
|
||||
[`azure/login`](https://github.com/Azure/login) 操作从 {% data variables.product.prodname_dotcom %} OIDC 提供商接收 JWT，然后从 Azure 请求访问令牌。 更多信息请参阅 [`azure/login`](https://github.com/Azure/login) 文档。
|
||||
|
||||
The following example exchanges an OIDC ID token with Azure to receive an access token, which can then be used to access cloud resources.
|
||||
以下示例将 OIDC ID 令牌与 Azure 交换以接收访问令牌，然后可以使用该令牌访问云资源。
|
||||
|
||||
{% raw %}
|
||||
```yaml{:copy}
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Configuring OpenID Connect in Google Cloud Platform
|
||||
shortTitle: Configuring OpenID Connect in Google Cloud Platform
|
||||
intro: Use OpenID Connect within your workflows to authenticate with Google Cloud Platform.
|
||||
title: 在 Google Cloud Platform 中配置 OpenID Connect
|
||||
shortTitle: 在 Google Cloud Platform 中配置 OpenID Connect
|
||||
intro: 在工作流程中使用 OpenID Connect 向 Google Cloud 平台进行身份验证。
|
||||
miniTocMaxHeadingLevel: 3
|
||||
versions:
|
||||
fpt: '*'
|
||||
@@ -17,9 +17,9 @@ topics:
|
||||
|
||||
## 概览
|
||||
|
||||
OpenID Connect (OIDC) allows your {% data variables.product.prodname_actions %} workflows to access resources in Google Cloud Platform (GCP), without needing to store the GCP credentials as long-lived {% data variables.product.prodname_dotcom %} secrets.
|
||||
OpenID Connect (OIDC) 允许您的 {% data variables.product.prodname_actions %} 工作流程访问 Google Cloud 平台中的资源，而无需将任何 GCP 凭据存储为长期 {% data variables.product.prodname_dotcom %} 机密。
|
||||
|
||||
This guide gives an overview of how to configure GCP to trust {% data variables.product.prodname_dotcom %}'s OIDC as a federated identity, and includes a workflow example for the [`google-github-actions/auth`](https://github.com/google-github-actions/auth) action that uses tokens to authenticate to GCP and access resources.
|
||||
本指南概述了如何配置 GCP 信任 {% data variables.product.prodname_dotcom %} 的 OIDC 作为联合标识，并包括 [`google-github-actions/auth`](https://github.com/google-github-actions/auth) 操作的工作流程示例，该操作使用令牌向 GCP 进行身份验证和访问资源。
|
||||
|
||||
## 基本要求
|
||||
|
||||
@@ -27,41 +27,41 @@ This guide gives an overview of how to configure GCP to trust {% data variables.
|
||||
|
||||
{% data reusables.actions.oidc-security-notice %}
|
||||
|
||||
## Adding a Google Cloud Workload Identity Provider
|
||||
## 添加 Google Cloud 工作负载身份提供商
|
||||
|
||||
To configure the OIDC identity provider in GCP, you will need to perform the following configuration. For instructions on making these changes, refer to [the GCP documentation](https://github.com/google-github-actions/auth).
|
||||
要在 GCP 中配置 OIDC 身份提供商，您需要执行以下配置。 有关进行这些更改的说明，请参阅 [GCP 文档](https://github.com/google-github-actions/auth)。
|
||||
|
||||
1. Create a new identity pool.
|
||||
2. Configure the mapping and add conditions.
|
||||
3. Connect the new pool to a service account.
|
||||
1. 创建新的身份池。
|
||||
2. 配置映射并添加条件。
|
||||
3. 将新池连接到服务帐户。
|
||||
|
||||
Additional guidance for configuring the identity provider:
|
||||
配置身份提供商的附加指导：
|
||||
|
||||
- For security hardening, make sure you've reviewed ["Configuring the OIDC trust with the cloud"](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-oidc-trust-with-the-cloud). For an example, see ["Configuring the subject in your cloud provider"](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-subject-in-your-cloud-provider).
|
||||
- For the service account to be available for configuration, it needs to be assigned to the `roles/iam.workloadIdentityUser` role. For more information, see [the GCP documentation](https://cloud.google.com/iam/docs/workload-identity-federation?_ga=2.114275588.-285296507.1634918453#conditions).
|
||||
- The Issuer URL to use: `https://token.actions.githubusercontent.com`
|
||||
- 为强化安全，请确保您已查看[“使用云配置 OIDC 信任”](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-oidc-trust-with-the-cloud)。 有关示例，请参阅[“在云提供商中配置主题”](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-subject-in-your-cloud-provider)。
|
||||
- 要使服务帐户可用于配置，需要将其分配给 `roles/iam.workloadIdentityUser` 角色。 更多信息请参阅 [GCP 文档](https://cloud.google.com/iam/docs/workload-identity-federation?_ga=2.114275588.-285296507.1634918453#conditions)。
|
||||
- 要使用的颁发者 URL：`https://token.actions.githubusercontent.com`
|
||||
|
||||
## 更新 {% data variables.product.prodname_actions %} 工作流程
|
||||
|
||||
要更新 OIDC 的工作流程，您需要对 YAML 进行两项更改：
|
||||
1. 为令牌添加权限设置。
|
||||
2. Use the [`google-github-actions/auth`](https://github.com/google-github-actions/auth) action to exchange the OIDC token (JWT) for a cloud access token.
|
||||
2. 使用 [`google-github-actions/auth`](https://github.com/google-github-actions/auth) 操作将 OIDC 令牌 (JWT) 交换为云访问令牌。
|
||||
|
||||
### 添加权限设置
|
||||
|
||||
{% data reusables.actions.oidc-permissions-token %}
|
||||
|
||||
### Requesting the access token
|
||||
### 请求访问令牌
|
||||
|
||||
The `google-github-actions/auth` action receives a JWT from the {% data variables.product.prodname_dotcom %} OIDC provider, and then requests an access token from GCP. For more information, see the GCP [documentation](https://github.com/google-github-actions/auth).
|
||||
`google-github-actions/auth` 操作从 {% data variables.product.prodname_dotcom %} OIDC 提供商接收 JWT，然后从 GCP 请求访问令牌。 更多信息请参阅 GCP [文档](https://github.com/google-github-actions/auth)。
|
||||
|
||||
This example has a job called `Get_OIDC_ID_token` that uses actions to request a list of services from GCP.
|
||||
此示例有一个名为 `Get_OIDC_ID_token` 的作业，该作业使用操作从 GCP 请求服务列表。
|
||||
|
||||
- `<example-workload-identity-provider>`: Replace this with the path to your identity provider in GCP. For example, `projects/<example-project-id>/locations/global/workloadIdentityPools/<name-of-pool/providers/<name-of-provider>`
|
||||
- `<example-service-account>`: Replace this with the name of your service account in GCP.
|
||||
- `<project-id>`: Replace this with the ID of your GCP project.
|
||||
- `<example-workload-identity-provider>`：将此值替换为指向 GCP 中身份提供商的路径。 例如 `projects/<example-project-id>/locations/global/workloadIdentityPools/<name-of-pool/providers/<name-of-provider>`
|
||||
- `<example-service-account>`：将此值替换为您在 GCP 中的服务帐户的名称。
|
||||
- `<project-id>`：将此值替换为 GCP 项目的 ID。
|
||||
|
||||
This action exchanges a {% data variables.product.prodname_dotcom %} OIDC token for a Google Cloud access token, using [Workload Identity Federation](https://cloud.google.com/iam/docs/workload-identity-federation).
|
||||
此操作使用[工作负载联合身份验证](https://cloud.google.com/iam/docs/workload-identity-federation)将 {% data variables.product.prodname_dotcom %} OIDC 令牌交换为 Google Cloud 访问令牌。
|
||||
|
||||
{% raw %}
|
||||
```yaml{:copy}
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Configuring OpenID Connect in HashiCorp Vault
|
||||
shortTitle: Configuring OpenID Connect in HashiCorp Vault
|
||||
intro: Use OpenID Connect within your workflows to authenticate with HashiCorp Vault.
|
||||
title: 在 HashiCorp Vault 中配置 OpenID Connect
|
||||
shortTitle: 在 HashiCorp Vault 中配置 OpenID Connect
|
||||
intro: 在工作流程中使用 OpenID Connect 通过 HashiCorp Vault 进行身份验证。
|
||||
miniTocMaxHeadingLevel: 3
|
||||
versions:
|
||||
fpt: '*'
|
||||
@@ -17,9 +17,9 @@ topics:
|
||||
|
||||
## 概览
|
||||
|
||||
OpenID Connect (OIDC) allows your {% data variables.product.prodname_actions %} workflows to authenticate with a HashiCorp Vault to retrieve secrets.
|
||||
OpenID Connect (OIDC) 允许您的 {% data variables.product.prodname_actions %} 工作流程使用 HashiCorp Vault 进行身份验证以检索机密。
|
||||
|
||||
This guide gives an overview of how to configure HashiCorp Vault to trust {% data variables.product.prodname_dotcom %}'s OIDC as a federated identity, and demonstrates how to use this configuration in the [hashicorp/vault-action](https://github.com/hashicorp/vault-action) action to retrieve secrets from HashiCorp Vault.
|
||||
本指南概述如何配置 HashiCorp Vault 信任 {% data variables.product.prodname_dotcom %} 的 OIDC 作为联合身份，并演示如何在 [hashicorp/vault-action](https://github.com/hashicorp/vault-action) 操作中使用此配置从 HashiCorp Vault 检索机密。
|
||||
|
||||
## 基本要求
|
||||
|
||||
@@ -27,45 +27,45 @@ This guide gives an overview of how to configure HashiCorp Vault to trust {% dat
|
||||
|
||||
{% data reusables.actions.oidc-security-notice %}
|
||||
|
||||
## Adding the identity provider to HashiCorp Vault
|
||||
## 将身份提供商添加到 HashiCorp Vault
|
||||
|
||||
To use OIDC with HashiCorp Vault, you will need to add a trust configuration for the {% data variables.product.prodname_dotcom %} OIDC provider. For more information, see the HashiCorp Vault [documentation](https://www.vaultproject.io/docs/auth/jwt).
|
||||
要将 OIDC 与 HashiCorp Vault 配合使用，您需要为 {% data variables.product.prodname_dotcom %} OIDC 提供商添加信任配置。 更多信息请参阅 HashiCorp Vault [文档](https://www.vaultproject.io/docs/auth/jwt)。
|
||||
|
||||
Configure the vault to accept JSON Web Tokens (JWT) for authentication:
|
||||
- For the `oidc_discovery_url`, use `https://token.actions.githubusercontent.com`
|
||||
- For `bound_issuer`, use `https://token.actions.githubusercontent.com`
|
||||
- Ensure that `bound_subject` is correctly defined for your security requirements. For more information, see ["Configuring the OIDC trust with the cloud"](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-oidc-trust-with-the-cloud) and [`hashicorp/vault-action`](https://github.com/hashicorp/vault-action).
|
||||
配置 Vault 接受 JSON Web 令牌 (JWT) 进行身份验证：
|
||||
- 对于 `oidc_discovery_url`，请使用 `https://token.actions.githubusercontent.com`
|
||||
- 对于 `bound_issuer`，请使用 `https://token.actions.githubusercontent.com`
|
||||
- 确保针对您的安全要求正确定义了 `bound_subject`。 更多信息请参阅[“使用云配置 OIDC 信任”](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-oidc-trust-with-the-cloud)和 [`hashicorp/vault-action`](https://github.com/hashicorp/vault-action)。
|
||||
|
||||
## 更新 {% data variables.product.prodname_actions %} 工作流程
|
||||
|
||||
要更新 OIDC 的工作流程，您需要对 YAML 进行两项更改：
|
||||
1. 为令牌添加权限设置。
|
||||
2. Use the [`hashicorp/vault-action`](https://github.com/hashicorp/vault-action) action to exchange the OIDC token (JWT) for a cloud access token.
|
||||
2. 使用 [`hashicorp/vault-action`](https://github.com/hashicorp/vault-action) 操作将 OIDC 令牌 (JWT) 交换为云访问令牌。
|
||||
|
||||
|
||||
To add OIDC integration to your workflows that allow them to access secrets in Vault, you will need to add the following code changes:
|
||||
要将 OIDC 集成添加到您的工作流程中，以允许他们访问 Vault 中的密钥，您需要添加以下代码更改：
|
||||
|
||||
- Grant permission to fetch the token from the {% data variables.product.prodname_dotcom %} OIDC provider:
|
||||
- The workflow needs `permissions:` settings with the `id-token` value set to `write`. This lets you fetch the OIDC token from every job in the workflow.
|
||||
- Request the JWT from the {% data variables.product.prodname_dotcom %} OIDC provider, and present it to HashiCorp Vault to receive an access token:
|
||||
- You could use the [Actions toolkit](https://github.com/actions/toolkit/) to fetch the tokens for your job, or you can use the [`hashicorp/vault-action`](https://github.com/hashicorp/vault-action) action to fetch the JWT and receive the access token from the Vault.
|
||||
- 工作流需要 `permissions:` 设置将 `id-token` 值设为 `write`。 This lets you fetch the OIDC token from every job in the workflow.
|
||||
- 向 {% data variables.product.prodname_dotcom %} OIDC 提供商请求 JWT，并将其提供给 HashiCorp Vault 以接收访问令牌：
|
||||
- 您可以使用[操作工具包](https://github.com/actions/toolkit/)来获取作业的令牌，也可以使用 [`hashicorp/vault-action`](https://github.com/hashicorp/vault-action) 操作来获取 JWT 并从 Vault 接收访问令牌。
|
||||
|
||||
This example demonstrates how to use OIDC with the official action to request a secret from HashiCorp Vault.
|
||||
此示例演示如何将 OIDC 与官方操作结合使用，以向 HashiCorp Vault 请求机密。
|
||||
|
||||
### 添加权限设置
|
||||
|
||||
{% data reusables.actions.oidc-permissions-token %}
|
||||
|
||||
### Requesting the access token
|
||||
### 请求访问令牌
|
||||
|
||||
The `hashicorp/vault-action` action receives a JWT from the {% data variables.product.prodname_dotcom %} OIDC provider, and then requests an access token from your HashiCorp Vault instance to retrieve secrets. For more information, see the HashiCorp Vault [documentation](https://github.com/hashicorp/vault-action).
|
||||
`hashicorp/vault-action` 操作从 {% data variables.product.prodname_dotcom %} OIDC 提供商接收 JWT，然后从 HashiCorp Vault 实例请求访问令牌以检索机密。 更多信息请参阅 HashiCorp Vault [文档](https://github.com/hashicorp/vault-action)。
|
||||
|
||||
This example demonstrates how to create a job that requests a secret from HashiCorp Vault.
|
||||
此示例演示如何创建从 HashiCorp Vault请求机密的作业。
|
||||
|
||||
- `<Vault URL>`: Replace this with the URL of your HashiCorp Vault.
|
||||
- `<Role name>`: Replace this with the role you've set in the HashiCorp Vault trust relationship.
|
||||
- `<Audience>`: Replace this with the audience you've defined in the HashiCorp Vault trust relationship.
|
||||
- `<Secret-Path>`: Replace this with the path to the secret you're retrieving from HashiCorp Vault. For example: `secret/data/ci npmToken`.
|
||||
- `<Vault URL>`：将此值替换为您的 HashiCorp Vault 的URL。
|
||||
- `<Role name>`：将此值替换为您在 HashiCorp Vault 信任关系中设置的角色。
|
||||
- `<Audience>`：将此值替换为您在 HashiCorp Vault 信任关系中定义的受众。
|
||||
- `<Secret-Path>`：将此值替换为您从 HashiCorp Vault 检索的机密的路径。 例如：`secret/data/ci npmToken`。
|
||||
|
||||
```yaml{:copy}
|
||||
jobs:
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Targeting different environments
|
||||
shortTitle: Targeting different environments
|
||||
title: 针对不同的环境
|
||||
shortTitle: 针对不同的环境
|
||||
intro: 您可以使用保护规则和机密配置环境。 引用环境的工作流程作业在运行或访问环境的机密之前，必须遵循环境的任何保护规则。
|
||||
versions:
|
||||
fpt: '*'
|
||||
|
||||
@@ -86,20 +86,20 @@ Environments are used to describe a general deployment target like `production`,
|
||||
1. 单击 **Save protection rules（保存保护规则）**。
|
||||
3. （可选）指定哪些分支可以部署到此环境。 有关可能值的详细信息，请参阅“[部署分支](#deployment-branches)”。
|
||||
1. 在 **Deployment branches（部署分支）**下拉列表中选择所需的选项。
|
||||
1. If you chose **Selected branches**, enter the branch name patterns that you want to allow.
|
||||
4. Optionally, add environment secrets. These secrets are only available to workflow jobs that use the environment. Additionally, workflow jobs that use this environment can only access these secrets after any configured rules (for example, required reviewers) pass. 有关机密的更多信息，请参阅“[加密密码](/actions/reference/encrypted-secrets)”。
|
||||
1. Under **Environment secrets**, click **Add Secret**.
|
||||
1. Enter the secret name.
|
||||
1. Enter the secret value.
|
||||
1. 如果选择 **Selected branches（选定分支）**，请输入要允许的分支名称模式。
|
||||
4. （可选）添加环境机密。 这些机密仅可用于使用环境的工作流程作业。 此外，使用此环境的工作流程作业只能在任何配置的规则（例如，必需的审查者）通过后才能访问这些机密。 有关机密的更多信息，请参阅“[加密密码](/actions/reference/encrypted-secrets)”。
|
||||
1. 在 **Environment secrets（环境机密）**下，单击 **Add Secret（添加机密）**。
|
||||
1. 输入机密名称。
|
||||
1. 输入机密值。
|
||||
1. 单击 **Add secret（添加密码）**。
|
||||
|
||||
{% ifversion fpt or ghae or ghes > 3.1 or ghec %}您也可以通过 REST API 创建和配置环境。 更多信息请参阅“[环境](/rest/reference/repos#environments)”和“[密码](/rest/reference/actions#secrets)”。{% endif %}
|
||||
|
||||
运行引用不存在的环境的工作流程将使用引用的名称创建环境。 新创建的环境将不配置任何保护规则或机密。 可在仓库中编辑工作流程的任何人都可以通过工作流程文件创建环境，但只有仓库管理员才能配置环境。
|
||||
|
||||
## Using an environment
|
||||
## 使用环境
|
||||
|
||||
工作流程中的每个作业都可以引用单个环境。 在将引用环境的作业发送到运行器之前，必须通过为环境配置的任何保护规则。 The job can access the environment's secrets only after the job is sent to a runner.
|
||||
工作流程中的每个作业都可以引用单个环境。 在将引用环境的作业发送到运行器之前，必须通过为环境配置的任何保护规则。 只有在将作业发送给运行器后，作业才能访问环境的机密。
|
||||
|
||||
当工作流程引用环境时，环境将显示在仓库的部署中。 有关查看当前和以前的部署的详细信息，请参阅“[查看部署历史记录](/developers/overview/viewing-deployment-history)”。
|
||||
|
||||
@@ -119,12 +119,12 @@ Environments are used to describe a general deployment target like `production`,
|
||||
|
||||
{% ifversion fpt or ghae or ghes > 3.1 or ghec %}您也可以通过 REST API 删除环境。 更多信息请参阅“[环境](/rest/reference/repos#environments)”。{% endif %}
|
||||
|
||||
## How environments relate to deployments
|
||||
## 环境与部署的关系
|
||||
|
||||
{% data reusables.actions.environment-deployment-event %}
|
||||
|
||||
You can access these objects through the REST API or GraphQL API. You can also subscribe to these webhook events. For more information, see "[Repositories](/rest/reference/repos#deployments)" (REST API), "[Objects]({% ifversion ghec %}/free-pro-team@latest{% endif %}/graphql/reference/objects#deployment)" (GraphQL API), or "[Webhook events and payloads](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#deployment)."
|
||||
您可以通过 REST API 或 GraphQL API 访问这些对象。 您还可以订阅这些 web 挂钩事件。 更多信息请参阅“[存储库](/rest/reference/repos#deployments)”（REST API）、“[对象]({% ifversion ghec %}/free-pro-team@latest{% endif %}/graphql/reference/objects#deployment)”（GraphQL API）或“[web 挂钩事件和有效负载](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#deployment)”。
|
||||
|
||||
## 后续步骤
|
||||
|
||||
{% data variables.product.prodname_actions %} provides several features for managing your deployments. For more information, see "[Deploying with GitHub Actions](/actions/deployment/deploying-with-github-actions)."
|
||||
{% data variables.product.prodname_actions %} 具有多个用于管理部署的功能。 更多信息请参阅“[使用 GitHub Actions 进行部署](/actions/deployment/deploying-with-github-actions)”。
|
||||
|
||||
@@ -2,6 +2,7 @@
|
||||
title: GitHub Actions 的工作流程命令
|
||||
shortTitle: 工作流程命令
|
||||
intro: 您可以在工作流程或操作代码中运行 shell 命令时使用工作流程命令。
|
||||
defaultTool: bash
|
||||
redirect_from:
|
||||
- /articles/development-tools-for-github-actions
|
||||
- /github/automating-your-workflow-with-github-actions/development-tools-for-github-actions
|
||||
@@ -26,10 +27,24 @@ versions:
|
||||
|
||||
大多数工作流程命令使用特定格式的 `echo` 命令，而其他工作流程则通过写入文件被调用。 更多信息请参阅“[环境文件](#environment-files)”。
|
||||
|
||||
``` bash
|
||||
### 示例
|
||||
|
||||
{% bash %}
|
||||
|
||||
```bash{:copy}
|
||||
echo "::workflow-command parameter1={data},parameter2={data}::{command value}"
|
||||
```
|
||||
|
||||
{% endbash %}
|
||||
|
||||
{% powershell %}
|
||||
|
||||
```pwsh{:copy}
|
||||
Write-Output "::workflow-command parameter1={data},parameter2={data}::{command value}"
|
||||
```
|
||||
|
||||
{% endpowershell %}
|
||||
|
||||
{% note %}
|
||||
|
||||
**注意：**工作流程命令和参数名称不区分大小写。
|
||||
@@ -46,14 +61,18 @@ echo "::workflow-command parameter1={data},parameter2={data}::{command value}"
|
||||
|
||||
[actions/toolkit](https://github.com/actions/toolkit) 包括一些可以作为工作流程命令执行的功能。 使用 `::` 语法来运行您的 YAML 文件中的工作流程命令；然后，通过 `stdout` 将这些命令发送给运行器。 例如，不使用代码来设置环境变量，如下所示：
|
||||
|
||||
```javascript
|
||||
```javascript{:copy}
|
||||
core.setOutput('SELECTED_COLOR', 'green');
|
||||
```
|
||||
|
||||
### Example: Setting a value
|
||||
|
||||
您可以在工作流程中使用 `set-output` 命令来设置相同的值：
|
||||
|
||||
{% bash %}
|
||||
|
||||
{% raw %}
|
||||
``` yaml
|
||||
```yaml{:copy}
|
||||
- name: Set selected color
|
||||
run: echo '::set-output name=SELECTED_COLOR::green'
|
||||
id: random-color-generator
|
||||
@@ -62,6 +81,22 @@ core.setOutput('SELECTED_COLOR', 'green');
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
{% endbash %}
|
||||
|
||||
{% powershell %}
|
||||
|
||||
{% raw %}
|
||||
```yaml{:copy}
|
||||
- name: Set selected color
|
||||
run: Write-Output "::set-output name=SELECTED_COLOR::green"
|
||||
id: random-color-generator
|
||||
- name: Get color
|
||||
run: Write-Output "The selected color is ${{ steps.random-color-generator.outputs.SELECTED_COLOR }}"
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
{% endpowershell %}
|
||||
|
||||
下表显示了在工作流程中可用的工具包功能：
|
||||
|
||||
| 工具包函数 | 等效工作流程命令 |
|
||||
@@ -86,186 +121,336 @@ core.setOutput('SELECTED_COLOR', 'green');
|
||||
|
||||
## 设置输出参数
|
||||
|
||||
```
|
||||
设置操作的输出参数。
|
||||
|
||||
```{:copy}
|
||||
::set-output name={name}::{value}
|
||||
```
|
||||
|
||||
设置操作的输出参数。
|
||||
|
||||
（可选）您也可以在操作的元数据文件中声明输出参数。 更多信息请参阅“[{% data variables.product.prodname_actions %} 的元数据语法](/articles/metadata-syntax-for-github-actions#outputs-for-docker-container-and-javascript-actions)”。
|
||||
|
||||
### 示例
|
||||
### Example: Setting an output parameter
|
||||
|
||||
``` bash
|
||||
{% bash %}
|
||||
|
||||
```bash{:copy}
|
||||
echo "::set-output name=action_fruit::strawberry"
|
||||
```
|
||||
|
||||
## 设置调试消息
|
||||
{% endbash %}
|
||||
|
||||
{% powershell %}
|
||||
|
||||
```pwsh{:copy}
|
||||
Write-Output "::set-output name=action_fruit::strawberry"
|
||||
```
|
||||
::debug::{message}
|
||||
```
|
||||
|
||||
{% endpowershell %}
|
||||
|
||||
## 设置调试消息
|
||||
|
||||
将调试消息打印到日志。 您可以创建名为 `ACTIONS_STEP_DEBUG`、值为 `true` 的密码，才能在日志中查看通过此命令设置的调试消息。 更多信息请参阅“[启用调试日志记录](/actions/managing-workflow-runs/enabling-debug-logging)”。
|
||||
|
||||
### 示例
|
||||
```{:copy}
|
||||
::debug::{message}
|
||||
```
|
||||
|
||||
``` bash
|
||||
### Example: Setting a debug message
|
||||
|
||||
{% bash %}
|
||||
|
||||
```bash{:copy}
|
||||
echo "::debug::Set the Octocat variable"
|
||||
```
|
||||
|
||||
{% endbash %}
|
||||
|
||||
{% powershell %}
|
||||
|
||||
```pwsh{:copy}
|
||||
Write-Output "::debug::Set the Octocat variable"
|
||||
```
|
||||
|
||||
{% endpowershell %}
|
||||
|
||||
{% ifversion fpt or ghes > 3.2 or ghae-issue-4929 or ghec %}
|
||||
|
||||
## 设置通知消息
|
||||
|
||||
```
|
||||
创建通知消息并将该消息打印到日志。 {% data reusables.actions.message-annotation-explanation %}
|
||||
|
||||
```{:copy}
|
||||
::notice file={name},line={line},endLine={endLine},title={title}::{message}
|
||||
```
|
||||
|
||||
创建通知消息并将该消息打印到日志。 {% data reusables.actions.message-annotation-explanation %}
|
||||
|
||||
{% data reusables.actions.message-parameters %}
|
||||
|
||||
### 示例
|
||||
### Example: Setting a notice message
|
||||
|
||||
``` bash
|
||||
{% bash %}
|
||||
|
||||
```bash{:copy}
|
||||
echo "::notice file=app.js,line=1,col=5,endColumn=7::Missing semicolon"
|
||||
```
|
||||
|
||||
{% endbash %}
|
||||
|
||||
{% powershell %}
|
||||
|
||||
```pwsh{:copy}
|
||||
Write-Output "::notice file=app.js,line=1,col=5,endColumn=7::Missing semicolon"
|
||||
```
|
||||
|
||||
{% endpowershell %}
|
||||
{% endif %}
|
||||
|
||||
## 设置警告消息
|
||||
|
||||
```
|
||||
创建警告消息并将该消息打印到日志。 {% data reusables.actions.message-annotation-explanation %}
|
||||
|
||||
```{:copy}
|
||||
::warning file={name},line={line},endLine={endLine},title={title}::{message}
|
||||
```
|
||||
|
||||
创建警告消息并将该消息打印到日志。 {% data reusables.actions.message-annotation-explanation %}
|
||||
|
||||
{% data reusables.actions.message-parameters %}
|
||||
|
||||
### 示例
|
||||
### Example: Setting a warning message
|
||||
|
||||
``` bash
|
||||
{% bash %}
|
||||
|
||||
```bash{:copy}
|
||||
echo "::warning file=app.js,line=1,col=5,endColumn=7::Missing semicolon"
|
||||
```
|
||||
{% endbash %}
|
||||
|
||||
{% powershell %}
|
||||
|
||||
```pwsh{:copy}
|
||||
Write-Output "::warning file=app.js,line=1,col=5,endColumn=7::Missing semicolon"
|
||||
```
|
||||
|
||||
{% endpowershell %}
|
||||
|
||||
## 设置错误消息
|
||||
|
||||
```
|
||||
创建错误消息并将该消息打印到日志。 {% data reusables.actions.message-annotation-explanation %}
|
||||
|
||||
```{:copy}
|
||||
::error file={name},line={line},endLine={endLine},title={title}::{message}
|
||||
```
|
||||
|
||||
创建错误消息并将该消息打印到日志。 {% data reusables.actions.message-annotation-explanation %}
|
||||
|
||||
{% data reusables.actions.message-parameters %}
|
||||
|
||||
### 示例
|
||||
### Example: Setting an error message
|
||||
|
||||
``` bash
|
||||
{% bash %}
|
||||
|
||||
```bash{:copy}
|
||||
echo "::error file=app.js,line=1,col=5,endColumn=7::Missing semicolon"
|
||||
```
|
||||
|
||||
{% endbash %}
|
||||
|
||||
{% powershell %}
|
||||
|
||||
```pwsh{:copy}
|
||||
Write-Output "::error file=app.js,line=1,col=5,endColumn=7::Missing semicolon"
|
||||
```
|
||||
|
||||
{% endpowershell %}
|
||||
## 对日志行分组
|
||||
|
||||
```
|
||||
在日志中创建一个可扩展的组。 要创建组，请使用 `group` 命令并指定 `title`。 打印到 `group` 与 `endgroup` 命令之间日志的任何内容都会嵌套在日志中可扩展的条目内。
|
||||
|
||||
```{:copy}
|
||||
::group::{title}
|
||||
::endgroup::
|
||||
```
|
||||
|
||||
在日志中创建一个可扩展的组。 要创建组，请使用 `group` 命令并指定 `title`。 打印到 `group` 与 `endgroup` 命令之间日志的任何内容都会嵌套在日志中可扩展的条目内。
|
||||
### Example: Grouping log lines
|
||||
|
||||
### 示例
|
||||
{% bash %}
|
||||
|
||||
```bash
|
||||
echo "::group::My title"
|
||||
echo "Inside group"
|
||||
echo "::endgroup::"
|
||||
```yaml{:copy}
|
||||
jobs:
|
||||
bash-example:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Group of log lines
|
||||
run: |
|
||||
echo "::group::My title"
|
||||
echo "Inside group"
|
||||
echo "::endgroup::"
|
||||
```
|
||||
|
||||
{% endbash %}
|
||||
|
||||
{% powershell %}
|
||||
|
||||
```yaml{:copy}
|
||||
jobs:
|
||||
powershell-example:
|
||||
runs-on: windows-latest
|
||||
steps:
|
||||
- name: Group of log lines
|
||||
run: |
|
||||
Write-Output "::group::My title"
|
||||
Write-Output "Inside group"
|
||||
Write-Output "::endgroup::"
|
||||
```
|
||||
|
||||
{% endpowershell %}
|
||||
|
||||
|
||||
|
||||
## 在日志中屏蔽值
|
||||
|
||||
```
|
||||
```{:copy}
|
||||
::add-mask::{value}
|
||||
```
|
||||
|
||||
屏蔽值可阻止在日志中打印字符串或变量。 用空格分隔的每个屏蔽的词均替换为 `*` 字符。 您可以使用环境变量或字符串作为屏蔽的 `value`。
|
||||
|
||||
### 屏蔽字符串的示例
|
||||
### Example: Masking a string
|
||||
|
||||
当您在日志中打印 `"Mona The Octocat"` 时，您将看到 `"***"`。
|
||||
|
||||
```bash
|
||||
{% bash %}
|
||||
|
||||
```bash{:copy}
|
||||
echo "::add-mask::Mona The Octocat"
|
||||
```
|
||||
|
||||
### 屏蔽环境变量的示例
|
||||
{% endbash %}
|
||||
|
||||
{% powershell %}
|
||||
|
||||
```pwsh{:copy}
|
||||
Write-Output "::add-mask::Mona The Octocat"
|
||||
```
|
||||
|
||||
{% endpowershell %}
|
||||
|
||||
### Example: Masking an environment variable
|
||||
|
||||
当您在日志中打印变量 `MY_NAME` 或值 `"Mona The Octocat"` 时，您将看到 `"***"` 而不是 `"Mona The Octocat"`。
|
||||
|
||||
```bash
|
||||
MY_NAME="Mona The Octocat"
|
||||
echo "::add-mask::$MY_NAME"
|
||||
{% bash %}
|
||||
|
||||
```yaml{:copy}
|
||||
jobs:
|
||||
bash-example:
|
||||
runs-on: ubuntu-latest
|
||||
env:
|
||||
MY_NAME: "Mona The Octocat"
|
||||
steps:
|
||||
- name: bash-version
|
||||
run: echo "::add-mask::$MY_NAME"
|
||||
```
|
||||
|
||||
{% endbash %}
|
||||
|
||||
{% powershell %}
|
||||
|
||||
```yaml{:copy}
|
||||
jobs:
|
||||
powershell-example:
|
||||
runs-on: windows-latest
|
||||
env:
|
||||
MY_NAME: "Mona The Octocat"
|
||||
steps:
|
||||
- name: powershell-version
|
||||
run: Write-Output "::add-mask::$env:MY_NAME"
|
||||
```
|
||||
|
||||
{% endpowershell %}
|
||||
|
||||
## 停止和启动工作流程命令
|
||||
|
||||
`::stop-commands::{endtoken}`
|
||||
|
||||
停止处理任何工作流程命令。 此特殊命令可让您记录任何内容而不会意外运行工作流程命令。 例如，您可以停止记录以输出带有注释的整个脚本。
|
||||
|
||||
```{:copy}
|
||||
::stop-commands::{endtoken}
|
||||
```
|
||||
|
||||
要停止处理工作流程命令，请将唯一的令牌传递给 `stop-commands`。 要继续处理工作流程命令，请传递用于停止工作流程命令的同一令牌。
|
||||
|
||||
{% warning %}
|
||||
|
||||
**警告：** 请确保您使用的令牌是随机生成的，且对每次运行唯一。 如下面的示例所示，您可以为每次运行生成 `github.token` 的唯一哈希值。
|
||||
**警告：** 请确保您使用的令牌是随机生成的，且对每次运行唯一。
|
||||
|
||||
{% endwarning %}
|
||||
|
||||
```
|
||||
```{:copy}
|
||||
::{endtoken}::
|
||||
```
|
||||
|
||||
### 停止和启动工作流程命令的示例
|
||||
### Example: Stopping and starting workflow commands
|
||||
|
||||
{% bash %}
|
||||
|
||||
{% raw %}
|
||||
|
||||
```yaml
|
||||
```yaml{:copy}
|
||||
jobs:
|
||||
workflow-command-job:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: disable workflow commands
|
||||
- name: Disable workflow commands
|
||||
run: |
|
||||
echo '::warning:: this is a warning'
|
||||
echo "::stop-commands::`echo -n ${{ github.token }} | sha256sum | head -c 64`"
|
||||
echo '::warning:: this will NOT be a warning'
|
||||
echo "::`echo -n ${{ github.token }} | sha256sum | head -c 64`::"
|
||||
echo '::warning:: this is a warning again'
|
||||
echo '::warning:: This is a warning message, to demonstrate that commands are being processed.'
|
||||
stopMarker=$(uuidgen)
|
||||
echo "::stop-commands::$stopMarker"
|
||||
echo '::warning:: This will NOT be rendered as a warning, because stop-commands has been invoked.'
|
||||
echo "::$stopMarker::"
|
||||
echo '::warning:: This is a warning again, because stop-commands has been turned off.'
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
{% endbash %}
|
||||
|
||||
{% powershell %}
|
||||
|
||||
{% raw %}
|
||||
```yaml{:copy}
|
||||
jobs:
|
||||
workflow-command-job:
|
||||
runs-on: windows-latest
|
||||
steps:
|
||||
- name: Disable workflow commands
|
||||
run: |
|
||||
Write-Output '::warning:: This is a warning message, to demonstrate that commands are being processed.'
|
||||
$stopMarker = New-Guid
|
||||
Write-Output "::stop-commands::$stopMarker"
|
||||
Write-Output '::warning:: This will NOT be rendered as a warning, because stop-commands has been invoked.'
|
||||
Write-Output "::$stopMarker::"
|
||||
Write-Output '::warning:: This is a warning again, because stop-commands has been turned off.'
|
||||
```
|
||||
|
||||
{% endraw %}
|
||||
|
||||
{% endpowershell %}
|
||||
|
||||
## Echoing command outputs
|
||||
|
||||
```
|
||||
Enables or disables echoing of workflow commands. For example, if you use the `set-output` command in a workflow, it sets an output parameter but the workflow run's log does not show the command itself. If you enable command echoing, then the log shows the command, such as `::set-output name={name}::{value}`.
|
||||
|
||||
```{:copy}
|
||||
::echo::on
|
||||
::echo::off
|
||||
```
|
||||
|
||||
Enables or disables echoing of workflow commands. For example, if you use the `set-output` command in a workflow, it sets an output parameter but the workflow run's log does not show the command itself. If you enable command echoing, then the log shows the command, such as `::set-output name={name}::{value}`.
|
||||
|
||||
Command echoing is disabled by default. However, a workflow command is echoed if there are any errors processing the command.
|
||||
|
||||
The `add-mask`, `debug`, `warning`, and `error` commands do not support echoing because their outputs are already echoed to the log.
|
||||
|
||||
You can also enable command echoing globally by turning on step debug logging using the `ACTIONS_STEP_DEBUG` secret. For more information, see "[Enabling debug logging](/actions/managing-workflow-runs/enabling-debug-logging)". In contrast, the `echo` workflow command lets you enable command echoing at a more granular level, rather than enabling it for every workflow in a repository.
|
||||
|
||||
### Example toggling command echoing
|
||||
### Example: Toggling command echoing
|
||||
|
||||
```yaml
|
||||
{% bash %}
|
||||
|
||||
```yaml{:copy}
|
||||
jobs:
|
||||
workflow-command-job:
|
||||
runs-on: ubuntu-latest
|
||||
@@ -279,9 +464,29 @@ jobs:
|
||||
echo '::set-output name=action_echo::disabled'
|
||||
```
|
||||
|
||||
The step above prints the following lines to the log:
|
||||
{% endbash %}
|
||||
|
||||
{% powershell %}
|
||||
|
||||
```yaml{:copy}
|
||||
jobs:
|
||||
workflow-command-job:
|
||||
runs-on: windows-latest
|
||||
steps:
|
||||
- name: toggle workflow command echoing
|
||||
run: |
|
||||
write-output "::set-output name=action_echo::disabled"
|
||||
write-output "::echo::on"
|
||||
write-output "::set-output name=action_echo::enabled"
|
||||
write-output "::echo::off"
|
||||
write-output "::set-output name=action_echo::disabled"
|
||||
```
|
||||
|
||||
{% endpowershell %}
|
||||
|
||||
The example above prints the following lines to the log:
|
||||
|
||||
```{:copy}
|
||||
::set-output name=action_echo::enabled
|
||||
::echo::off
|
||||
```
|
||||
@@ -298,13 +503,13 @@ Only the second `set-output` and `echo` workflow commands are included in the lo
|
||||
|
||||
此示例使用 JavaScript 运行 `save-state` 命令。 由此生成的环境变量被命名为 `STATE_processID`，带 `12345` 的值：
|
||||
|
||||
``` javascript
|
||||
```javascript{:copy}
|
||||
console.log('::save-state name=processID::12345')
|
||||
```
|
||||
|
||||
然后，`STATE_processID` 变量将仅可被用于 `main` 操作下运行的清理脚本。 此示例在 `main` 中运行，并使用 JavaScript 显示分配给 `STATE_processID` 环境变量的值：
|
||||
|
||||
``` javascript
|
||||
```javascript{:copy}
|
||||
console.log("The running PID from the main action is: " + process.env.STATE_processID);
|
||||
```
|
||||
|
||||
@@ -312,37 +517,70 @@ console.log("The running PID from the main action is: " + process.env.STATE_pro
|
||||
|
||||
在工作流程执行期间，运行器生成可用于执行某些操作的临时文件。 这些文件的路径通过环境变量显示。 写入这些文件时，您需要使用 UTF-8 编码，以确保正确处理命令。 多个命令可以写入同一个文件，用换行符分隔。
|
||||
|
||||
{% warning %}
|
||||
{% powershell %}
|
||||
|
||||
**Warning:** On Windows, legacy PowerShell (`shell: powershell`) does not use UTF-8 by default.
|
||||
{% note %}
|
||||
|
||||
When using `shell: powershell`, you must specify UTF-8 encoding. 例如：
|
||||
**Note:** PowerShell versions 5.1 and below (`shell: powershell`) do not use UTF-8 by default, so you must specify the UTF-8 encoding. 例如：
|
||||
|
||||
```yaml
|
||||
```yaml{:copy}
|
||||
jobs:
|
||||
legacy-powershell-example:
|
||||
uses: windows-2019
|
||||
runs-on: windows-latest
|
||||
steps:
|
||||
- shell: powershell
|
||||
run: echo "mypath" | Out-File -FilePath $env:GITHUB_PATH -Encoding utf8 -Append
|
||||
run: |
|
||||
"mypath" | Out-File -FilePath $env:GITHUB_PATH -Encoding utf8 -Append
|
||||
```
|
||||
|
||||
Alternatively, you can use PowerShell Core (`shell: pwsh`), which defaults to UTF-8.
|
||||
PowerShell Core versions 6 and higher (`shell: pwsh`) use UTF-8 by default. 例如：
|
||||
|
||||
{% endwarning %}
|
||||
```yaml{:copy}
|
||||
jobs:
|
||||
powershell-core-example:
|
||||
runs-on: windows-latest
|
||||
steps:
|
||||
- shell: pwsh
|
||||
run: |
|
||||
"mypath" >> $env:GITHUB_PATH
|
||||
```
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{% endpowershell %}
|
||||
|
||||
## 设置环境变量
|
||||
|
||||
``` bash
|
||||
{% bash %}
|
||||
|
||||
```bash{:copy}
|
||||
echo "{environment_variable_name}={value}" >> $GITHUB_ENV
|
||||
```
|
||||
|
||||
{% endbash %}
|
||||
|
||||
{% powershell %}
|
||||
|
||||
- Using PowerShell version 6 and higher:
|
||||
```pwsh{:copy}
|
||||
"{environment_variable_name}={value}" >> $env:GITHUB_ENV
|
||||
```
|
||||
|
||||
- Using PowerShell version 5.1 and below:
|
||||
```powershell{:copy}
|
||||
"{environment_variable_name}={value}" | Out-File -FilePath $env:GITHUB_ENV -Encoding utf8 -Append
|
||||
```
|
||||
|
||||
{% endpowershell %}
|
||||
|
||||
You can make an environment variable available to any subsequent steps in a workflow job by defining or updating the environment variable and writing this to the `GITHUB_ENV` environment file. 创建或更新环境变量的步骤无法访问新值，但在作业中的所有后续步骤均可访问。 The names of environment variables are case-sensitive, and you can include punctuation. 更多信息请参阅“[环境变量](/actions/learn-github-actions/environment-variables)”。
|
||||
|
||||
### 示例
|
||||
|
||||
{% bash %}
|
||||
|
||||
{% raw %}
|
||||
```
|
||||
```yaml{:copy}
|
||||
steps:
|
||||
- name: Set the value
|
||||
id: step_one
|
||||
@@ -355,11 +593,31 @@ steps:
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
{% endbash %}
|
||||
|
||||
{% powershell %}
|
||||
|
||||
{% raw %}
|
||||
```yaml{:copy}
|
||||
steps:
|
||||
- name: Set the value
|
||||
id: step_one
|
||||
run: |
|
||||
"action_state=yellow" >> $env:GITHUB_ENV
|
||||
- name: Use the value
|
||||
id: step_two
|
||||
run: |
|
||||
Write-Output "${{ env.action_state }}" # This will output 'yellow'
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
{% endpowershell %}
|
||||
|
||||
### 多行字符串
|
||||
|
||||
对于多行字符串，您可以使用具有以下语法的分隔符。
|
||||
|
||||
```
|
||||
```{:copy}
|
||||
{name}<<{delimiter}
|
||||
{value}
|
||||
{delimiter}
|
||||
@@ -367,29 +625,75 @@ steps:
|
||||
|
||||
#### 示例
|
||||
|
||||
在此示例中， 我们使用 `EOF` 作为分隔符，并将 `JSON_RESPONSE` 环境变量设置为 cURL 响应的值。
|
||||
```yaml
|
||||
This example uses `EOF` as a delimiter, and sets the `JSON_RESPONSE` environment variable to the value of the `curl` response.
|
||||
|
||||
{% bash %}
|
||||
|
||||
```yaml{:copy}
|
||||
steps:
|
||||
- name: Set the value
|
||||
- name: Set the value in bash
|
||||
id: step_one
|
||||
run: |
|
||||
echo 'JSON_RESPONSE<<EOF' >> $GITHUB_ENV
|
||||
curl https://httpbin.org/json >> $GITHUB_ENV
|
||||
curl https://example.lab >> $GITHUB_ENV
|
||||
echo 'EOF' >> $GITHUB_ENV
|
||||
```
|
||||
|
||||
## 添加系统路径
|
||||
{% endbash %}
|
||||
|
||||
``` bash
|
||||
echo "{path}" >> $GITHUB_PATH
|
||||
{% powershell %}
|
||||
|
||||
```yaml{:copy}
|
||||
steps:
|
||||
- name: Set the value in pwsh
|
||||
id: step_one
|
||||
run: |
|
||||
"JSON_RESPONSE<<EOF" >> $env:GITHUB_ENV
|
||||
(Invoke-WebRequest -Uri "https://example.lab").Content >> $env:GITHUB_ENV
|
||||
"EOF" >> $env:GITHUB_ENV
|
||||
shell: pwsh
|
||||
```
|
||||
|
||||
{% endpowershell %}
|
||||
|
||||
## 添加系统路径
|
||||
|
||||
Prepends a directory to the system `PATH` variable and automatically makes it available to all subsequent actions in the current job; the currently running action cannot access the updated path variable. 要查看作业的当前定义路径，您可以在步骤或操作中使用 `echo "$PATH"`。
|
||||
|
||||
{% bash %}
|
||||
|
||||
```bash{:copy}
|
||||
echo "{path}" >> $GITHUB_PATH
|
||||
```
|
||||
{% endbash %}
|
||||
|
||||
{% powershell %}
|
||||
|
||||
```pwsh{:copy}
|
||||
"{path}" >> $env:GITHUB_PATH
|
||||
```
|
||||
|
||||
{% endpowershell %}
|
||||
|
||||
### 示例
|
||||
|
||||
此示例演示如何将用户 `$HOME/.local/bin` 目录添加到 `PATH`：
|
||||
|
||||
``` bash
|
||||
{% bash %}
|
||||
|
||||
```bash{:copy}
|
||||
echo "$HOME/.local/bin" >> $GITHUB_PATH
|
||||
```
|
||||
|
||||
{% endbash %}
|
||||
|
||||
|
||||
This example demonstrates how to add the user `$env:HOMEPATH/.local/bin` directory to `PATH`:
|
||||
|
||||
{% powershell %}
|
||||
|
||||
```pwsh{:copy}
|
||||
"$env:HOMEPATH/.local/bin" >> $env:GITHUB_PATH
|
||||
```
|
||||
|
||||
{% endpowershell %}
|
||||
|
||||
@@ -17,7 +17,11 @@ topics:
|
||||
|
||||
如果配置的是主机名，而不是硬编码 IP 地址，您将能够更改运行 {% data variables.product.product_location %} 的物理硬件，而不会影响用户或客户端软件。
|
||||
|
||||
{% data variables.enterprise.management_console %} 中的主机名设置应设置为合适的完全限定域名 (FQDN)，此域名可在互联网上或您的内部网络内解析。 例如，您的主机名设置可以是 `github.companyname.com`。我们还建议为选定的主机名启用子域隔离，以缓解多种跨站点脚本样式漏洞。 更多关于主机名设置的信息，请参阅 [HTTP RFC 的第 2.1 节](https://tools.ietf.org/html/rfc1123#section-2)。
|
||||
{% data variables.enterprise.management_console %} 中的主机名设置应设置为合适的完全限定域名 (FQDN)，此域名可在互联网上或您的内部网络内解析。 For example, your hostname setting could be `github.companyname.com.` Web and API requests will automatically redirect to the hostname configured in the {% data variables.enterprise.management_console %}.
|
||||
|
||||
After you configure a hostname, you can enable subdomain isolation to further increase the security of {% data variables.product.product_location %}. 更多信息请参阅“[启用子域隔离](/enterprise/{{ currentVersion }}/admin/guides/installation/enabling-subdomain-isolation/)”。
|
||||
|
||||
For more information on the supported hostname types, see [Section 2.1 of the HTTP RFC](https://tools.ietf.org/html/rfc1123#section-2).
|
||||
|
||||
{% data reusables.enterprise_installation.changing-hostname-not-supported %}
|
||||
|
||||
@@ -29,4 +33,4 @@ topics:
|
||||
{% data reusables.enterprise_management_console.test-domain-settings-failure %}
|
||||
{% data reusables.enterprise_management_console.save-settings %}
|
||||
|
||||
配置完主机名后，建议为 {% data variables.product.product_location %} 启用子域隔离。 更多信息请参阅“[启用子域隔离](/enterprise/{{ currentVersion }}/admin/guides/installation/enabling-subdomain-isolation/)”。
|
||||
To help mitigate various cross-site scripting vulnerabilities, we recommend that you enable subdomain isolation for {% data variables.product.product_location %} after you configure a hostname. 更多信息请参阅“[启用子域隔离](/enterprise/{{ currentVersion }}/admin/guides/installation/enabling-subdomain-isolation/)”。
|
||||
|
||||
@@ -19,25 +19,32 @@ shortTitle: 启动故障转移到设备
|
||||
|
||||
{% data reusables.enterprise_installation.promoting-a-replica %}
|
||||
|
||||
1. 要允许复制在切换设备之前完成，请将主设备置于维护模式：
|
||||
- 要使用 Management Console，请参阅“[启用和排定维护模式](/enterprise/admin/guides/installation/enabling-and-scheduling-maintenance-mode/)”。
|
||||
- 您也可以使用 `ghe-maintenance -s` 命令。
|
||||
1. If the primary appliance is available, to allow replication to finish before you switch appliances, on the primary appliance, put the primary appliance into maintenance mode.
|
||||
|
||||
- Put the appliance into maintenance mode.
|
||||
|
||||
- 要使用 Management Console，请参阅“[启用和排定维护模式](/enterprise/admin/guides/installation/enabling-and-scheduling-maintenance-mode/)”。
|
||||
|
||||
- 您也可以使用 `ghe-maintenance -s` 命令。
|
||||
```shell
|
||||
$ ghe-maintenance -s
|
||||
```
|
||||
|
||||
- 当活动 Git 操作、MySQL 查询和 Resque 作业数量达到零时，等待 30 秒。
|
||||
|
||||
{% note %}
|
||||
|
||||
**注意：** Nomad 将始终有作业在运行，即使是在维护模式下，因此您可以安全地忽略这些作业。
|
||||
|
||||
{% endnote %}
|
||||
|
||||
- 要验证所有复制通道均报告 `OK`，请使用 `ghe-repl-status -vv` 命令。
|
||||
|
||||
```shell
|
||||
$ ghe-maintenance -s
|
||||
$ ghe-repl-status -vv
|
||||
```
|
||||
2. 当活动 Git 操作、MySQL 查询和 Resque 作业数量达到零时，等待 30 秒。
|
||||
|
||||
{% note %}
|
||||
|
||||
**注意：** Nomad 将始终有作业在运行，即使是在维护模式下，因此您可以安全地忽略这些作业。
|
||||
|
||||
{% endnote %}
|
||||
|
||||
3. 要验证所有复制通道均报告 `OK`，请使用 `ghe-repl-status -vv` 命令。
|
||||
```shell
|
||||
$ ghe-repl-status -vv
|
||||
```
|
||||
4. 要停止复制并将副本设备升级为主设备，请使用 `ghe-repl-promote` 命令。 此操作还会自动将主节点（若可到达）置于维护模式。
|
||||
4. On the replica appliance, to stop replication and promote the replica appliance to primary status, use the `ghe-repl-promote` command. 此操作还会自动将主节点（若可到达）置于维护模式。
|
||||
```shell
|
||||
$ ghe-repl-promote
|
||||
```
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: 恢复已删除的仓库
|
||||
intro: Site administrators can restore deleted repositories to recover their contents.
|
||||
intro: 站点管理员可以恢复已删除的仓库来恢复其内容。
|
||||
versions:
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
@@ -8,14 +8,14 @@ topics:
|
||||
- Enterprise
|
||||
- Privacy
|
||||
- Repositories
|
||||
shortTitle: Restore a deleted repository
|
||||
shortTitle: 恢复已删除的仓库
|
||||
---
|
||||
|
||||
通常情况下，如果有人删除仓库，它将在磁盘上保留 90 天并且可以通过站点管理员仪表板进行恢复。 Unless a legal hold is in effect on a user or organization, after 90 days the repository is purged and deleted forever.
|
||||
通常情况下，如果有人删除仓库，它将在磁盘上保留 90 天并且可以通过站点管理员仪表板进行恢复。 除非法定保留对用户或组织有效，否则 90 天后，存储库将被清除并永久删除。
|
||||
|
||||
## 关于仓库恢复
|
||||
|
||||
If a repository was part of a fork network when it was deleted, the restored repository will be detached from the original fork network.
|
||||
如果存储库在被删除时是复刻网络的一部分，则还原的存储库将与原始复刻网络分离。
|
||||
|
||||
仓库被删除后，可能需要一个小时才能恢复。
|
||||
|
||||
@@ -26,10 +26,10 @@ If a repository was part of a fork network when it was deleted, the restored rep
|
||||
{% data reusables.enterprise_site_admin_settings.access-settings %}
|
||||
{% data reusables.enterprise_site_admin_settings.search-user-or-org %}
|
||||
{% data reusables.enterprise_site_admin_settings.click-user-or-org %}
|
||||
1. In the {% octicon "repo" aria-label="The repo icon" %} **Repositories** section, click the {% octicon "trash" aria-label="The trash icon" %} **Deleted repositories** link.
|
||||
1. Find the repository you want to restore in the deleted repositories list, then to the right of the repository name click **Restore**.
|
||||
1. To confirm you would like to restore the named repository, click **Restore**.
|
||||
1. 在 {% octicon "repo" aria-label="The repo icon" %} **存储库**部分，单击 {% octicon "trash" aria-label="The trash icon" %} **已删除的存储库**链接。
|
||||
1. 在已删除的存储库列表中找到要还原的存储库，然后在存储库名称右侧单击 **Restore（还原）**。
|
||||
1. 要确认是否要还原指定的存储库，请单击 **Restore（还原）**。
|
||||
|
||||
## 延伸阅读
|
||||
|
||||
- "[Placing a legal hold on a user or organization](/admin/user-management/managing-users-in-your-enterprise/placing-a-legal-hold-on-a-user-or-organization)"
|
||||
- "[对用户或组织合法保留](/admin/user-management/managing-users-in-your-enterprise/placing-a-legal-hold-on-a-user-or-organization)"
|
||||
|
||||
@@ -25,7 +25,7 @@ topics:
|
||||
|
||||
在迁移中，一切都围绕仓库进行。 与仓库关联的大多数数据都可以迁移。 例如，组织内的仓库将迁移仓库*和*组织，以及与该仓库关联的任何用户、团队、问题和拉取请求。
|
||||
|
||||
下表中的项可随仓库一起迁移。 迁移的数据列表中未显示的任何项都无法迁移。
|
||||
下表中的项可随仓库一起迁移。 Any items not shown in the list of migrated data can not be migrated, including {% data variables.large_files.product_name_short %} assets.
|
||||
|
||||
{% data reusables.enterprise_migrations.fork-persistence %}
|
||||
|
||||
|
||||
@@ -25,7 +25,7 @@ shortTitle: Check for existing SSH key
|
||||
# Lists the files in your .ssh directory, if they exist
|
||||
```
|
||||
|
||||
3. Check the directory listing to see if you already have a public SSH key. By default, the {% ifversion ghae %}filename of a supported public key for {% data variables.product.product_name %} is *id_rsa.pub*.{% elsif fpt or ghes %}filenames of supported public keys for {% data variables.product.product_name %} are one of the following.
|
||||
3. Check the directory listing to see if you already have a public SSH key. By default, the {% ifversion ghae %}filename of a supported public key for {% data variables.product.product_name %} is *id_rsa.pub*.{% else %}filenames of supported public keys for {% data variables.product.product_name %} are one of the following.
|
||||
- *id_rsa.pub*
|
||||
- *id_ecdsa.pub*
|
||||
- *id_ed25519.pub*{% endif %}
|
||||
|
||||
@@ -33,7 +33,7 @@ $ ssh -T -p 443 git@ssh.github.com
|
||||
|
||||
如果您能在端口 443 上通过 SSH 连接到 `git@ssh.{% data variables.command_line.backticks %}`，则可以覆盖您的 SSH 设置以强制与 {% data variables.product.product_location %} 的任何连接均通过该服务器和端口运行。
|
||||
|
||||
要在 SSH 配置文件中设置此设置，请在 `~/.ssh/config` 编辑该文件，并添加以下部分：
|
||||
To set this in your SSH configuration file, edit the file at `~/.ssh/config`, and add this section:
|
||||
|
||||
```
|
||||
Host {% data variables.command_line.codeblock %}
|
||||
|
||||
@@ -31,9 +31,9 @@ If your project communicates with an external service, you might use a token or
|
||||
{% ifversion fpt or ghec %}
|
||||
{% data variables.product.prodname_secret_scanning_caps %} is available on {% data variables.product.prodname_dotcom_the_website %} in two forms:
|
||||
|
||||
1. **{% data variables.product.prodname_secret_scanning_partner_caps %}.** Runs automatically on all public repositories. Any strings that match patterns that were provided by secret scanning partners are reported directly to the relvant partner.
|
||||
1. **{% data variables.product.prodname_secret_scanning_partner_caps %}.** Runs automatically on all public repositories. Any strings that match patterns that were provided by secret scanning partners are reported directly to the relevant partner.
|
||||
|
||||
2. **{% data variables.product.prodname_secret_scanning_GHAS_caps %}.** You can enable and configure additional scanning for repositories owned by organizations that use {% data variables.product.prodname_ghe_cloud %} and have a license for {% data variables.product.prodname_GH_advanced_security %}. Any strings that match patterns provided by secret scannng partners, by other service providers, or defined by your organization are reported as alerts in the "Security" tab of repositories. If a string in a public repository matches a partner pattern, it is also reported to the partner.
|
||||
2. **{% data variables.product.prodname_secret_scanning_GHAS_caps %}.** You can enable and configure additional scanning for repositories owned by organizations that use {% data variables.product.prodname_ghe_cloud %} and have a license for {% data variables.product.prodname_GH_advanced_security %}. Any strings that match patterns provided by secret scanning partners, by other service providers, or defined by your organization, are reported as alerts in the "Security" tab of repositories. If a string in a public repository matches a partner pattern, it is also reported to the partner.
|
||||
{% endif %}
|
||||
|
||||
Service providers can partner with {% data variables.product.company_short %} to provide their secret formats for scanning. {% data reusables.secret-scanning.partner-program-link %}
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Using the Visual Studio Code Command Palette in Codespaces
|
||||
title: 在 Codespaces 中使用 Visual Studio 代码命令面板
|
||||
intro: '您可以使用 {% data variables.product.prodname_vscode %} 的命令调色板功能访问代码空间中的许多命令。'
|
||||
versions:
|
||||
fpt: '*'
|
||||
@@ -9,21 +9,21 @@ topics:
|
||||
- Codespaces
|
||||
- Visual Studio Code
|
||||
product: '{% data reusables.gated-features.codespaces %}'
|
||||
shortTitle: VS Code Command Palette
|
||||
shortTitle: VS 代码命令面板
|
||||
allowTitleToDifferFromFilename: true
|
||||
redirect_from:
|
||||
- /codespaces/codespaces-reference/using-the-command-palette-in-codespaces
|
||||
---
|
||||
|
||||
## About the {% data variables.product.prodname_vscode %} Command Palette
|
||||
## 关于 {% data variables.product.prodname_vscode %} 命令面板
|
||||
|
||||
命令调色板是 {% data variables.product.prodname_vscode %} 的重点功能之一，可用于代码空间。 The {% data variables.product.prodname_vscode_command_palette %} allows you to access many commands for {% data variables.product.prodname_codespaces %} and {% data variables.product.prodname_vscode %}. For more information on using the {% data variables.product.prodname_vscode_command_palette %}, see "[User Interface](https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette)" in the Visual Studio Code documentation.
|
||||
命令调色板是 {% data variables.product.prodname_vscode %} 的重点功能之一，可用于代码空间。 {% data variables.product.prodname_vscode_command_palette %} 允许您访问 {% data variables.product.prodname_codespaces %} 和 {% data variables.product.prodname_vscode %} 的许多命令。 有关使用 {% data variables.product.prodname_vscode_command_palette %} 的更多信息，请参阅 visual Studio Code 文档中的 “[用户界面](https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette)”。
|
||||
|
||||
## Accessing the {% data variables.product.prodname_vscode_command_palette %}
|
||||
## 访问 {% data variables.product.prodname_vscode_command_palette %}
|
||||
|
||||
You can access the {% data variables.product.prodname_vscode_command_palette %} in a number of ways.
|
||||
您可以通过多种方式访问 {% data variables.product.prodname_vscode_command_palette %}。
|
||||
|
||||
- <kbd>Shift</kbd>+<kbd>Command</kbd>+<kbd>P</kbd> (Mac) / <kbd>Ctrl</kbd>+<kbd>Shift</kbd>+<kbd>P</kbd> (Windows/Linux).
|
||||
- <kbd>Shift</kbd>+<kbd>Command</kbd>+<kbd>P</kbd> (Mac) / <kbd>Ctrl</kbd>+<kbd>Shift</kbd>+<kbd>P</kbd> (Windows/Linux)。
|
||||
|
||||
请注意，此命令是 Firefox 中保留的键盘快捷键。
|
||||
- <kbd>F1</kbd>
|
||||
@@ -33,21 +33,21 @@ You can access the {% data variables.product.prodname_vscode_command_palette %}
|
||||
|
||||
## {% data variables.product.prodname_github_codespaces %} 命令
|
||||
|
||||
To see all commands related to {% data variables.product.prodname_github_codespaces %}, [access the {% data variables.product.prodname_vscode_command_palette %}](#accessing-the-command-palette), then start typing "Codespaces".
|
||||
要查看与 {% data variables.product.prodname_github_codespaces %} 相关的所有命令， [访问 {% data variables.product.prodname_vscode_command_palette %}](#accessing-the-command-palette)，然后开始键入 "Codespaces"。
|
||||
|
||||
|
||||
|
||||
### 挂起或停止代码空间
|
||||
|
||||
If you add a new secret or change the machine type, you'll have to stop and restart the codespace for it to apply your changes.
|
||||
如果添加新密钥或更换机器类型，则必须停止并重新启动代码空间才能应用更改。
|
||||
|
||||
To suspend or stop your codespace's container, [access the {% data variables.product.prodname_vscode_command_palette %}](#accessing-the-command-palette), then start typing "stop". 选择 **Codespaces: Stop Current Codespace（Codespace：停止当前 Codespace）**。
|
||||
要暂停或停止代码空间的容器，[访问 {% data variables.product.prodname_vscode_command_palette %}](#accessing-the-command-palette)，然后开始键入"stop"。 选择 **Codespaces: Stop Current Codespace（Codespace：停止当前 Codespace）**。
|
||||
|
||||
|
||||
|
||||
### 从模板添加开发容器
|
||||
|
||||
To add a dev container from a template, [access the {% data variables.product.prodname_vscode_command_palette %}](#accessing-the-command-palette), then start typing "dev container". 选择 **Codespaces: Add Development Container Configuration Files...（Codespaces：添加开发容器配置文件...）**
|
||||
要从模板添加开发容器，[访问 {% data variables.product.prodname_vscode_command_palette %}](#accessing-the-command-palette)，然后开始键入 "dev container"。 选择 **Codespaces: Add Development Container Configuration Files...（Codespaces：添加开发容器配置文件...）**
|
||||
|
||||
|
||||
|
||||
@@ -55,14 +55,14 @@ To add a dev container from a template, [access the {% data variables.product.pr
|
||||
|
||||
如果您添加 dev 容器或编辑任何配置文件（`devcontainer.json` 和 `Dockerfile`），则需要重建代码空间才可应用更改。
|
||||
|
||||
To rebuild your container, [access the {% data variables.product.prodname_vscode_command_palette %}](#accessing-the-command-palette), then start typing "rebuild". 选择 **Codespaces: Rebuild Container（代码空间：重建容器）**。
|
||||
要重建容器，[访问 {% data variables.product.prodname_vscode_command_palette %}](#accessing-the-command-palette)，然后开始键入 "rebuild"。 选择 **Codespaces: Rebuild Container（代码空间：重建容器）**。
|
||||
|
||||
|
||||
|
||||
### Codespaces 日志
|
||||
|
||||
You can use the {% data variables.product.prodname_vscode_command_palette %} to access the codespace creation logs, or you can use it export all logs.
|
||||
可以使用 {% data variables.product.prodname_vscode_command_palette %} 访问代码空间创建日志，也可以使用它导出所有日志。
|
||||
|
||||
To retrieve the logs for Codespaces, [access the {% data variables.product.prodname_vscode_command_palette %}](#accessing-the-command-palette), then start typing "log". 选择 **Codespaces: Export Logs（Codespaces：导出日志）**以导出所有与 Codespaces 相关的日志，或选择 **Codespaces: View Creation Logs（Codespaces：查看创建日志）**以查看与设置相关的日志。
|
||||
要检索 Codespaces 的日志，[访问 {% data variables.product.prodname_vscode_command_palette %}](#accessing-the-command-palette)，然后开始键入 "log"。 选择 **Codespaces: Export Logs（Codespaces：导出日志）**以导出所有与 Codespaces 相关的日志，或选择 **Codespaces: View Creation Logs（Codespaces：查看创建日志）**以查看与设置相关的日志。
|
||||
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ topics:
|
||||
- Codespaces
|
||||
- Fundamentals
|
||||
- Developer
|
||||
shortTitle: Create a codespace
|
||||
shortTitle: 创建代码空间
|
||||
---
|
||||
|
||||
## 关于代码空间的创建
|
||||
|
||||
@@ -13,7 +13,7 @@ topics:
|
||||
- Codespaces
|
||||
- Fundamentals
|
||||
- Developer
|
||||
shortTitle: Delete a codespace
|
||||
shortTitle: 删除代码空间
|
||||
---
|
||||
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ topics:
|
||||
- Developer
|
||||
---
|
||||
|
||||
## 关于 {% data variables.product.prodname_cli %}
|
||||
## About {% data variables.product.prodname_cli %}
|
||||
|
||||
{% data reusables.cli.about-cli %} For more information, see "[About {% data variables.product.prodname_cli %}](/github-cli/github-cli/about-github-cli)."
|
||||
|
||||
@@ -28,22 +28,26 @@ You can work with {% data variables.product.prodname_codespaces %} in the {% da
|
||||
- [Modify ports in a codespace](#modify-ports-in-a-codespace)
|
||||
- [Access codespace logs](#access-codespace-logs)
|
||||
|
||||
## 安装 {% data variables.product.prodname_cli %}
|
||||
## Installing {% data variables.product.prodname_cli %}
|
||||
|
||||
{% data reusables.cli.cli-installation %}
|
||||
|
||||
## Using {% data variables.product.prodname_cli %}
|
||||
|
||||
## 使用 {% data variables.product.prodname_cli %}
|
||||
|
||||
If you have not already done so, run `gh auth login` to authenticate with your {% data variables.product.prodname_dotcom %} account.
|
||||
If you have not already done so, run `gh auth login` to authenticate with your {% data variables.product.prodname_dotcom %} account.
|
||||
|
||||
To use `gh` to work with {% data variables.product.prodname_codespaces %}, type `gh codespace <COMMAND>` or its alias `gh cs <COMMAND>`.
|
||||
|
||||
As an example of a series of commands you might use to work with {% data variables.product.prodname_github_codespaces %}, you could:
|
||||
As an example of a series of commands you might use to work with {% data variables.product.prodname_github_codespaces %}, you could:
|
||||
|
||||
* List your current codespaces, to check whether you have a codespace for a particular repository:<br> `gh codespace list`
|
||||
* Create a new codespace for the required repository branch:<br> `gh codespace create -r github/docs -b main`
|
||||
* SSH into the new codespace:<br> `gh codespace ssh -c mona-github-docs-v4qxrv7rfwv9w`
|
||||
* Forward a port to your local machine:<br> `gh codespace ports forward 8000:8000 -c mona-github-docs-v4qxrv7rfwv9w`
|
||||
* List your current codespaces, to check whether you have a codespace for a particular repository:<br>
|
||||
`gh codespace list`
|
||||
* Create a new codespace for the required repository branch:<br>
|
||||
`gh codespace create -r github/docs -b main`
|
||||
* SSH into the new codespace:<br>
|
||||
`gh codespace ssh -c mona-github-docs-v4qxrv7rfwv9w`
|
||||
* Forward a port to your local machine:<br>
|
||||
`gh codespace ports forward 8000:8000 -c mona-github-docs-v4qxrv7rfwv9w`
|
||||
|
||||
## `gh` commands for {% data variables.product.prodname_github_codespaces %}
|
||||
|
||||
@@ -71,7 +75,7 @@ The list includes the unique name of each codespace, which you can use in other
|
||||
gh codespace create -r <em>owner/repository</em> [-b <em>branch</em>]
|
||||
```
|
||||
|
||||
更多信息请参阅“[创建代码空间](/codespaces/developing-in-codespaces/creating-a-codespace)”。
|
||||
For more information, see "[Creating a codespace](/codespaces/developing-in-codespaces/creating-a-codespace)."
|
||||
|
||||
### Stop a codespace
|
||||
|
||||
@@ -119,7 +123,7 @@ Use the prefix `remote:` on a file or directory name to indicate that it's on th
|
||||
|
||||
The location of files and directories on the codespace is relative to the home directory of the remote user.
|
||||
|
||||
#### 示例
|
||||
#### Examples
|
||||
|
||||
* Copy a file from the local machine to the `$HOME` directory of a codespace:
|
||||
|
||||
@@ -167,13 +171,13 @@ You can set the visibility of a forwarded port. {% data reusables.codespaces.por
|
||||
gh codespace ports visibility <em>codespace-port</em>:<em>private|org|public</em> -c <em>codespace-name</em>
|
||||
```
|
||||
|
||||
You can set the visibility for multiple ports with one command. 例如：
|
||||
You can set the visibility for multiple ports with one command. For example:
|
||||
|
||||
```shell
|
||||
gh codespace ports visibility 80:private 3000:public 3306:org -c <em>codespace-name</em>
|
||||
```
|
||||
|
||||
更多信息请参阅“[在代码空间中转发端口](/codespaces/developing-in-codespaces/forwarding-ports-in-your-codespace)”。
|
||||
For more information, see "[Forwarding ports in your codespace](/codespaces/developing-in-codespaces/forwarding-ports-in-your-codespace)."
|
||||
|
||||
### Access codespace logs
|
||||
|
||||
|
||||
@@ -22,7 +22,7 @@ topics:
|
||||
|
||||
## 关于复刻
|
||||
|
||||
复刻最常见的用法是对其他人的项目提出更改或将其他人的项目用作自己创意的起点。 您可以复刻仓库以创建仓库的副本，并在不影响上游仓库的情况下进行更改。 更多信息请参阅“[使用复刻](/github/collaborating-with-issues-and-pull-requests/working-with-forks)”。
|
||||
Most commonly, forks are used to either propose changes to someone else's project to which you don't have write access, or to use someone else's project as a starting point for your own idea. 您可以复刻仓库以创建仓库的副本，并在不影响上游仓库的情况下进行更改。 更多信息请参阅“[使用复刻](/github/collaborating-with-issues-and-pull-requests/working-with-forks)”。
|
||||
|
||||
### 对其他人的项目提出更改
|
||||
|
||||
|
||||
@@ -66,7 +66,7 @@ You can only invite an individual user to collaborate on your organization-level
|
||||
|
||||
{% note %}
|
||||
|
||||
This only affects collaborators for your project, not for repositories in your project. To view an item on the project, someone must have the required permissions for the repository that the item belongs to. If your project includes items from a private repository, people who are not collaborators in the repository will not be able to view items from that repository. For more information, see "[Setting repository visibility](/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility)" and "[Managing teams and people with access to your repository](/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/managing-teams-and-people-with-access-to-your-repository)."
|
||||
This only affects collaborators for your project, not for repositories in your project. To view an item on the project, someone must have the required permissions for the repository that the item belongs to. 如果项目包含私有存储库中的项目，则不是存储库协作者的用户将无法查看该存储库中的项。 For more information, see "[Setting repository visibility](/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility)" and "[Managing teams and people with access to your repository](/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/managing-teams-and-people-with-access-to-your-repository)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Managing the visibility of your projects (beta)
|
||||
intro: You can control who can view your projects.
|
||||
title: 管理项目的可见性（测试版）
|
||||
intro: 您可以控制谁可以查看您的项目。
|
||||
allowTitleToDifferFromFilename: true
|
||||
miniTocMaxHeadingLevel: 3
|
||||
versions:
|
||||
@@ -13,21 +13,21 @@ topics:
|
||||
|
||||
{% data reusables.projects.projects-beta %}
|
||||
|
||||
## About project visibility
|
||||
## 关于项目可见性
|
||||
|
||||
Projects (beta) can be public or private. For public projects, everyone on the internet can view the project. For private projects, only users granted at least read access can see the project.
|
||||
项目（测试版）可以是公共的，也可以是私有的。 对于公共项目，互联网上的每个人都可以查看。 对于私有项目，只有被授予至少读取访问权限的用户才能查看。
|
||||
|
||||
Only the project visibility is affected; to view an item on the project, someone must have the required permissions for the repository that the item belongs to. If your project includes items from a private repository, people who are not collaborators in the repository will not be able to view items from that repository.
|
||||
只有项目可见性会受影响；要查看项目上的项，必须有人具有该项所属存储库所需的权限。 如果项目包含私有存储库中的项目，则不是存储库协作者的用户将无法查看该存储库中的项。
|
||||
|
||||
|
||||
|
||||
|
||||
Only project admins can control project visibility.
|
||||
只有项目管理员才能控制项目可见性。
|
||||
|
||||
In private, organization-owned projects, the avatars of users who are current making updates to the project are displayed in the project UI.
|
||||
在组织拥有的私有项目中，当前对项目进行更新的用户的头像将显示在项目 UI 中。
|
||||
|
||||
Project admins can also manage write and admin access to their project and control read access for individual users. For more information, see "[Managing access to projects](/issues/trying-out-the-new-projects-experience/managing-access-to-projects)."
|
||||
项目管理员还可以管理对其项目的写入和管理员访问权限，并控制单个用户的读取访问权限。 更多信息请参阅“[管理对项目的访问](/issues/trying-out-the-new-projects-experience/managing-access-to-projects)”。
|
||||
|
||||
## Changing project visibility
|
||||
## 更改项目可见性
|
||||
|
||||
{% data reusables.projects.project-settings %}
|
||||
1. Under **Visibility**, select **Private** or **Public**.
|
||||
1. 在 **Visibility（可见性）**下，选择 **Private（私有）**或 **Public（公共）**。
|
||||
|
||||
@@ -1,147 +1,147 @@
|
||||
---
|
||||
title: Managing custom repository roles for an organization
|
||||
intro: You can more granularly control access to your organization's repositories by creating custom repository roles.
|
||||
title: 管理组织的自定义存储库角色
|
||||
intro: 通过创建自定义存储库角色，可以更精细地控制对组织存储库的访问。
|
||||
permissions: Organization owners can manage custom repository roles.
|
||||
versions:
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Organizations
|
||||
- Teams
|
||||
shortTitle: Custom repository roles
|
||||
shortTitle: 自定义存储库角色
|
||||
redirect_from:
|
||||
- /early-access/github/articles/managing-custom-repository-roles-for-an-organization
|
||||
---
|
||||
|
||||
{% data reusables.pre-release-program.custom-roles-public-beta %}
|
||||
|
||||
## About custom repository roles
|
||||
## 关于自定义存储库角色
|
||||
|
||||
To perform any actions on {% data variables.product.product_name %}, such as creating a pull request in a repository or changing an organization's billing settings, a person must have sufficient access to the relevant account or resource. This access is controlled by permissions. A permission is the ability to perform a specific action. For example, the ability to delete an issue is a permission. A role is a set of permissions you can assign to individuals or teams.
|
||||
要对 {% data variables.product.product_name %} 执行任何操作，例如在存储库中创建拉取请求或更改组织的计费设置，人员必须具有对相关帐户或资源的足够访问权限。 This access is controlled by permissions. A permission is the ability to perform a specific action. For example, the ability to delete an issue is a permission. A role is a set of permissions you can assign to individuals or teams.
|
||||
|
||||
Within an organization, you can assign roles at the organization, team, and repository level. For more information about the different levels of roles, see "[Roles in an organization](/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization)."
|
||||
在组织内，您可以在组织、团队和存储库级别分配角色。 有关不同级别角色的更多信息，请参阅“[组织中的角色](/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization)”。
|
||||
|
||||
If your organization uses {% data variables.product.prodname_ghe_cloud %}, you can have more granular control over the permissions you grant at the repository level by creating up to three custom repository roles. A custom repository role is a configurable set of permissions with a custom name you choose. After you create a custom role, anyone with admin access to a repository can assign the role to an individual or team. For more information, see "[Managing an individual's access to an organization repository](/organizations/managing-access-to-your-organizations-repositories/managing-an-individuals-access-to-an-organization-repository)" and "[Managing team access to an organization repository](/organizations/managing-access-to-your-organizations-repositories/managing-team-access-to-an-organization-repository)"
|
||||
如果您的组织使用 {% data variables.product.prodname_ghe_cloud %}，则通过创建最多三个自定义存储库角色，可以更精细地控制在存储库级别授予的权限。 自定义存储库角色是一组可配置的权限，具有您选择的自定义名称。 创建自定义角色后，对存储库具有管理员访问权限的任何人都可以将该角色分配给个人或团队。 更多信息请参阅“[管理个人对组织存储库的访问](/organizations/managing-access-to-your-organizations-repositories/managing-an-individuals-access-to-an-organization-repository)”和“[管理团队对组织存储库的访问](/organizations/managing-access-to-your-organizations-repositories/managing-team-access-to-an-organization-repository)”
|
||||
|
||||
{% data reusables.enterprise.link-to-ghec-trial %}
|
||||
|
||||
## About the inherited role
|
||||
## 关于继承的角色
|
||||
|
||||
When you create a custom repository role, you start by choosing an inherited role from a set of pre-defined options. The inherited role determines the initial set of permissions included in the custom role. Then, you can further customize the role by choosing additional permissions to give the role. For the full list of available permissions, see "[Additional permissions for custom roles](#additional-permissions-for-custom-roles)."
|
||||
创建自定义存储库角色时，首先从一组预定义选项中选择继承的角色。 继承的角色确定自定义角色中包含的初始权限集。 然后，您可以通过选择其他权限来授予角色，从而进一步自定义角色。 有关可用权限的完整列表，请参阅“[自定义角色的其他权限](#additional-permissions-for-custom-roles)”。
|
||||
|
||||
Your options for the inherited role are standardized for different types of contributors in your repository.
|
||||
继承角色的选项已针对存储库中不同类型的参与者进行了标准化。
|
||||
|
||||
| Inherited role | Designed for |
|
||||
| -------------- | ------------------------------------------------------------------------------------------------------ |
|
||||
| **读取** | Non-code contributors who want to view or discuss your project. |
|
||||
| **分类** | Contributors who need to proactively manage issues and pull requests without write access. |
|
||||
| **写入** | Organization members and collaborators who actively push to your project. |
|
||||
| **维护** | Project managers who need to manage the repository without access to sensitive or destructive actions. |
|
||||
| 继承的角色 | 适用于 |
|
||||
| ------ | ------------------------------- |
|
||||
| **读取** | 想要查看或讨论项目的非代码参与者。 |
|
||||
| **分类** | 需要主动管理问题和在没有写入访问权限的情况下拉取请求的参与者。 |
|
||||
| **写入** | 积极推动项目的组织成员和协作者。 |
|
||||
| **维护** | 需要管理存储库而无法访问敏感或破坏性操作的项目经理。 |
|
||||
|
||||
## Custom role examples
|
||||
## 自定义角色示例
|
||||
|
||||
Here are some examples of custom repository roles you can configure.
|
||||
以下是您可以配置的自定义存储库角色的一些示例。
|
||||
|
||||
| Custom repository role | 摘要 | Inherited role | Additional permissions |
|
||||
| ---------------------- | ----------------------------------------------------------------------------------- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Security engineer | Able to contribute code and maintain the security pipeline | **维护** | Delete code scanning results |
|
||||
| Contractor | Able to develop webhooks integrations | **写入** | Manage webhooks |
|
||||
| Community manager | Able to handle all the community interactions without being able to contribute code | **读取** | - Mark an issue as duplicate <br> - Manage GitHub Page settings <br> - Manage wiki settings <br> - Set the social preview <br> - Edit repository metadata <br> - Triage discussions |
|
||||
| 自定义存储库角色 | 摘要 | 继承的角色 | 其他权限 |
|
||||
| -------- | ------------------ | ------ | ------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| 安全工程师 | 能够贡献代码并维护安全管道 | **维护** | 删除代码扫描结果 |
|
||||
| 承包商 | 能够开发 web 挂钩集成 | **写入** | 管理 web 挂钩 |
|
||||
| 社区经理 | 能够处理所有社区互动，而无需贡献代码 | **读取** | - 将问题标记为重复 <br> - 管理 GitHub Pages 设置 - <br> 管理 wiki 设置<br> - 设置社交预览 <br> - 编辑存储库元数据 <br> - 对讨论分类 |
|
||||
|
||||
## Additional permissions for custom roles
|
||||
## 自定义角色的其他权限
|
||||
|
||||
After choosing an inherited role, you can select additional permissions for your custom role.
|
||||
选择继承角色后，您可以为自定义角色选择其他权限。
|
||||
|
||||
You can only choose an additional permission if it's not already included in the inherited role. For example, if the inherited role offers **Write** access to a repository, then the "Close a pull request" permission will already be included in the inherited role.
|
||||
仅当继承的角色中尚未包含其他权限时，才能选择该权限。 例如，如果继承的角色提供对存储库**写入**访问权限，则“关闭拉取请求”权限将已包含在继承的角色中。
|
||||
|
||||
### Issue and Pull Requests
|
||||
### 议题和拉取请求
|
||||
|
||||
- **Assign or remove a user**: Assign a user to an issue or pull request, or remove a user from an issue or pull request.
|
||||
- **Add or remove a label**: Add a label to an issue or a pull request, or remove a label from an issue or pull request.
|
||||
- **分配或删除用户**：将用户分配给问题或拉取请求，或从问题或拉取请求中删除用户。
|
||||
- **添加或删除标签**：向议题或拉取请求添加标签，或者从议题或拉取请求中删除标签。
|
||||
|
||||
### 议题
|
||||
|
||||
- **Close an issue**
|
||||
- **Reopen a closed issue**
|
||||
- **Delete an issue**
|
||||
- **Mark an issue as a duplicate**
|
||||
- **关闭议题**
|
||||
- **重新打开已关闭的议题**
|
||||
- **删除议题**
|
||||
- **将议题标记为重复**
|
||||
|
||||
### 拉取请求
|
||||
|
||||
- **Close a pull request**
|
||||
- **Reopen a closed pull request**
|
||||
- **Request a pull request review**: Request a review from a user or team.
|
||||
- **关闭拉取请求**
|
||||
- **重新打开已关闭的拉取请求**
|
||||
- **请求拉取请求审核**：请求用户或团队审核。
|
||||
|
||||
### 仓库
|
||||
|
||||
- **Set milestones**: Add milestones to an issue or pull request.
|
||||
- **Manage wiki settings**: Turn on wikis for a repository.
|
||||
- **Manage project settings**: Turning on projects for a repository.
|
||||
- **Manage pull request merging settings**: Choose the type of merge commits that are allowed in your repository, such as merge, squash, or rebase.
|
||||
- **Manage {% data variables.product.prodname_pages %} settings**: Enable {% data variables.product.prodname_pages %} for the repository, and select the branch you want to publish. 更多信息请参阅“[配置 {% data variables.product.prodname_pages %} 站点的发布来源](/pages/getting-started-with-github-pages/configuring-a-publishing-source-for-your-github-pages-site)”。
|
||||
- **Manage webhooks**: Add webhooks to the repository.
|
||||
- **Manage deploy keys**: Add deploy keys to the repository.
|
||||
- **Edit repository metadata**: Update the repository description as well as the repository topics.
|
||||
- **Set interaction limits**: Temporarily restrict certain users from commenting, opening issues, or creating pull requests in your public repository to enforce a period of limited activity. For more information, see "[Limiting interactions in your repository](/communities/moderating-comments-and-conversations/limiting-interactions-in-your-repository)."
|
||||
- **Set the social preview**: Add an identifying image to your repository that appears on social media platforms when your repository is linked. 更多信息请参阅“[自定义仓库的社交媒体审查](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/customizing-your-repositorys-social-media-preview)”。
|
||||
- **Push commits to protected branches**: Push to a branch that is marked as a protected branch.
|
||||
- **Create protected tags**: Create tags that match a tag protection rule. For more information, see "[Configuring tag protection rules](/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/configuring-tag-protection-rules)."
|
||||
- **Delete protected tags**: Delete tags that match a tag protection rule. For more information, see "[Configuring tag protection rules](/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/configuring-tag-protection-rules)."
|
||||
- **设置里程碑**：将里程碑添加到议题或拉取请求。
|
||||
- **管理 wiki 设置**：打开存储库的 wiki。
|
||||
- **管理项目设置**：打开存储库的项目。
|
||||
- **管理拉取请求合并设置**：选择存储库中允许的合并提交类型，例如合并、压缩或变基。
|
||||
- **管理 {% data variables.product.prodname_pages %} 设置**：为存储库启用 {% data variables.product.prodname_pages %} ，然后选择要发布的分支。 更多信息请参阅“[配置 {% data variables.product.prodname_pages %} 站点的发布来源](/pages/getting-started-with-github-pages/configuring-a-publishing-source-for-your-github-pages-site)”。
|
||||
- **管理 web 挂钩**：将 web 挂钩添加到存储库。
|
||||
- **管理部署密钥**：将部署密钥添加到存储库。
|
||||
- **编辑存储库元数据**：更新存储库描述以及存储库主题。
|
||||
- **设置交互限制**：暂时限制某些用户在公共存储库中发表评论、打开议题或创建拉取请求，以强制执行一段有限的活动。 更多信息请参阅“[限制存储库中的交互](/communities/moderating-comments-and-conversations/limiting-interactions-in-your-repository)”。
|
||||
- **设置社交预览**：将识别图像添加到存储库，该图像在链接存储库时显示在社交媒体平台上。 更多信息请参阅“[自定义仓库的社交媒体审查](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/customizing-your-repositorys-social-media-preview)”。
|
||||
- **推送提交到受保护分支**：推送到标记为受保护分支的分支。
|
||||
- **创建受保护的标记**：创建与标记保护规则匹配的标记。 更多信息请参阅“[配置标记保护规则](/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/configuring-tag-protection-rules)”。
|
||||
- **删除受保护的标记**：删除与标记保护规则匹配的标记。 更多信息请参阅“[配置标记保护规则](/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/configuring-tag-protection-rules)”。
|
||||
|
||||
### 安全
|
||||
|
||||
- **View {% data variables.product.prodname_code_scanning %} results**: Ability to view {% data variables.product.prodname_code_scanning %} alerts.
|
||||
- **Dismiss or reopen {% data variables.product.prodname_code_scanning %} results**: Ability to dismiss or reopen {% data variables.product.prodname_code_scanning %} alerts.
|
||||
- **Delete {% data variables.product.prodname_code_scanning %} results**: Ability to delete {% data variables.product.prodname_code_scanning %} alerts.
|
||||
- **View {% data variables.product.prodname_dependabot_alerts %}**: Ability to view {% data variables.product.prodname_dependabot_alerts %}.
|
||||
- **Dismiss or reopen {% data variables.product.prodname_dependabot_alerts %}**: Ability to dismiss or reopen {% data variables.product.prodname_dependabot_alerts %}.
|
||||
- **View {% data variables.product.prodname_secret_scanning %} results**: Ability to view {% data variables.product.prodname_secret_scanning %} alerts.
|
||||
- **Dismiss or reopen {% data variables.product.prodname_secret_scanning %} results**: Ability to dismiss or reopen {% data variables.product.prodname_secret_scanning %} alerts.
|
||||
- **查看 {% data variables.product.prodname_code_scanning %} 结果**：能够查看 {% data variables.product.prodname_code_scanning %} 警报。
|
||||
- **忽略或重新打开 {% data variables.product.prodname_code_scanning %} 结果**：能够忽略或重新打开 {% data variables.product.prodname_code_scanning %} 警报。
|
||||
- **删除 {% data variables.product.prodname_code_scanning %} 结果**：能够删除 {% data variables.product.prodname_code_scanning %} 警报。
|
||||
- **查看 {% data variables.product.prodname_dependabot_alerts %}**：能够查看 {% data variables.product.prodname_dependabot_alerts %}。
|
||||
- **忽略或重新打开 {% data variables.product.prodname_dependabot_alerts %}**：能够忽略或重新打开 {% data variables.product.prodname_dependabot_alerts %}。
|
||||
- **查看 {% data variables.product.prodname_secret_scanning %} 结果**：能够查看 {% data variables.product.prodname_secret_scanning %} 警报。
|
||||
- **忽略或重新打开 {% data variables.product.prodname_secret_scanning %} 结果**：能够忽略或重新打开 {% data variables.product.prodname_secret_scanning %} 警报。
|
||||
|
||||
## Precedence for different levels of access
|
||||
## 不同级别访问的优先级
|
||||
|
||||
If a person is given different levels of access through different avenues, such as team membership and the base permissions for an organization, the highest access overrides the others. For example, if an organization owner gives an organization member a custom role that uses the "Read" inherited role, and then an organization owner sets the organization's base permission to "Write", then this custom role will have write access, along with any additional permissions included in the custom role.
|
||||
如果通过不同的途径（如团队成员身份和组织的基本权限）为某人授予不同级别的访问权限，则最高访问权限将覆盖其他访问权限。 例如，如果组织所有者向组织成员提供使用“读取”继承角色的自定义角色，然后组织所有者将组织的基本权限设置为“写入”，则此自定义角色将具有写入权限以及自定义角色中包含的任何其他权限。
|
||||
|
||||
{% data reusables.organizations.mixed-roles-warning %}
|
||||
|
||||
To resolve conflicting access, you can adjust your organization's base permissions or the team's access, or edit the custom role. 更多信息请参阅：
|
||||
要解决冲突的访问权限，您可以调整组织的基本权限或团队的访问权限，或编辑自定义角色。 更多信息请参阅：
|
||||
- “[设置组织的基本权限](/github/setting-up-and-managing-organizations-and-teams/setting-base-permissions-for-an-organization)”
|
||||
- "[管理团队对组织仓库的访问](/organizations/managing-access-to-your-organizations-repositories/managing-team-access-to-an-organization-repository)"
|
||||
- "[Editing a repository role](#editing-a-repository-role)"
|
||||
- "[编辑存储库角色](#editing-a-repository-role)"
|
||||
|
||||
## Creating a repository role
|
||||
## 创建存储库角色
|
||||
|
||||
To create a new repository role, you add permissions to an inherited role and give the custom role a name.
|
||||
要创建新的存储库角色，请向继承的角色添加权限并为自定义角色命名。
|
||||
|
||||
{% data reusables.profile.access_profile %}
|
||||
{% data reusables.profile.access_org %}
|
||||
{% data reusables.organizations.org_settings %}
|
||||
{% data reusables.organizations.org-list %}
|
||||
{% data reusables.organizations.org-settings-repository-roles %}
|
||||
5. Click **Create a Role**. 
|
||||
4. Under "Name", type the name of your repository role. 
|
||||
5. Under "Description", type a description of your repository role. 
|
||||
6. Under "Choose a role to inherit", select the role you want to inherit. 
|
||||
7. Under "Add Permissions", use the drop-down menu to select the permissions you want your custom role to include. 
|
||||
7. Click **Create role**. 
|
||||
5. 单击 **Create a Role（创建角色）**。 
|
||||
4. 在“Name（名称）”下，键入存储库角色的名称。 
|
||||
5. 在“Description（描述）”下，键入存储库角色的描述。 
|
||||
6. 在“Choose a role to inherit（选择要继承的角色）”下，选择要继承的角色。 
|
||||
7. 在“Add Permissions（添加权限）”下，使用下拉菜单选择您希望自定义角色包含的权限。 
|
||||
7. 单击 **Create a role（创建角色）**。 
|
||||
|
||||
## Editing a repository role
|
||||
## 编辑存储库角色
|
||||
|
||||
{% data reusables.profile.access_profile %}
|
||||
{% data reusables.profile.access_org %}
|
||||
{% data reusables.organizations.org_settings %}
|
||||
{% data reusables.organizations.org-list %}
|
||||
{% data reusables.organizations.org-settings-repository-roles %}
|
||||
3. To the right of the role you want to edit, click {% octicon "kebab-horizontal" aria-label="The horizontal kebab icon" %}, then click **Edit**. 
|
||||
4. Edit, then click **Update role**. 
|
||||
3. 在要删除的角色的右侧，单击 {% octicon "kebab-horizontal" aria-label="The horizontal kebab icon" %}，然后单击 **Edit（编辑）**。 
|
||||
4. 编辑，然后单击 **Update role（更新角色）**。 
|
||||
|
||||
## Deleting a repository role
|
||||
## 删除存储库角色
|
||||
|
||||
If you delete an existing repository role, all pending invitations, teams, and users with the custom role will be reassigned to the organization's base permissions.
|
||||
如果您删除现有存储库角色，则所有具有自定义角色的待处理邀请、团队和用户都将被重新分配给组织的基本权限。
|
||||
|
||||
{% data reusables.profile.access_profile %}
|
||||
{% data reusables.profile.access_org %}
|
||||
{% data reusables.organizations.org_settings %}
|
||||
{% data reusables.organizations.org-list %}
|
||||
{% data reusables.organizations.org-settings-repository-roles %}
|
||||
3. To the right of the role you want to delete, click {% octicon "kebab-horizontal" aria-label="The horizontal kebab icon" %}, then click **Delete**. 
|
||||
4. Review changes for the role you want to remove, then click **Delete role**. 
|
||||
3. 在要删除的角色的右侧，单击 {% octicon "kebab-horizontal" aria-label="The horizontal kebab icon" %}，然后单击 **Delete（删除）**。 
|
||||
4. 查看要删除的角色的更改，然后单击 **Delete role（删除角色）**。 
|
||||
|
||||
@@ -17,9 +17,11 @@ topics:
|
||||
shortTitle: 请求 PR 审查
|
||||
---
|
||||
|
||||
用户帐户拥有的仓库的所有者和协作者可以分配拉取请求审查。 拥有仓库查验漏洞权限的组织成员可以分配拉取请求审查。
|
||||
Repositories belong to a personal account (a single individual owner) or an organization account (a shared account with numerous collaborators or maintainers). 更多信息请参阅“[{% data variables.product.prodname_dotcom %} 帐户的类型](/get-started/learning-about-github/types-of-github-accounts)”。 Owners and collaborators on a repository owned by a personal account can assign pull request reviews. Organization members with triage permissions can also assign a reviewer for a pull request.
|
||||
|
||||
所有者或协作者可以将拉取请求审核分配给被明确授予用户拥有仓库[读取权限](/articles/access-permissions-on-github)的任何人。 组织成员也可将拉取请求审查分配给拥有仓库读取权限的任何个人或团队。 被请求的审查者或团队将收到您请求他们审查拉取请求的通知。 {% ifversion fpt or ghae or ghes or ghec %}如果您请求团队审查，并且启用了代码审查分配，则会向特定成员发出申请，并且取消团队作为审查者。 For more information, see "[Managing code review settings for your team](/organizations/organizing-members-into-teams/managing-code-review-settings-for-your-team)."{% endif %}
|
||||
To assign a reviewer to a pull request, you will need write access to the repository. For more information about repository access, see "[Repository roles for an organization](/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization)." If you have write access, you can assign anyone who has read access to the repository as a reviewer.
|
||||
|
||||
Organization members with write access can also assign a pull request review to any person or team with read access to a repository. 被请求的审查者或团队将收到您请求他们审查拉取请求的通知。 {% ifversion fpt or ghae or ghes or ghec %}如果您请求团队审查，并且启用了代码审查分配，则会向特定成员发出申请，并且取消团队作为审查者。 For more information, see "[Managing code review settings for your team](/organizations/organizing-members-into-teams/managing-code-review-settings-for-your-team)."{% endif %}
|
||||
|
||||
{% note %}
|
||||
|
||||
|
||||
@@ -38,7 +38,7 @@ topics:
|
||||
|
||||
为使代码所有者接收审查请求，CODEOWNERS 文件必须在拉取请求的基本分支上。 例如，如果您将 `@octocat` 分配为仓库 `gh-pages` 分支上 *.js* 文件的代码所有者，则在头部分支与 `gh-pages` 之间打开更改 *.js* 文件的拉取请求时，`@octocat` 将会收到审查请求。
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.2 or ghae-issue-9273 %}
|
||||
{% ifversion fpt or ghec or ghes > 3.2 or ghae-issue-4675 %}
|
||||
## CODEOWNERS 文件大小
|
||||
|
||||
CODEOWNERS 文件大小必须低于 3MB。 将不会加载超过此限制的 CODEOWNERS 文件，这意味着不会显示代码所有者信息，并且不会要求相应的代码所有者查看拉取请求中的更改。
|
||||
|
||||
@@ -7,7 +7,7 @@ versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '>3.2'
|
||||
ghae-issue-4974: '*'
|
||||
ghae: issue-4974
|
||||
topics:
|
||||
- Repositories
|
||||
---
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Codespaces
|
||||
intro: 'The {% data variables.product.prodname_codespaces %} API enables you to manage your codespaces using the REST API.'
|
||||
intro: '{% data variables.product.prodname_codespaces %} API 允许您使用 REST API 管理代码空间。'
|
||||
product: '{% data reusables.gated-features.codespaces %}'
|
||||
versions:
|
||||
fpt: '*'
|
||||
@@ -12,4 +12,4 @@ miniTocMaxHeadingLevel: 3
|
||||
|
||||
<!--
|
||||
Operations are automatically generated. Markdown for this page is located in data/reusables/rest-reference/codespaces
|
||||
-->
|
||||
-->
|
||||
|
||||
@@ -76,6 +76,7 @@ sections:
|
||||
- The latest release of the CodeQL CLI supports uploading analysis results to GitHub. This makes it easier to run code analysis for customers who wish to use CI/CD systems other than {% data variables.product.prodname_actions %}. Previously, such users had to use the separate CodeQL runner, which will continue to be available. For more information, see "[About CodeQL code scanning in your CI system](/enterprise-server@3.1/code-security/secure-coding/about-codeql-code-scanning-in-your-ci-system)."
|
||||
- '{% data variables.product.prodname_actions %} now supports skipping `push` and `pull_request` workflows by looking for some common keywords in your commit message.'
|
||||
- Check annotations older than four months will be archived.
|
||||
- Scaling of worker allocation for background tasks has been revised. We recommend validating that the new defaults are appropriate for your workload. Custom background worker overrides should be unset in most cases. [Updated 2022-03-18]
|
||||
|
||||
- heading: Security Changes
|
||||
notes:
|
||||
|
||||
@@ -29,6 +29,11 @@ sections:
|
||||
notes:
|
||||
- |
|
||||
{% data variables.product.prodname_dependabot %} is now available in {% data variables.product.prodname_ghe_server %} 3.4 as a public beta, offering both version updates and security updates for several popular ecosystems. {% data variables.product.prodname_dependabot %} on {% data variables.product.prodname_ghe_server %} requires {% data variables.product.prodname_actions %} and a pool of self-hosted runners configured for {% data variables.product.prodname_dependabot %} use. {% data variables.product.prodname_dependabot %} on {% data variables.product.prodname_ghe_server %} also requires {% data variables.product.prodname_github_connect %} and {% data variables.product.prodname_dependabot %} to be enabled by an administrator. Beta feedback and suggestions can be shared in the [{% data variables.product.prodname_dependabot %} Feedback GitHub discussion](https://github.com/github/feedback/discussions/categories/dependabot-feedback). For more information and to try the beta, see "[Setting up {% data variables.product.prodname_dependabot %} security and version updates on your enterprise](/admin/github-actions/enabling-github-actions-for-github-enterprise-server/setting-up-dependabot-updates)."
|
||||
-
|
||||
heading: SAML authentication supports encrypted assertions
|
||||
notes:
|
||||
- |
|
||||
If you use SAML authentication for {% data variables.product.prodname_ghe_server %}, you can now configure encrypted assertions from your IdP to improve security. Encrypted assertions add an additional layer of encryption when your IdP transmits information to {% data variables.product.product_location %}. For more information, see "[Using SAML](/admin/identity-and-access-management/authenticating-users-for-your-github-enterprise-server-instance/using-saml#enabling-encrypted-assertions)."
|
||||
changes:
|
||||
-
|
||||
heading: 管理更改
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
{% ifversion ghae %}
|
||||
{% ifversion ghae-issue-5752 %}
|
||||
|
||||
<!-- Remove this reusable and all references for GA release -->
|
||||
|
||||
{% elsif ghae %}
|
||||
|
||||
{% note %}
|
||||
|
||||
|
||||
@@ -1 +1 @@
|
||||
## Custom repository roles
|
||||
## 自定义存储库角色
|
||||
@@ -1,4 +1,9 @@
|
||||
{% ifversion ghae %}
|
||||
{% ifversion ghae-issue-5752 %}
|
||||
|
||||
<!-- Remove this reusable and all references for GA release -->
|
||||
|
||||
{% elsif ghae %}
|
||||
|
||||
{% note %}
|
||||
|
||||
**注意：**组织拥有的仓库的 {% data variables.product.prodname_secret_scanning_caps %} 目前处于公测阶段，可能会有变动。
|
||||
|
||||
@@ -142,7 +142,7 @@ prodname_vs: 'Visual Studio'
|
||||
prodname_vscode: 'Visual Studio Code'
|
||||
prodname_vss_ghe: 'Visual Studio subscriptions with GitHub Enterprise'
|
||||
prodname_vss_admin_portal_with_url: '[Visual Studio 订阅的管理员门户](https://visualstudio.microsoft.com/subscriptions-administration/)'
|
||||
prodname_vscode_command_palette: 'VS Code Command Palette'
|
||||
prodname_vscode_command_palette: 'VS 代码命令面板'
|
||||
#GitHub Dependabot
|
||||
prodname_dependabot: 'Dependabot'
|
||||
prodname_dependabot_alerts: 'Dependabot 警报'
|
||||
|
||||
Reference in New Issue
Block a user