New translation batch for cn (#33274)
This commit is contained in:
docubot
@@ -366,6 +366,7 @@ translations/zh-CN/data/reusables/actions/hardware-requirements-3.6.md,file dele
|
||||
translations/zh-CN/data/reusables/actions/link-to-example-library.md,file deleted because it no longer exists in main
|
||||
translations/zh-CN/data/reusables/actions/minio-gateways-removal.md,file deleted because it no longer exists in main
|
||||
translations/zh-CN/data/reusables/actions/perform-blob-storage-precheck.md,file deleted because it no longer exists in main
|
||||
translations/zh-CN/data/reusables/actions/reusable-workflows-ghes-beta.md,file deleted because it no longer exists in main
|
||||
translations/zh-CN/data/reusables/actions/self-hosted-runner-configure-runner-group.md,file deleted because it no longer exists in main
|
||||
translations/zh-CN/data/reusables/actions/self-hosted-runner-groups-navigate-to-repo-org-enterprise.md,file deleted because it no longer exists in main
|
||||
translations/zh-CN/data/reusables/apps/metadata-permissions.md,file deleted because it no longer exists in main
|
||||
@@ -998,6 +999,7 @@ translations/zh-CN/data/reusables/actions/enterprise-postinstall-nextsteps.md,re
|
||||
translations/zh-CN/data/reusables/actions/github-connect-resolution.md,rendering error
|
||||
translations/zh-CN/data/reusables/actions/jobs/section-defining-outputs-for-jobs.md,broken liquid tags
|
||||
translations/zh-CN/data/reusables/actions/jobs/section-running-jobs-in-a-container.md,broken liquid tags
|
||||
translations/zh-CN/data/reusables/actions/jobs/section-using-conditions-to-control-job-execution.md,broken liquid tags
|
||||
translations/zh-CN/data/reusables/actions/more-resources-for-ghes.md,rendering error
|
||||
translations/zh-CN/data/reusables/actions/moving-a-runner-to-a-group.md,rendering error
|
||||
translations/zh-CN/data/reusables/actions/reusable-workflow-artifacts.md,rendering error
|
||||
|
||||
|
@@ -94,7 +94,7 @@ Before you begin, you'll create a repository on {% ifversion ghae %}{% data vari
|
||||
shell: bash
|
||||
```
|
||||
{% endraw %}
|
||||
This file defines the `who-to-greet` input, maps the random generated number to the `random-number` output variable, and runs the `goodbye.sh` script. It also tells the runner how to execute the composite action.
|
||||
This file defines the `who-to-greet` input, maps the random generated number to the `random-number` output variable, adds the action's path to the runner system path (to locate the `goodbye.sh` script during execution), and runs the `goodbye.sh` script.
|
||||
|
||||
For more information about managing outputs, see "[`outputs` for a composite action](/actions/creating-actions/metadata-syntax-for-github-actions#outputs-for-composite-actions)".
|
||||
|
||||
|
||||
@@ -283,6 +283,12 @@ After this setting is applied, the JWT will contain the updated `iss` value. In
|
||||
|
||||
To help improve security, compliance, and standardization, you can customize the standard claims to suit your required access conditions. If your cloud provider supports conditions on subject claims, you can create a condition that checks whether the `sub` value matches the path of the reusable workflow, such as `"job_workflow_ref: "octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main""`. The exact format will vary depending on your cloud provider's OIDC configuration. To configure the matching condition on {% data variables.product.prodname_dotcom %}, you can can use the REST API to require that the `sub` claim must always include a specific custom claim, such as `job_workflow_ref`. You can use the [OIDC REST API](/rest/actions/oidc) to apply a customization template for the OIDC subject claim; for example, you can require that the `sub` claim within the OIDC token must always include a specific custom claim, such as `job_workflow_ref`.
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note**: When the organization template is applied, it will not affect any workflows in existing repositories that already use OIDC. For existing repositories, as well as any new repositories that are created after the template has been applied, the repository owner will need to opt-in to receive this configuration, or alternatively could apply a different configuration specific to the repo. For more information, see "[Set the customization template for an OIDC subject claim for a repository](/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-a-repository)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
Customizing the claims results in a new format for the entire `sub` claim, which replaces the default predefined `sub` format in the token described in "[Example subject claims](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#example-subject-claims)."
|
||||
|
||||
The following example templates demonstrate various ways to customize the subject claim. To configure these settings on {% data variables.product.prodname_dotcom %}, admins use the REST API to specify a list of claims that must be included in the subject (`sub`) claim.
|
||||
@@ -291,12 +297,6 @@ The following example templates demonstrate various ways to customize the subjec
|
||||
|
||||
To customize your subject claims, you should first create a matching condition in your cloud provider's OIDC configuration, before customizing the configuration using the REST API. Once the configuration is completed, each time a new job runs, the OIDC token generated during that job will follow the new customization template. If the matching condition doesn't exist in the cloud provider's OIDC configuration before the job runs, the generated token might not be accepted by the cloud provider, since the cloud conditions may not be synchronized.
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note**: When the organization template is applied, it will not affect any action workflows in existing repositories that already use OIDC. For existing repositories, as well as any new repositories that are created after the template has been applied, the repository owner will need to opt-in to receive this configuration, or alternatively could apply a different configuration specific to the repo. For more information, see "[Set the customization template for an OIDC subject claim for a repository](/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-a-repository)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
#### Example: Allowing repository based on visibility and owner
|
||||
|
||||
This example template allows the `sub` claim to have a new format, using `repository_owner` and `repository_visibility`:
|
||||
@@ -431,7 +431,9 @@ In your cloud provider's OIDC configuration, configure the `sub` condition to re
|
||||
|
||||
#### Using the default subject claims
|
||||
|
||||
For repositories that can receive a subject claim policy from their organization, the repository owner can later choose to opt-out and instead use the default `sub` claim format. To configure this, the repository admin must use the REST API endpoint at "[Set the customization template for an OIDC subject claim for a repository](/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-a-repository)" with the following request body:
|
||||
For repositories that can receive a subject claim policy from their organization, the repository owner can later choose to opt-out and instead use the default `sub` claim format. This means that the repository will not use the organization's customized template.
|
||||
|
||||
To configure the repository to use the default `sub` claim format, a repository admin must use the REST API endpoint at "[Set the customization template for an OIDC subject claim for a repository](/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-a-repository)" with the following request body:
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -439,6 +441,18 @@ For repositories that can receive a subject claim policy from their organization
|
||||
}
|
||||
```
|
||||
|
||||
#### Example: Configuring a repository to use an organization template
|
||||
|
||||
A repository administrator can configure their repository to use the template created by the administrator of their organisation.
|
||||
|
||||
To configure the repository to use the organization's template, a repository admin must use the REST API endpoint at "[Set the customization template for an OIDC subject claim for a repository](/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-a-repository)" with the following request body:
|
||||
|
||||
```json
|
||||
{
|
||||
"use_default": false
|
||||
}
|
||||
```
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Updating your workflows for OIDC
|
||||
|
||||
@@ -811,7 +811,7 @@ The `inputs` context contains input properties passed to an action{% ifversion a
|
||||
|
||||
There are no standard properties in the `inputs` context, only those which are defined in the workflow file.
|
||||
|
||||
{% data reusables.actions.reusable-workflows-ghes-beta %}
|
||||
{% data reusables.actions.reusable-workflows-enterprise-beta %}
|
||||
|
||||
| Property name | Type | Description |
|
||||
|---------------|------|-------------|
|
||||
|
||||
@@ -88,7 +88,7 @@ In addition to the usage limits, you must ensure that you use {% data variables.
|
||||
{% ifversion fpt or ghes > 3.3 or ghec %}
|
||||
## Billing for reusable workflows
|
||||
|
||||
{% data reusables.actions.reusable-workflows-ghes-beta %}
|
||||
{% data reusables.actions.reusable-workflows-enterprise-beta %}
|
||||
|
||||
If you reuse a workflow, billing is always associated with the caller workflow. Assignment of {% data variables.product.prodname_dotcom %}-hosted runners is always evaluated using only the caller's context. The caller cannot use {% data variables.product.prodname_dotcom %}-hosted runners from the called repository.
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@ topics:
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.reusable-workflows-ghes-beta %}
|
||||
{% data reusables.actions.reusable-workflows-enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
## Overview
|
||||
|
||||
@@ -123,7 +123,7 @@ You can use activity types and filters to further control when your workflow wil
|
||||
{% ifversion fpt or ghes > 3.3 or ghae > 3.3 or ghec %}
|
||||
## Defining inputs, outputs, and secrets for reusable workflows
|
||||
|
||||
{% data reusables.actions.reusable-workflows-ghes-beta %}
|
||||
{% data reusables.actions.reusable-workflows-enterprise-beta %}
|
||||
|
||||
You can define inputs and secrets that a reusable workflow should receive from a calling workflow. You can also specify outputs that a reusable workflow will make available to a calling workflow. For more information, see "[Reusing workflows](/actions/using-workflows/reusing-workflows)."
|
||||
|
||||
|
||||
@@ -72,7 +72,7 @@ run-name: Deploy to ${{ inputs.deploy_target }} by @${{ github.actor }}
|
||||
{% ifversion fpt or ghes > 3.3 or ghae > 3.3 or ghec %}
|
||||
## `on.workflow_call`
|
||||
|
||||
{% data reusables.actions.reusable-workflows-ghes-beta %}
|
||||
{% data reusables.actions.reusable-workflows-enterprise-beta %}
|
||||
|
||||
Use `on.workflow_call` to define the inputs and outputs for a reusable workflow. You can also map the secrets that are available to the called workflow. For more information on reusable workflows, see "[Reusing workflows](/actions/using-workflows/reusing-workflows)."
|
||||
|
||||
@@ -320,7 +320,7 @@ A unique identifier for the step. You can use the `id` to reference the step in
|
||||
|
||||
### `jobs.<job_id>.steps[*].if`
|
||||
|
||||
You can use the `if` conditional to prevent a step from running unless a condition is met. You can use any supported context and expression to create a conditional.
|
||||
You can use the `if` conditional to prevent a step from running unless a condition is met. {% data reusables.actions.if-supported-contexts %}
|
||||
|
||||
{% data reusables.actions.expression-syntax-if %} For more information, see "[Expressions](/actions/learn-github-actions/expressions)."
|
||||
|
||||
@@ -945,7 +945,7 @@ Additional Docker container resource options. For a list of options, see "[`dock
|
||||
{% ifversion fpt or ghes > 3.3 or ghae > 3.3 or ghec %}
|
||||
## `jobs.<job_id>.uses`
|
||||
|
||||
{% data reusables.actions.reusable-workflows-ghes-beta %}
|
||||
{% data reusables.actions.reusable-workflows-enterprise-beta %}
|
||||
|
||||
The location and version of a reusable workflow file to run as a job. {% ifversion fpt or ghec or ghes > 3.4 or ghae > 3.4 %}Use one of the following syntaxes:{% endif %}
|
||||
|
||||
|
||||
@@ -72,7 +72,7 @@ Think about how your enterprise can use features of {% data variables.product.pr
|
||||
{% data reusables.actions.internal-actions-summary %}
|
||||
|
||||
{% ifversion ghec or ghes > 3.3 or ghae > 3.3 %}
|
||||
{% data reusables.actions.reusable-workflows-ghes-beta %}
|
||||
{% data reusables.actions.reusable-workflows-enterprise-beta %}
|
||||
With reusable workflows, your team can call one workflow from another workflow, avoiding exact duplication. Reusable workflows promote best practice by helping your team use workflows that are well designed and have already been tested. For more information, see "[Reusing workflows](/actions/learn-github-actions/reusing-workflows)."
|
||||
{% endif %}
|
||||
|
||||
|
||||
@@ -67,7 +67,9 @@ The storage used by a repository is the total storage used by {% data variables.
|
||||
### Per-minute rates
|
||||
|
||||
{% data reusables.billing.billing-standard-runners %}
|
||||
{%- ifversion actions-hosted-runners %}{% data reusables.billing.billing-hosted-runners %}{%- endif %}
|
||||
{%- ifversion actions-hosted-runners %}
|
||||
{% data reusables.billing.billing-hosted-runners %}
|
||||
{%- endif %}
|
||||
|
||||
- The number of jobs you can run concurrently across all repositories in your user or organization account depends on your GitHub plan. For more information, see "[Usage limits and billing](/actions/reference/usage-limits-billing-and-administration)" for {% data variables.product.prodname_dotcom %}-hosted runners and "[About self-hosted runners](/actions/hosting-your-own-runners/about-self-hosted-runners/#usage-limits)" for self-hosted runner usage limits.
|
||||
- {% data reusables.user-settings.context_switcher %}
|
||||
|
||||
@@ -1,18 +1,10 @@
|
||||
---
|
||||
ms.openlocfilehash: 543455f8802e8e2c8b4dc60283c442a536476751
|
||||
ms.sourcegitcommit: fb047f9450b41b24afc43d9512a5db2a2b750a2a
|
||||
ms.translationtype: HT
|
||||
ms.contentlocale: zh-CN
|
||||
ms.lasthandoff: 09/11/2022
|
||||
ms.locfileid: "145098450"
|
||||
---
|
||||
可以使用 `jobs.<job_id>.if` 条件来阻止步骤运行，除非满足条件。 您可以使用任何支持上下文和表达式来创建条件。
|
||||
You can use the `jobs.<job_id>.if` conditional to prevent a job from running unless a condition is met. {% data reusables.actions.if-supported-contexts %}
|
||||
|
||||
{% data reusables.actions.expression-syntax-if %} 有关详细信息，请参阅“[表达式](/actions/learn-github-actions/expressions)”。
|
||||
{% data reusables.actions.expression-syntax-if %} For more information, see "[Expressions](/actions/learn-github-actions/expressions)."
|
||||
|
||||
### 示例：仅针对特定存储库运行作业
|
||||
### Example: Only run job for specific repository
|
||||
|
||||
此示例使用 `if` 控制 `production-deploy` 作业何时可以运行。 仅当存储库名为 `octo-repo-prod` 且位于 `octo-org` 组织内时，它才会运行。 否则，作业将被标记为“跳过”。
|
||||
This example uses `if` to control when the `production-deploy` job can run. It will only run if the repository is named `octo-repo-prod` and is within the `octo-org` organization. Otherwise, the job will be marked as _skipped_.
|
||||
|
||||
```yaml{:copy}
|
||||
name: example-workflow
|
||||
|
||||
@@ -1,17 +0,0 @@
|
||||
---
|
||||
ms.openlocfilehash: 933805023c32c3e956b510000cdaff7326b880e3
|
||||
ms.sourcegitcommit: fcf3546b7cc208155fb8acdf68b81be28afc3d2d
|
||||
ms.translationtype: HT
|
||||
ms.contentlocale: zh-CN
|
||||
ms.lasthandoff: 09/10/2022
|
||||
ms.locfileid: "145065894"
|
||||
---
|
||||
{% ifversion ghes = 3.4 %}
|
||||
|
||||
{% note %}
|
||||
|
||||
注意：可重用工作流目前处于 beta 版本阶段，可能会更改。
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{% endif %}
|
||||
Reference in New Issue
Block a user