jprdonnelly/docs
1
0
Fork 0
mirror of synced 2026-01-05 12:07:35 -05:00
Code Issues Projects Releases Wiki Activity

Merge branch 'main' into repo-sync

Browse Source
This commit is contained in:
Octomerger Bot
2021-11-04 12:56:47 -04:00
committed by GitHub
parent 7f5ca0b1d8 cae86f2e4d
commit fe3579eb9d
5 changed files with 18 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
content/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services.md
View File

@@ -44,7 +44,7 @@ By default, the validation only includes the audience (`aud`) condition, so you
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "https://github.com/octo-org",
"token.actions.githubusercontent.com:sub": "token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:ref:refs/heads/octo-branch"
"token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:ref:refs/heads/octo-branch"
```
## Updating your {% data variables.product.prodname_actions %} workflow

2
content/actions/hosting-your-own-runners/autoscaling-with-self-hosted-runners.md
View File

@@ -77,4 +77,4 @@ To authenticate using a {% data variables.product.prodname_dotcom %} App, it mu
You can register and delete enterprise self-hosted runners using [the API](/rest/reference/enterprise-admin#github-actions). To authenticate to the API, your autoscaling implementation can use an access token.
Your access token will requite the `manage_runners:enterprise` scope.
Your access token will require the `manage_runners:enterprise` scope.

12
content/actions/learn-github-actions/contexts.md
View File

@@ -41,6 +41,7 @@ Contexts are a way to access information about workflow runs, runner environment
| `strategy` | `object` | Enables access to the configured strategy parameters and information about the current job. Strategy parameters include `fail-fast`, `job-index`, `job-total`, and `max-parallel`. |
| `matrix` | `object` | Enables access to the matrix parameters you configured for the current job. For example, if you configure a matrix build with the `os` and `node` versions, the `matrix` context object includes the `os` and `node` versions of the current job. |
| `needs` | `object` | Enables access to the outputs of all jobs that are defined as a dependency of the current job. For more information, see [`needs` context](#needs-context). |
| `inputs` | `object` | Enables access to the inputs of reusable workflow. For more information, see [`inputs` context](#inputs-context). |
As part of an expression, you may access context information using one of two syntaxes.
- Index syntax: `github['sha']`
@@ -148,6 +149,17 @@ The `needs` context contains outputs from all jobs that are defined as a depende
| `needs.<job id>.outputs.<output name>` | `string` | The value of a specific output for a job that the current job depends on. |
| `needs.<job id>.result` | `string` | The result of a job that the current job depends on. Possible values are `success`, `failure`, `cancelled`, or `skipped`. |
### `inputs` context
The `inputs` context contains information about the inputs of reusable workflow. The inputs are defined in [`workflow_call` event configuration](/actions/learn-github-actions/events-that-trigger-workflows#workflow-reuse-events). These inputs are passed from [`jobs.<job_id>.with`](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idwith) in an external workflow.
For more information, see "[Reusing workflows](/actions/learn-github-actions/reusing-workflows)".
| Property name | Type | Description |
|---------------|------|-------------|
| `inputs` | `object` | This context is only available when it is [a reusable workflow](/actions/learn-github-actions/reusing-workflows). |
| `inputs.<name>` | `string` or `number` or `boolean` | Each input value passed from an external workflow. |
#### Example printing context information to the log file
To inspect the information that is accessible in each context, you can use this workflow file example.

2
content/admin/enterprise-management/configuring-high-availability/about-geo-replication.md
View File

@@ -22,7 +22,7 @@ Geo DNS, such as [Amazon's Route 53 service](http://docs.aws.amazon.com/Route53/
## Limitations
Writing requests to the replica requires sending the data to the primary and all replicas. This means that the performance of all writes are limited by the slowest replica, although new geo-replicas can seed the majority of their data from existing co-located geo-replicas, rather than from the primary. Geo-replication will not add capacity to a {% data variables.product.prodname_ghe_server %} instance or solve performance issues related to insufficient CPU or memory resources. If the primary appliance is offline, active replicas will be unable to serve any read or write requests.
Writing requests to the replica requires sending the data to the primary and all replicas. This means that the performance of all writes is limited by the slowest replica, although new geo-replicas can seed the majority of their data from existing co-located geo-replicas, rather than from the primary. Geo-replication will not add capacity to a {% data variables.product.prodname_ghe_server %} instance or solve performance issues related to insufficient CPU or memory resources. If the primary appliance is offline, active replicas will be unable to serve any read or write requests.
{% data reusables.enterprise_installation.replica-limit %}

6
data/reusables/pull_requests/rebase_and_merge_summary.md
View File

@@ -1,7 +1,7 @@
When you select the **Rebase and merge** option on a pull request on {% data variables.product.product_location %}, all commits from the topic branch (or head branch) are added onto the base branch individually without a merge commit. Pull requests with rebased commits are merged using the [fast-forward option](https://git-scm.com/docs/git-merge#_fast_forward_merge).
When you select the **Rebase and merge** option on a pull request on {% data variables.product.product_location %}, all commits from the topic branch (or head branch) are added onto the base branch individually without a merge commit. In that way, the rebase and merge behavior resembles a [fast-forward merge](https://git-scm.com/docs/git-merge#_fast_forward_merge) by maintaining a linear project history. However, rebasing achieves this by re-writing the commit history on the base branch with new commits.
The rebase and merge behavior on {% data variables.product.product_name %} deviates slightly from `git rebase`. Rebase and merge on {% data variables.product.prodname_dotcom %} will always update the committer information and create new commit SHAs, whereas `git rebase` outside of {% data variables.product.prodname_dotcom %} does not change the committer information when the rebase happens on top of an ancestor commit. For more information about `git rebase`, see [git-rebase](https://git-scm.com/docs/git-rebase) in the Git documentation.
To rebase and merge pull requests, you must have [write permissions](/articles/repository-permission-levels-for-an-organization/) in the repository, and the repository must [allow rebase merging](/articles/configuring-commit-rebasing-for-pull-requests/).
The rebase and merge behavior on {% data variables.product.product_name %} deviates slightly from `git rebase`. Rebase and merge on {% data variables.product.prodname_dotcom %} will always update the committer information and create new commit SHAs, whereas `git rebase` outside of {% data variables.product.prodname_dotcom %} does not change the committer information when the rebase happens on top of an ancestor commit. For more information about `git rebase`, see [the official Git documentation](https://git-scm.com/docs/git-rebase).
For a visual representation of `git rebase`, see [The "Git Branching - Rebasing" chapter from the _Pro Git_ book](https://git-scm.com/book/en/Git-Branching-Rebasing).