зеркало из https://github.com/github/docs.git
update old rest links (#49572)
This commit is contained in:
Родитель
d8d87d0f8a
Коммит
040a77ffcb
|
@ -153,7 +153,7 @@ You can also build an app that uses deployment and deployment status webhooks to
|
|||
|
||||
## Choosing a runner
|
||||
|
||||
You can run your deployment workflow on {% data variables.product.company_short %}-hosted runners or on self-hosted runners. Traffic from {% data variables.product.company_short %}-hosted runners can come from a [wide range of network addresses](/rest/meta#get-github-meta-information). If you are deploying to an internal environment and your company restricts external traffic into private networks, {% data variables.product.prodname_actions %} workflows running on {% data variables.product.company_short %}-hosted runners may not be able to communicate with your internal services or resources. To overcome this, you can host your own runners. For more information, see "[AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners)" and "[AUTOTITLE](/actions/using-github-hosted-runners/about-github-hosted-runners)."
|
||||
You can run your deployment workflow on {% data variables.product.company_short %}-hosted runners or on self-hosted runners. Traffic from {% data variables.product.company_short %}-hosted runners can come from a [wide range of network addresses](/rest/meta/meta#get-github-meta-information). If you are deploying to an internal environment and your company restricts external traffic into private networks, {% data variables.product.prodname_actions %} workflows running on {% data variables.product.company_short %}-hosted runners may not be able to communicate with your internal services or resources. To overcome this, you can host your own runners. For more information, see "[AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners)" and "[AUTOTITLE](/actions/using-github-hosted-runners/about-github-hosted-runners)."
|
||||
|
||||
## Displaying a status badge
|
||||
|
||||
|
|
|
@ -47,7 +47,7 @@ You can add self-hosted runners to a single repository. To add a self-hosted run
|
|||
|
||||
{% ifversion custom-org-roles %}For more information about custom organization roles, see "[AUTOTITLE](/organizations/managing-peoples-access-to-your-organization-with-roles/about-custom-organization-roles)."{% endif %}
|
||||
|
||||
For information about how to add a self-hosted runner with the REST API, see "[AUTOTITLE](/rest/actions#self-hosted-runners)."
|
||||
For information about how to add a self-hosted runner with the REST API, see "[AUTOTITLE](/rest/actions/self-hosted-runners)."
|
||||
|
||||
{% ifversion actions-disable-repo-runners %}
|
||||
|
||||
|
@ -70,7 +70,7 @@ For more information, see "[AUTOTITLE](/actions/hosting-your-own-runners/managin
|
|||
|
||||
## Adding a self-hosted runner to an organization
|
||||
|
||||
You can add self-hosted runners at the organization level, where they can be used to process jobs for multiple repositories in an organization. To add a self-hosted runner to an organization, you must be an organization owner{% ifversion custom-org-roles %} or have the "Manage organization runners and runner groups" permission{% endif %}. For information about how to add a self-hosted runner with the REST API, see "[AUTOTITLE](/rest/actions#self-hosted-runners)."
|
||||
You can add self-hosted runners at the organization level, where they can be used to process jobs for multiple repositories in an organization. To add a self-hosted runner to an organization, you must be an organization owner{% ifversion custom-org-roles %} or have the "Manage organization runners and runner groups" permission{% endif %}. For information about how to add a self-hosted runner with the REST API, see "[AUTOTITLE](/rest/actions/self-hosted-runners)."
|
||||
|
||||
{% ifversion custom-org-roles %}For more information about custom organization roles, see "[AUTOTITLE](/organizations/managing-peoples-access-to-your-organization-with-roles/about-custom-organization-roles)."{% endif %}
|
||||
|
||||
|
@ -94,7 +94,7 @@ New runners are assigned to the default group. You can modify the runner's group
|
|||
|
||||
{% ifversion ghec or ghes %}
|
||||
|
||||
To add a self-hosted runner to an enterprise, you must be an enterprise owner. For information about how to add a self-hosted runner with the REST API, see the enterprise endpoints in the [{% data variables.product.prodname_actions %} REST API](/rest/actions#self-hosted-runners).
|
||||
To add a self-hosted runner to an enterprise, you must be an enterprise owner. For information about how to add a self-hosted runner with the REST API, see the enterprise endpoints in the [{% data variables.product.prodname_actions %} REST API](/rest/actions/self-hosted-runners).
|
||||
|
||||
{% endif %}
|
||||
|
||||
|
|
|
@ -47,7 +47,7 @@ The {% data variables.product.prodname_actions %} service will then automaticall
|
|||
|
||||
{% ifversion actions-single-use-tokens %}
|
||||
|
||||
Alternatively, you can create ephemeral, just-in-time runners using the REST API. For more information, see "[AUTOTITLE](/rest/actions#self-hosted-runners)."
|
||||
Alternatively, you can create ephemeral, just-in-time runners using the REST API. For more information, see "[AUTOTITLE](/rest/actions/self-hosted-runners)."
|
||||
|
||||
{% endif %}
|
||||
|
||||
|
@ -82,7 +82,7 @@ You can create your own autoscaling environment by using payloads received from
|
|||
|
||||
## Authentication requirements
|
||||
|
||||
You can register and delete repository and organization self-hosted runners using [the API](/rest/actions#self-hosted-runners). To authenticate to the API, your autoscaling implementation can use an access token or a {% data variables.product.prodname_dotcom %} app.
|
||||
You can register and delete repository and organization self-hosted runners using [the API](/rest/actions/self-hosted-runners). To authenticate to the API, your autoscaling implementation can use an access token or a {% data variables.product.prodname_dotcom %} app.
|
||||
|
||||
Your access token will require the following scope:
|
||||
|
||||
|
@ -94,6 +94,6 @@ To authenticate using a {% data variables.product.prodname_dotcom %} App, it mu
|
|||
- For repositories, assign the `administration` permission.
|
||||
- For organizations, assign the `organization_self_hosted_runners` permission.
|
||||
|
||||
You can register and delete enterprise self-hosted runners using [the API](/rest/actions#self-hosted-runners). To authenticate to the API, your autoscaling implementation can use an access token.
|
||||
You can register and delete enterprise self-hosted runners using [the API](/rest/actions/self-hosted-runners). To authenticate to the API, your autoscaling implementation can use an access token.
|
||||
|
||||
Your access token will require the `manage_runners:enterprise` scope.
|
||||
|
|
|
@ -33,7 +33,7 @@ To remove a self-hosted runner from a user repository you must be the repository
|
|||
|
||||
We recommend that you also have access to the self-hosted runner machine.
|
||||
|
||||
For information about how to remove a self-hosted runner with the REST API, see "[AUTOTITLE](/rest/actions#self-hosted-runners)."
|
||||
For information about how to remove a self-hosted runner with the REST API, see "[AUTOTITLE](/rest/actions/self-hosted-runners)."
|
||||
|
||||
{% data reusables.actions.self-hosted-runner-reusing %}
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
|
@ -56,7 +56,7 @@ For information about how to remove a self-hosted runner with the REST API, see
|
|||
|
||||
{% endnote %}
|
||||
|
||||
To remove a self-hosted runner from an organization, you must be an organization owner{% ifversion custom-org-roles %} or have the "Manage organization runners and runner groups" permission{% endif %}. We recommend that you also have access to the self-hosted runner machine. For information about how to remove a self-hosted runner with the REST API, see "[AUTOTITLE](/rest/actions#self-hosted-runners)."
|
||||
To remove a self-hosted runner from an organization, you must be an organization owner{% ifversion custom-org-roles %} or have the "Manage organization runners and runner groups" permission{% endif %}. We recommend that you also have access to the self-hosted runner machine. For information about how to remove a self-hosted runner with the REST API, see "[AUTOTITLE](/rest/actions/self-hosted-runners)."
|
||||
|
||||
{% ifversion custom-org-roles %}For more information about custom organization roles, see "[AUTOTITLE](/organizations/managing-peoples-access-to-your-organization-with-roles/about-custom-organization-roles)."{% endif %}
|
||||
|
||||
|
@ -84,7 +84,7 @@ If you use {% data variables.product.prodname_ghe_cloud %}, you can also remove
|
|||
{%- endif %}
|
||||
{% endnote %}
|
||||
|
||||
To remove a self-hosted runner from an enterprise, you must be an enterprise owner. We recommend that you also have access to the self-hosted runner machine. For information about how to remove a self-hosted runner with the REST API, see the enterprise endpoints in the [{% data variables.product.prodname_actions %} REST API](/rest/actions#self-hosted-runners).
|
||||
To remove a self-hosted runner from an enterprise, you must be an enterprise owner. We recommend that you also have access to the self-hosted runner machine. For information about how to remove a self-hosted runner with the REST API, see the enterprise endpoints in the [{% data variables.product.prodname_actions %} REST API](/rest/actions/self-hosted-runners).
|
||||
|
||||
{% data reusables.actions.self-hosted-runner-reusing %}
|
||||
{% ifversion ghec or ghes %}
|
||||
|
|
|
@ -57,7 +57,7 @@ For more information about workflows, see "[AUTOTITLE](/actions/using-workflows)
|
|||
|
||||
### Events
|
||||
|
||||
An event is a specific activity in a repository that triggers a workflow run. For example, activity can originate from {% data variables.product.prodname_dotcom %} when someone creates a pull request, opens an issue, or pushes a commit to a repository. You can also trigger a workflow to run on a [schedule](/actions/using-workflows/events-that-trigger-workflows#schedule), by [posting to a REST API](/rest/repos#create-a-repository-dispatch-event), or manually.
|
||||
An event is a specific activity in a repository that triggers a workflow run. For example, activity can originate from {% data variables.product.prodname_dotcom %} when someone creates a pull request, opens an issue, or pushes a commit to a repository. You can also trigger a workflow to run on a [schedule](/actions/using-workflows/events-that-trigger-workflows#schedule), by [posting to a REST API](/rest/repos/repos#create-a-repository-dispatch-event), or manually.
|
||||
|
||||
For a complete list of events that can be used to trigger workflows, see [Events that trigger workflows](/actions/using-workflows/events-that-trigger-workflows).
|
||||
|
||||
|
|
|
@ -144,7 +144,7 @@ gh run rerun --job JOB_ID --debug
|
|||
|
||||
## Reviewing previous workflow runs
|
||||
|
||||
You can view the results from your previous attempts at running a workflow. You can also view previous workflow runs using the API. For more information, see "[AUTOTITLE](/rest/actions#get-a-workflow-run)."
|
||||
You can view the results from your previous attempts at running a workflow. You can also view previous workflow runs using the API. For more information, see "[AUTOTITLE](/rest/actions/workflow-runs#get-a-workflow-run)."
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.actions-tab %}
|
||||
|
|
|
@ -14,7 +14,7 @@ versions:
|
|||
|
||||
Jobs that reference an environment configured with required reviewers will wait for an approval before starting. While a job is awaiting approval, it has a status of "Waiting". If a job is not approved within 30 days, it will automatically fail.
|
||||
|
||||
For more information about environments and required approvals, see "[AUTOTITLE](/actions/deployment/targeting-different-environments/using-environments-for-deployment)." For information about how to review deployments with the REST API, see "[AUTOTITLE](/rest/actions#workflow-runs)."
|
||||
For more information about environments and required approvals, see "[AUTOTITLE](/actions/deployment/targeting-different-environments/using-environments-for-deployment)." For information about how to review deployments with the REST API, see "[AUTOTITLE](/rest/actions/workflow-runs)."
|
||||
|
||||
## Approving or rejecting a job
|
||||
|
||||
|
|
|
@ -25,7 +25,7 @@ This guide explains how to configure security hardening for certain {% data vari
|
|||
Sensitive values should never be stored as plaintext in workflow files, but rather as secrets. [Secrets](/actions/security-guides/using-secrets-in-github-actions) can be configured at the organization, repository, or environment level, and allow you to store sensitive information in {% data variables.product.product_name %}.
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
Secrets use [Libsodium sealed boxes](https://libsodium.gitbook.io/doc/public-key_cryptography/sealed_boxes), so that they are encrypted before reaching {% data variables.product.product_name %}. This occurs when the secret is submitted [using the UI](/actions/security-guides/using-secrets-in-github-actions#creating-secrets-for-a-repository) or through the [REST API](/rest/actions#secrets). This client-side encryption helps minimize the risks related to accidental logging (for example, exception logs and request logs, among others) within {% data variables.product.product_name %}'s infrastructure. Once the secret is uploaded, {% data variables.product.product_name %} is then able to decrypt it so that it can be injected into the workflow runtime.
|
||||
Secrets use [Libsodium sealed boxes](https://libsodium.gitbook.io/doc/public-key_cryptography/sealed_boxes), so that they are encrypted before reaching {% data variables.product.product_name %}. This occurs when the secret is submitted [using the UI](/actions/security-guides/using-secrets-in-github-actions#creating-secrets-for-a-repository) or through the [REST API](/rest/actions/secrets). This client-side encryption helps minimize the risks related to accidental logging (for example, exception logs and request logs, among others) within {% data variables.product.product_name %}'s infrastructure. Once the secret is uploaded, {% data variables.product.product_name %} is then able to decrypt it so that it can be injected into the workflow runtime.
|
||||
{% endif %}
|
||||
|
||||
To help prevent accidental disclosure, {% data variables.product.product_name %} uses a mechanism that attempts to redact any secrets that appear in run logs. This redaction looks for exact matches of any configured secrets used within the job, as well as common encodings of the values, such as Base64. However, because there are multiple ways a secret value can be transformed, this redaction is not guaranteed. Additionally, the runner can only redact secrets used within the current job. As a result, there are certain proactive steps and good practices you should follow to help ensure secrets are redacted, and to limit other risks associated with secrets:
|
||||
|
|
|
@ -54,7 +54,7 @@ You can use and read secrets in a workflow file if you have access to edit the f
|
|||
|
||||
Organization and repository secrets are read when a workflow run is queued, and environment secrets are read when a job referencing the environment starts.
|
||||
|
||||
You can also manage secrets using the REST API. For more information, see "[AUTOTITLE](/rest/actions#secrets)."
|
||||
You can also manage secrets using the REST API. For more information, see "[AUTOTITLE](/rest/actions/secrets)."
|
||||
|
||||
### Limiting credential permissions
|
||||
|
||||
|
@ -66,7 +66,7 @@ Instead of using a {% data variables.product.pat_generic %}, consider using a {%
|
|||
|
||||
{% note %}
|
||||
|
||||
**Note:** Users with collaborator access to a repository can use the REST API to manage secrets for that repository, and users with admin access to an organization can use the REST API to manage secrets for that organization. For more information, see "[AUTOTITLE](/rest/actions#secrets)."
|
||||
**Note:** Users with collaborator access to a repository can use the REST API to manage secrets for that repository, and users with admin access to an organization can use the REST API to manage secrets for that organization. For more information, see "[AUTOTITLE](/rest/actions/secrets)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
|
|
|
@ -190,7 +190,7 @@ Windows virtual machines are configured to run as administrators with User Accou
|
|||
|
||||
## IP addresses
|
||||
|
||||
To get a list of IP address ranges that {% data variables.product.prodname_actions %} uses for {% data variables.product.prodname_dotcom %}-hosted runners, you can use the {% data variables.product.prodname_dotcom %} REST API. For more information, see the `actions` key in the response of the `GET /meta` endpoint. For more information, see "[AUTOTITLE](/rest/meta#get-github-meta-information)."
|
||||
To get a list of IP address ranges that {% data variables.product.prodname_actions %} uses for {% data variables.product.prodname_dotcom %}-hosted runners, you can use the {% data variables.product.prodname_dotcom %} REST API. For more information, see the `actions` key in the response of the `GET /meta` endpoint. For more information, see "[AUTOTITLE](/rest/meta/meta#get-github-meta-information)."
|
||||
|
||||
Windows and Ubuntu runners are hosted in Azure and subsequently have the same IP address ranges as the Azure datacenters. macOS runners are hosted in {% data variables.product.prodname_dotcom %}'s own macOS cloud.
|
||||
|
||||
|
|
|
@ -27,7 +27,7 @@ Temporarily disabling a workflow can be useful in many scenarios. These are a fe
|
|||
|
||||
{% endwarning %}
|
||||
|
||||
You can also disable and enable a workflow using the REST API. For more information, see "[AUTOTITLE](/rest/actions#workflows)."
|
||||
You can also disable and enable a workflow using the REST API. For more information, see "[AUTOTITLE](/rest/actions/workflows)."
|
||||
|
||||
## Disabling a workflow
|
||||
|
||||
|
|
|
@ -64,7 +64,7 @@ on:
|
|||
|
||||
{% data reusables.actions.branch-requirement %}
|
||||
|
||||
Runs your workflow when activity related to a check run occurs. A check run is an individual test that is part of a check suite. For information, see "[AUTOTITLE](/rest/guides/using-the-rest-api-to-interact-with-checks)." For information about the check run APIs, see "[AUTOTITLE](/graphql/reference/objects#checkrun)" in the GraphQL API documentation or "[AUTOTITLE](/rest/checks#runs)."
|
||||
Runs your workflow when activity related to a check run occurs. A check run is an individual test that is part of a check suite. For information, see "[AUTOTITLE](/rest/guides/using-the-rest-api-to-interact-with-checks)." For information about the check run APIs, see "[AUTOTITLE](/graphql/reference/objects#checkrun)" in the GraphQL API documentation or "[AUTOTITLE](/rest/checks/runs)."
|
||||
|
||||
For example, you can run a workflow when a check run has been `rerequested` or `completed`.
|
||||
|
||||
|
@ -94,7 +94,7 @@ on:
|
|||
|
||||
{% endnote %}
|
||||
|
||||
Runs your workflow when check suite activity occurs. A check suite is a collection of the check runs created for a specific commit. Check suites summarize the status and conclusion of the check runs that are in the suite. For information, see "[AUTOTITLE](/rest/guides/using-the-rest-api-to-interact-with-checks)." For information about the check suite APIs, see "[AUTOTITLE](/graphql/reference/objects#checksuite)" in the GraphQL API documentation or "[AUTOTITLE](/rest/checks#suites)."
|
||||
Runs your workflow when check suite activity occurs. A check suite is a collection of the check runs created for a specific commit. Check suites summarize the status and conclusion of the check runs that are in the suite. For information, see "[AUTOTITLE](/rest/guides/using-the-rest-api-to-interact-with-checks)." For information about the check suite APIs, see "[AUTOTITLE](/graphql/reference/objects#checksuite)" in the GraphQL API documentation or "[AUTOTITLE](/rest/checks/suites)."
|
||||
|
||||
For example, you can run a workflow when a check suite has been `completed`.
|
||||
|
||||
|
@ -116,7 +116,7 @@ on:
|
|||
|
||||
{% endnote %}
|
||||
|
||||
Runs your workflow when someone creates a Git reference (Git branch or tag) in the workflow's repository. For information about the APIs to create a Git reference, see "[AUTOTITLE](/graphql/reference/mutations#createref)" in the GraphQL API documentation or "[AUTOTITLE](/rest/git#create-a-reference)."
|
||||
Runs your workflow when someone creates a Git reference (Git branch or tag) in the workflow's repository. For information about the APIs to create a Git reference, see "[AUTOTITLE](/graphql/reference/mutations#createref)" in the GraphQL API documentation or "[AUTOTITLE](/rest/git/refs#create-a-reference)."
|
||||
|
||||
For example, you can run a workflow when the `create` event occurs.
|
||||
|
||||
|
@ -139,7 +139,7 @@ on:
|
|||
|
||||
{% endnote %}
|
||||
|
||||
Runs your workflow when someone deletes a Git reference (Git branch or tag) in the workflow's repository. For information about the APIs to delete a Git reference, see "[AUTOTITLE](/graphql/reference/mutations#deleteref)" in the GraphQL API documentation or "[AUTOTITLE](/rest/git#delete-a-reference)."
|
||||
Runs your workflow when someone deletes a Git reference (Git branch or tag) in the workflow's repository. For information about the APIs to delete a Git reference, see "[AUTOTITLE](/graphql/reference/mutations#deleteref)" in the GraphQL API documentation or "[AUTOTITLE](/rest/git/refs#delete-a-reference)."
|
||||
|
||||
For example, you can run a workflow when the `delete` event occurs.
|
||||
|
||||
|
@ -248,7 +248,7 @@ on:
|
|||
|
||||
{% data reusables.actions.branch-requirement %}
|
||||
|
||||
Runs your workflow when someone forks a repository. For information about the REST API, see "[AUTOTITLE](/rest/repos#create-a-fork)."
|
||||
Runs your workflow when someone forks a repository. For information about the REST API, see "[AUTOTITLE](/rest/repos/forks#create-a-fork)."
|
||||
|
||||
For example, you can run a workflow when the `fork` event occurs.
|
||||
|
||||
|
@ -369,7 +369,7 @@ on:
|
|||
|
||||
{% data reusables.actions.branch-requirement %}
|
||||
|
||||
Runs your workflow when a label in your workflow's repository is created or modified. For more information about labels, see "[AUTOTITLE](/issues/using-labels-and-milestones-to-track-work/managing-labels)." For information about the label APIs, see "[AUTOTITLE](/graphql/reference/objects#label)" in the GraphQL API documentation or "[AUTOTITLE](/rest/issues#labels)."
|
||||
Runs your workflow when a label in your workflow's repository is created or modified. For more information about labels, see "[AUTOTITLE](/issues/using-labels-and-milestones-to-track-work/managing-labels)." For information about the label APIs, see "[AUTOTITLE](/graphql/reference/objects#label)" in the GraphQL API documentation or "[AUTOTITLE](/rest/issues/labels)."
|
||||
|
||||
If you want to run your workflow when a label is added to or removed from an issue, pull request, or discussion, use the `labeled` or `unlabeled` activity types for the [`issues`](#issues), [`pull_request`](#pull_request), [`pull_request_target`](#pull_request_target), or [`discussion`](#discussion) events instead.
|
||||
|
||||
|
@ -421,7 +421,7 @@ on:
|
|||
|
||||
{% data reusables.actions.branch-requirement %}
|
||||
|
||||
Runs your workflow when a milestone in the workflow's repository is created or modified. For more information about milestones, see "[AUTOTITLE](/issues/using-labels-and-milestones-to-track-work/about-milestones)." For information about the milestone APIs, see "[AUTOTITLE](/graphql/reference/objects#milestone)" in the GraphQL API documentation or "[AUTOTITLE](/rest/issues#milestones)."
|
||||
Runs your workflow when a milestone in the workflow's repository is created or modified. For more information about milestones, see "[AUTOTITLE](/issues/using-labels-and-milestones-to-track-work/about-milestones)." For information about the milestone APIs, see "[AUTOTITLE](/graphql/reference/objects#milestone)" in the GraphQL API documentation or "[AUTOTITLE](/rest/issues/milestones)."
|
||||
|
||||
If you want to run your workflow when an issue is added to or removed from a milestone, use the `milestoned` or `demilestoned` activity types for the [`issues`](#issues) event instead.
|
||||
|
||||
|
@ -516,7 +516,7 @@ on:
|
|||
{% endnote %}
|
||||
{% endif %}
|
||||
|
||||
Runs your workflow when a card on a {% data variables.projects.projects_v1_board %} is created or modified. For activity related to {% data variables.projects.projects_v1_boards %} or columns in a {% data variables.projects.projects_v1_board %}, use the [`project`](#project) or [`project_column`](#project_column) event instead. For more information about {% data variables.projects.projects_v1_boards %}, see "[AUTOTITLE](/issues/organizing-your-work-with-project-boards/managing-project-boards/about-project-boards)." For information about the project card APIs, see "[AUTOTITLE](/graphql/reference/objects#projectcard)" in the GraphQL API documentation or "[AUTOTITLE](/rest/projects#cards)."
|
||||
Runs your workflow when a card on a {% data variables.projects.projects_v1_board %} is created or modified. For activity related to {% data variables.projects.projects_v1_boards %} or columns in a {% data variables.projects.projects_v1_board %}, use the [`project`](#project) or [`project_column`](#project_column) event instead. For more information about {% data variables.projects.projects_v1_boards %}, see "[AUTOTITLE](/issues/organizing-your-work-with-project-boards/managing-project-boards/about-project-boards)." For information about the project card APIs, see "[AUTOTITLE](/graphql/reference/objects#projectcard)" in the GraphQL API documentation or "[AUTOTITLE](/rest/projects/cards)."
|
||||
|
||||
For example, you can run a workflow when a project card has been `created` or `deleted`.
|
||||
|
||||
|
@ -1108,7 +1108,7 @@ on:
|
|||
|
||||
{% data reusables.actions.branch-requirement %}
|
||||
|
||||
You can use the {% data variables.product.product_name %} API to trigger a webhook event called [`repository_dispatch`](/webhooks-and-events/webhooks/webhook-events-and-payloads#repository_dispatch) when you want to trigger a workflow for activity that happens outside of {% data variables.product.product_name %}. For more information, see "[AUTOTITLE](/rest/repos#create-a-repository-dispatch-event)."
|
||||
You can use the {% data variables.product.product_name %} API to trigger a webhook event called [`repository_dispatch`](/webhooks-and-events/webhooks/webhook-events-and-payloads#repository_dispatch) when you want to trigger a workflow for activity that happens outside of {% data variables.product.product_name %}. For more information, see "[AUTOTITLE](/rest/repos/repos#create-a-repository-dispatch-event)."
|
||||
|
||||
When you make a request to create a `repository_dispatch` event, you must specify an `event_type` to describe the activity type. By default, all `repository_dispatch` activity types trigger a workflow to run. You can use the `types` keyword to limit your workflow to run when a specific `event_type` value is sent in the `repository_dispatch` webhook payload.
|
||||
|
||||
|
@ -1263,7 +1263,7 @@ jobs:
|
|||
|
||||
{% data reusables.actions.branch-requirement %}
|
||||
|
||||
Runs your workflow when the workflow's repository is starred. For information about the pull request APIs, see "[AUTOTITLE](/graphql/reference/mutations#addstar)" in the GraphQL API documentation or "[AUTOTITLE](/rest/activity#starring)."
|
||||
Runs your workflow when the workflow's repository is starred. For information about the pull request APIs, see "[AUTOTITLE](/graphql/reference/mutations#addstar)" in the GraphQL API documentation or "[AUTOTITLE](/rest/activity/starring)."
|
||||
|
||||
For example, you can run a workflow when someone stars a repository, which is the `started` activity type for a watch event.
|
||||
|
||||
|
|
|
@ -93,4 +93,4 @@ When using the REST API, you configure the `inputs` and `ref` as request body pa
|
|||
|
||||
{% endnote %}
|
||||
|
||||
For more information about using the REST API, see "[AUTOTITLE](/rest/actions#create-a-workflow-dispatch-event)."
|
||||
For more information about using the REST API, see "[AUTOTITLE](/rest/actions/workflows#create-a-workflow-dispatch-event)."
|
||||
|
|
|
@ -139,7 +139,7 @@ The `retention-days` value cannot exceed the retention limit set by the reposito
|
|||
|
||||
During a workflow run, you can use the [`download-artifact`](https://github.com/actions/download-artifact) action to download artifacts that were previously uploaded in the same workflow run.
|
||||
|
||||
After a workflow run has been completed, you can download or delete artifacts on {% data variables.product.prodname_dotcom %} or using the REST API. For more information, see "[AUTOTITLE](/actions/managing-workflow-runs/downloading-workflow-artifacts)," "[AUTOTITLE](/actions/managing-workflow-runs/removing-workflow-artifacts)," and "[AUTOTITLE](/rest/actions#artifacts)."
|
||||
After a workflow run has been completed, you can download or delete artifacts on {% data variables.product.prodname_dotcom %} or using the REST API. For more information, see "[AUTOTITLE](/actions/managing-workflow-runs/downloading-workflow-artifacts)," "[AUTOTITLE](/actions/managing-workflow-runs/removing-workflow-artifacts)," and "[AUTOTITLE](/rest/actions/artifacts)."
|
||||
|
||||
### Downloading artifacts during a workflow run
|
||||
|
||||
|
|
|
@ -140,7 +140,7 @@ $ ghe-config app.github.rate-limiting-exempt-users "hubot github-actions[bot]"
|
|||
|
||||
### ghe-config-apply
|
||||
|
||||
This utility applies {% data variables.enterprise.management_console %} settings, reloads system services, prepares a storage device, reloads application services, and runs any pending database migrations. It is equivalent to clicking **Save settings** in the {% data variables.enterprise.management_console %}'s web UI or to sending a POST request to [the `/setup/api/configure` endpoint](/rest/enterprise-admin#management-console).
|
||||
This utility applies {% data variables.enterprise.management_console %} settings, reloads system services, prepares a storage device, reloads application services, and runs any pending database migrations. It is equivalent to clicking **Save settings** in the {% data variables.enterprise.management_console %}'s web UI or to sending a POST request to [the `/setup/api/configure` endpoint](/rest/enterprise-admin/management-console).
|
||||
|
||||
You will probably never need to run this manually, but it's available if you want to automate the process of saving your settings via SSH.
|
||||
|
||||
|
|
|
@ -20,7 +20,7 @@ shortTitle: Change authentication methods
|
|||
---
|
||||
User accounts on {% data variables.location.product_location %} are preserved when you change the authentication method and users will continue to log into the same account as long as their username doesn't change.
|
||||
|
||||
If the new method of authentication changes usernames, new accounts will be created. As an administrator, you can rename users through the site admin settings or by using [the User Administration API](/rest/enterprise-admin#update-the-username-for-a-user).
|
||||
If the new method of authentication changes usernames, new accounts will be created. As an administrator, you can rename users through the site admin settings or by using [the User Administration API](/rest/enterprise-admin/users#update-the-username-for-a-user).
|
||||
|
||||
Other issues you should take into consideration include:
|
||||
|
||||
|
|
|
@ -220,7 +220,7 @@ Unless [LDAP Sync is enabled](#enabling-ldap-sync), changes to LDAP accounts are
|
|||
{% data reusables.enterprise_site_admin_settings.admin-top-tab %}
|
||||
1. Under "LDAP," click **Sync now** to manually update the account with data from your LDAP server.
|
||||
|
||||
You can also [use the API to trigger a manual sync](/rest/enterprise-admin#ldap).
|
||||
You can also [use the API to trigger a manual sync](/rest/enterprise-admin/ldap).
|
||||
|
||||
## Revoking access to {% data variables.location.product_location %}
|
||||
|
||||
|
|
|
@ -104,4 +104,4 @@ You can create a custom message that suspended users will see when attempting to
|
|||
|
||||
## Further reading
|
||||
|
||||
- "[AUTOTITLE](/rest/enterprise-admin#suspend-a-user)"
|
||||
- "[AUTOTITLE](/rest/enterprise-admin/users#suspend-a-user)"
|
||||
|
|
|
@ -14,7 +14,7 @@ topics:
|
|||
|
||||
{% data variables.product.prodname_server_statistics %} can help you anticipate the needs of your organization, understand how your team works, and show the value you get from {% data variables.product.prodname_ghe_server %}.
|
||||
|
||||
Once enabled, {% data variables.product.prodname_server_statistics %} collects aggregate data on how much certain features are used on your instance over time. Unlike other [Admin Stats API](/rest/enterprise-admin#admin-stats) endpoints, which only return data for the last day, {% data variables.product.prodname_server_statistics %} provides historical data of all {% data variables.product.prodname_server_statistics %} metrics collected since the day you enabled the feature. For more information, see "[AUTOTITLE](/admin/configuration/configuring-github-connect/enabling-server-statistics-for-your-enterprise)."
|
||||
Once enabled, {% data variables.product.prodname_server_statistics %} collects aggregate data on how much certain features are used on your instance over time. Unlike other [Admin Stats API](/rest/enterprise-admin/admin-stats) endpoints, which only return data for the last day, {% data variables.product.prodname_server_statistics %} provides historical data of all {% data variables.product.prodname_server_statistics %} metrics collected since the day you enabled the feature. For more information, see "[AUTOTITLE](/admin/configuration/configuring-github-connect/enabling-server-statistics-for-your-enterprise)."
|
||||
|
||||
When you enable {% data variables.product.prodname_server_statistics %}, you're helping to build a better {% data variables.product.prodname_dotcom %}. The aggregated data you'll provide gives us insights into how {% data variables.product.prodname_dotcom %} adds value to our customers. This information allows {% data variables.product.company_short %} to make better and more informed product decisions, ultimately benefiting you.
|
||||
|
||||
|
|
|
@ -36,7 +36,7 @@ Timestamps and date fields in the API response are measured in [UTC epoch millis
|
|||
|
||||
{% ifversion ghec %}Each audit log API endpoint has a rate limit of 1,750 queries per hour for a given combination of user and IP address. To avoid rate limiting, integrations that query the audit log API should query at a maximum frequency of 1,750 queries per hour. Additionally, if your integration receives a rate limit error (typically a 403 or 429 response), it should wait before making another request to the API. For more information, see "[AUTOTITLE](/rest/overview/rate-limits-for-the-rest-api)" and "[AUTOTITLE](/rest/guides/best-practices-for-integrators)."{% endif %}
|
||||
|
||||
For more information about the audit log REST API, see "[AUTOTITLE](/rest/enterprise-admin#audit-log)" and "[AUTOTITLE](/rest/orgs#get-the-audit-log-for-an-organization)."
|
||||
For more information about the audit log REST API, see "[AUTOTITLE](/rest/enterprise-admin/audit-log)" and "[AUTOTITLE](/rest/orgs#get-the-audit-log-for-an-organization)."
|
||||
|
||||
## Example 1: All events in an enterprise, for a specific date, with pagination
|
||||
|
||||
|
|
|
@ -18,9 +18,9 @@ shortTitle: GitHub Enterprise API
|
|||
With the APIs, you can automate many administrative tasks. Some examples include:
|
||||
|
||||
{% ifversion ghes %}
|
||||
- Perform changes to the {% data variables.enterprise.management_console %}. For more information, see "[AUTOTITLE](/rest/enterprise-admin#management-console)."
|
||||
- Configure LDAP sync. For more information, see "[AUTOTITLE](/rest/enterprise-admin#ldap)."{% endif %}
|
||||
- Collect statistics about your enterprise. For more information, see "[AUTOTITLE](/rest/enterprise-admin#admin-stats)."
|
||||
- Perform changes to the {% data variables.enterprise.management_console %}. For more information, see "[AUTOTITLE](/rest/enterprise-admin/management-console)."
|
||||
- Configure LDAP sync. For more information, see "[AUTOTITLE](/rest/enterprise-admin/ldap)."{% endif %}
|
||||
- Collect statistics about your enterprise. For more information, see "[AUTOTITLE](/rest/enterprise-admin/admin-stats)."
|
||||
- Manage your enterprise account. For more information, see "[AUTOTITLE](/graphql/guides/managing-enterprise-accounts)."
|
||||
|
||||
For the complete documentation for the {% data variables.product.prodname_enterprise_api %}, see [{% data variables.product.prodname_dotcom %} REST API](/rest) and [{% data variables.product.prodname_dotcom%} GraphQL API](/graphql).
|
||||
|
|
|
@ -88,22 +88,22 @@ The `$GITHUB_VIA` variable is available in the pre-receive hook environment when
|
|||
| <pre>blob#save</pre> | Change to a file's contents in the web interface | "[AUTOTITLE](/repositories/working-with-files/managing-files/editing-files)" |
|
||||
| <pre>branch merge api</pre> | Merge of a branch via the API | "[AUTOTITLE](/rest/branches#merge-a-branch)" |
|
||||
| <pre>branches page delete button</pre> | Deletion of a branch in the web interface | "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository#deleting-a-branch)" |
|
||||
| <pre>git refs create api</pre> | Creation of a ref via the API | "[AUTOTITLE](/rest/git#create-a-reference)" |
|
||||
| <pre>git refs delete api</pre> | Deletion of a ref via the API | "[AUTOTITLE](/rest/git#delete-a-reference)" |
|
||||
| <pre>git refs update api</pre> | Update of a ref via the API | "[AUTOTITLE](/rest/git#update-a-reference)" |
|
||||
| <pre>git repo contents api</pre> | Change to a file's contents via the API | "[AUTOTITLE](/rest/repos#create-or-update-file-contents)" |
|
||||
| <pre>git refs create api</pre> | Creation of a ref via the API | "[AUTOTITLE](/rest/git/refs#create-a-reference)" |
|
||||
| <pre>git refs delete api</pre> | Deletion of a ref via the API | "[AUTOTITLE](/rest/git/refs#delete-a-reference)" |
|
||||
| <pre>git refs update api</pre> | Update of a ref via the API | "[AUTOTITLE](/rest/git/refs#update-a-reference)" |
|
||||
| <pre>git repo contents api</pre> | Change to a file's contents via the API | "[AUTOTITLE](/rest/repos/contents#create-or-update-file-contents)" |
|
||||
{%- ifversion ghes %}
|
||||
| `merge` | Merge of a pull request using auto-merge | "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request)" |
|
||||
{%- endif %}
|
||||
| <pre>merge base into head</pre> | Update of the topic branch from the base branch when the base branch requires strict status checks (via **Update branch** in a pull request, for example) | "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging)" |
|
||||
| <pre>pull request branch delete button</pre> | Deletion of a topic branch from a pull request in the web interface | "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/deleting-and-restoring-branches-in-a-pull-request#deleting-a-branch-used-for-a-pull-request)" |
|
||||
| <pre>pull request branch undo button</pre> | Restoration of a topic branch from a pull request in the web interface | "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/deleting-and-restoring-branches-in-a-pull-request#restoring-a-deleted-branch)" |
|
||||
| <pre>pull request merge api</pre> | Merge of a pull request via the API | "[AUTOTITLE](/rest/pulls#merge-a-pull-request)" |
|
||||
| <pre>pull request merge api</pre> | Merge of a pull request via the API | "[AUTOTITLE](/rest/pulls/pulls#merge-a-pull-request)" |
|
||||
| <pre>pull request merge button</pre> | Merge of a pull request in the web interface | "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request#merging-a-pull-request-on-github)" |
|
||||
| <pre>pull request revert button</pre> | Revert of a pull request | "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/reverting-a-pull-request)" |
|
||||
| <pre>releases delete button</pre> | Deletion of a release | "[AUTOTITLE](/repositories/releasing-projects-on-github/managing-releases-in-a-repository#deleting-a-release)" |
|
||||
| <pre>stafftools branch restore</pre> | Restoration of a branch from the site admin dashboard | "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/site-admin-dashboard#repositories)" |
|
||||
| <pre>tag create api</pre> | Creation of a tag via the API | "[AUTOTITLE](/rest/git#create-a-tag-object)" |
|
||||
| <pre>tag create api</pre> | Creation of a tag via the API | "[AUTOTITLE](/rest/git/tags#create-a-tag-object)" |
|
||||
{%- ifversion ghes < 3.13 %}
|
||||
| <pre>slumlord (#SHA)</pre> | Commit via Subversion | "[AUTOTITLE](/get-started/working-with-subversion-on-github/support-for-subversion-clients#making-commits-to-subversion)" |
|
||||
{%- endif %}
|
||||
|
|
|
@ -92,7 +92,7 @@ To help your users install your {% data variables.product.prodname_github_app %}
|
|||
To pre-select any repositories your {% data variables.product.prodname_oauth_app %} had access to, you can append `/permissions` and query parameters to the install URL. This helps users grant your {% data variables.product.prodname_github_app %} access to repositories that your {% data variables.product.prodname_oauth_app %} already has access to. The query parameters are:
|
||||
|
||||
- `suggested_target_id`: The ID of the user or organization that is installing your {% data variables.product.prodname_github_app %}. This parameter is required.
|
||||
- `repository_ids[]`: The repository IDs to select for the installation. If omitted, all repositories are selected. The maximum number of repositories that can be pre-selected is 100. To get a list of repositories that your {% data variables.product.prodname_oauth_app %} has access to, use the [List repositories for the authenticated user](/rest/repos#list-repositories-for-the-authenticated-user) and [List organization repositories](/rest/repos#list-organization-repositories) endpoints.
|
||||
- `repository_ids[]`: The repository IDs to select for the installation. If omitted, all repositories are selected. The maximum number of repositories that can be pre-selected is 100. To get a list of repositories that your {% data variables.product.prodname_oauth_app %} has access to, use the [List repositories for the authenticated user](/rest/repos/repos#list-repositories-for-the-authenticated-user) and [List organization repositories](/rest/repos/repos#list-organization-repositories) endpoints.
|
||||
|
||||
For example: `{% data variables.product.oauth_host_code %}/{% ifversion ghes %}github-apps{% else %}apps{% endif %}/YOUR_APP_NAME/installations/new/permissions?suggested_target_id=ID_OF_USER_OR_ORG&repository_ids[]=REPO_A_ID&repository_ids[]=REPO_B_ID`.
|
||||
|
||||
|
|
|
@ -661,7 +661,7 @@ In the code block that starts with `helpers do`, where it says `# ADD CREATE_CHE
|
|||
end
|
||||
```
|
||||
|
||||
This code calls the `POST /repos/{owner}/{repo}/check-runs` endpoint using the Octokit [create_check_run method](https://msp-greg.github.io/octokit/Octokit/Client/Checks.html#create_check_run-instance_method). For more information about the endpoint, see "[AUTOTITLE](/rest/checks#create-a-check-run)."
|
||||
This code calls the `POST /repos/{owner}/{repo}/check-runs` endpoint using the Octokit [create_check_run method](https://msp-greg.github.io/octokit/Octokit/Client/Checks.html#create_check_run-instance_method). For more information about the endpoint, see "[AUTOTITLE](/rest/checks/runs#create-a-check-run)."
|
||||
|
||||
To create a check run, only two input parameters are required: `name` and `head_sha`. In this code, we name the check run "Octo RuboCop," because we'll use RuboCop to implement the CI test later in the tutorial. But you can choose any name you'd like for the check run. For more information about RuboCop, see the [RuboCop documentation](https://docs.rubocop.org/rubocop/index.html).
|
||||
|
||||
|
@ -748,7 +748,7 @@ In the code block that starts with `helpers do`, where it says `# ADD INITIATE_C
|
|||
end
|
||||
```
|
||||
|
||||
The code above calls the `PATCH /repos/{owner}/{repo}/check-runs/{check_run_id}` endpoint using the [`update_check_run` Octokit method](https://msp-greg.github.io/octokit/Octokit/Client/Checks.html#update_check_run-instance_method), and updates the check run that you already created. For more information about the endpoint, see "[AUTOTITLE](/rest/checks#update-a-check-run)."
|
||||
The code above calls the `PATCH /repos/{owner}/{repo}/check-runs/{check_run_id}` endpoint using the [`update_check_run` Octokit method](https://msp-greg.github.io/octokit/Octokit/Client/Checks.html#update_check_run-instance_method), and updates the check run that you already created. For more information about the endpoint, see "[AUTOTITLE](/rest/checks/runs#update-a-check-run)."
|
||||
|
||||
Here's what this code is doing. First, it updates the check run's status to `in_progress` and implicitly sets the `started_at` time to the current time. In Part 2 of this tutorial, you'll add code that kicks off a real CI test under `***** RUN A CI TEST *****`. For now, you'll leave that section as a placeholder, so the code that follows it will just simulate that the CI process succeeds and all tests pass. Finally, the code updates the status of the check run again to `completed`.
|
||||
|
||||
|
@ -904,7 +904,7 @@ The code above gets the full repository name and the head SHA of the commit from
|
|||
|
||||
## Step 2.3. Run RuboCop
|
||||
|
||||
So far, your code clones the repository and creates check runs using your CI server. Now you'll get into the details of the [RuboCop linter](https://docs.rubocop.org/rubocop/usage/basic_usage.html#code-style-checker) and [checks annotations](/rest/checks#create-a-check-run).
|
||||
So far, your code clones the repository and creates check runs using your CI server. Now you'll get into the details of the [RuboCop linter](https://docs.rubocop.org/rubocop/usage/basic_usage.html#code-style-checker) and [checks annotations](/rest/checks/runs#create-a-check-run).
|
||||
|
||||
First, you'll add code to run RuboCop and save the style code errors in JSON format.
|
||||
|
||||
|
|
|
@ -31,7 +31,7 @@ Customers should be able to perform the following actions from your app's websit
|
|||
|
||||
Follow these guidelines for upgrades, downgrades, and cancellations to maintain a clear and consistent billing process. For more detailed instructions about the {% data variables.product.prodname_marketplace %} purchase events, see "[AUTOTITLE](/apps/github-marketplace/using-the-github-marketplace-api-in-your-app)."
|
||||
|
||||
You can use the `marketplace_purchase` webhook's `effective_date` key to determine when a plan change will occur and periodically synchronize the [List accounts for a plan](/rest/apps#list-accounts-for-a-plan).
|
||||
You can use the `marketplace_purchase` webhook's `effective_date` key to determine when a plan change will occur and periodically synchronize the [List accounts for a plan](/rest/apps/marketplace#list-accounts-for-a-plan).
|
||||
|
||||
### Upgrades
|
||||
|
||||
|
|
|
@ -83,6 +83,6 @@ If the purchase is for an organization and per-user, you can prompt the customer
|
|||
|
||||
You can customize the way that organization members receive access to your app. Here are a few suggestions:
|
||||
|
||||
**Flat-rate pricing:** If the purchase is made for an organization using flat-rate pricing, your app can [get all the organization’s members](/rest/orgs#list-organization-members) via the API and prompt the organization owner to choose which members will have paid users on the integrator side.
|
||||
**Flat-rate pricing:** If the purchase is made for an organization using flat-rate pricing, your app can [get all the organization’s members](/rest/orgs/members#list-organization-members) via the API and prompt the organization owner to choose which members will have paid users on the integrator side.
|
||||
|
||||
**Per-unit pricing:** One method of provisioning per-unit seats is to allow users to occupy a seat as they log in to the app. Once the customer hits the seat count threshold, your app can alert the user that they need to upgrade through {% data variables.product.prodname_marketplace %}.
|
||||
|
|
|
@ -35,6 +35,6 @@ When a customer cancels a free or paid plan, your app must perform these steps t
|
|||
|
||||
{% note %}
|
||||
|
||||
**Note:** We recommend using the [`marketplace_purchase`](/apps/github-marketplace/using-the-github-marketplace-api-in-your-app/webhook-events-for-the-github-marketplace-api) webhook's `effective_date` to determine when a plan change will occur and periodically synchronizing the [List accounts for a plan](/rest/apps#list-accounts-for-a-plan). For more information on webhooks, see "[AUTOTITLE](/apps/github-marketplace/using-the-github-marketplace-api-in-your-app/webhook-events-for-the-github-marketplace-api)."
|
||||
**Note:** We recommend using the [`marketplace_purchase`](/apps/github-marketplace/using-the-github-marketplace-api-in-your-app/webhook-events-for-the-github-marketplace-api) webhook's `effective_date` to determine when a plan change will occur and periodically synchronizing the [List accounts for a plan](/rest/apps/marketplace#list-accounts-for-a-plan). For more information on webhooks, see "[AUTOTITLE](/apps/github-marketplace/using-the-github-marketplace-api-in-your-app/webhook-events-for-the-github-marketplace-api)."
|
||||
|
||||
{% endnote %}
|
||||
|
|
|
@ -20,10 +20,10 @@ shortTitle: REST API
|
|||
|
||||
Here are some useful endpoints available for Marketplace listings:
|
||||
|
||||
- [List plans](/rest/apps#list-plans)
|
||||
- [List accounts for a plan](/rest/apps#list-accounts-for-a-plan)
|
||||
- [Get a subscription plan for an account](/rest/apps#get-a-subscription-plan-for-an-account)
|
||||
- [List subscriptions for the authenticated user](/rest/apps#list-subscriptions-for-the-authenticated-user)
|
||||
- [List plans](/rest/apps/marketplace#list-plans)
|
||||
- [List accounts for a plan](/rest/apps/marketplace#list-accounts-for-a-plan)
|
||||
- [Get a subscription plan for an account](/rest/apps/marketplace#get-a-subscription-plan-for-an-account)
|
||||
- [List subscriptions for the authenticated user](/rest/apps/marketplace#list-subscriptions-for-the-authenticated-user)
|
||||
|
||||
See these pages for details on how to authenticate when using the {% data variables.product.prodname_marketplace %} API:
|
||||
|
||||
|
|
|
@ -41,7 +41,7 @@ The `marketplace_purchase` object has the following keys:
|
|||
|
||||
Key | Type | Description
|
||||
----|------|-------------
|
||||
`account` | `object` | The `organization` or `user` account associated with the subscription. Organization accounts will include `organization_billing_email`, which is the organization's administrative email address. To find email addresses for personal accounts, you can use the [Get the authenticated user](/rest/users#get-the-authenticated-user) endpoint.
|
||||
`account` | `object` | The `organization` or `user` account associated with the subscription. Organization accounts will include `organization_billing_email`, which is the organization's administrative email address. To find email addresses for personal accounts, you can use the [Get the authenticated user](/rest/users/users#get-the-authenticated-user) endpoint.
|
||||
`billing_cycle` | `string` | Can be `yearly` or `monthly`. When the `account` owner has a free GitHub plan and has purchased a free {% data variables.product.prodname_marketplace %} plan, `billing_cycle` will be `nil`.
|
||||
`unit_count` | `integer` | Number of units purchased.
|
||||
`on_free_trial` | `boolean` | `true` when the `account` is on a free trial.
|
||||
|
|
|
@ -171,7 +171,7 @@ To help you gracefully handle these situations, all API responses for requests
|
|||
made with valid OAuth app tokens also contain an [`X-OAuth-Scopes` header](/apps/oauth-apps/building-oauth-apps/scopes-for-oauth-apps).
|
||||
This header contains the list of scopes of the token that was used to make the
|
||||
request. In addition to that, the REST API provides an endpoint to
|
||||
[check a token for validity](/rest/apps#check-a-token).
|
||||
[check a token for validity](/rest/apps/oauth-applications#check-a-token).
|
||||
Use this information to detect changes in token scopes, and inform your users of
|
||||
changes in available application functionality.
|
||||
|
||||
|
|
|
@ -168,7 +168,7 @@ If you provided a `state` parameter, you will also see that parameter in the `re
|
|||
|
||||
### 3. You exchange the temporary code to retrieve the app configuration
|
||||
|
||||
To complete the handshake, send the temporary `code` in a `POST` request to the [Create a GitHub App from a manifest](/rest/apps#create-a-github-app-from-a-manifest) endpoint. The response will include the `id` (GitHub App ID), `pem` (private key), and `webhook_secret`. GitHub creates a webhook secret for the app automatically. You can store these values in environment variables on the app's server. For example, if your app uses [dotenv](https://github.com/bkeepers/dotenv) to store environment variables, you would store the variables in your app's `.env` file.
|
||||
To complete the handshake, send the temporary `code` in a `POST` request to the [Create a GitHub App from a manifest](/rest/apps/apps#create-a-github-app-from-a-manifest) endpoint. The response will include the `id` (GitHub App ID), `pem` (private key), and `webhook_secret`. GitHub creates a webhook secret for the app automatically. You can store these values in environment variables on the app's server. For example, if your app uses [dotenv](https://github.com/bkeepers/dotenv) to store environment variables, you would store the variables in your app's `.env` file.
|
||||
|
||||
You must complete this step of the GitHub App Manifest flow within one hour.
|
||||
|
||||
|
@ -180,7 +180,7 @@ You must complete this step of the GitHub App Manifest flow within one hour.
|
|||
|
||||
POST /app-manifests/{code}/conversions
|
||||
|
||||
For more information about the endpoint's response, see [Create a GitHub App from a manifest](/rest/apps#create-a-github-app-from-a-manifest).
|
||||
For more information about the endpoint's response, see [Create a GitHub App from a manifest](/rest/apps/apps#create-a-github-app-from-a-manifest).
|
||||
|
||||
When the final step in the manifest flow is completed, the person registering the app from the flow will be an owner of a registered GitHub App that they can install on any of their personal repositories. They can choose to extend the app using the GitHub APIs, transfer ownership to someone else, or delete it at any time.
|
||||
|
||||
|
|
|
@ -51,7 +51,7 @@ If you don't want to use SSH keys, you can use HTTPS with OAuth tokens.
|
|||
- Multiple tokens (one for each user) are not needed; one token per server is enough.
|
||||
- A token can be revoked at any time, turning it essentially into a one-use password.
|
||||
{% ifversion ghes %}
|
||||
- Generating new tokens can be easily scripted using [the OAuth API](/rest/oauth-authorizations#create-a-new-authorization).
|
||||
- Generating new tokens can be easily scripted using [the OAuth API](/rest/oauth-authorizations/oauth-authorizations#create-a-new-authorization).
|
||||
{% endif %}
|
||||
|
||||
### Cons of HTTPS cloning with OAuth tokens
|
||||
|
@ -147,7 +147,7 @@ Since {% data variables.product.prodname_github_apps %} are a first class actor
|
|||
1. Note your {% data variables.product.prodname_github_app %} `id`.
|
||||
1. Generate and download your {% data variables.product.prodname_github_app %}'s private key, and store this safely. For more information, see [Generating a private key](/apps/creating-github-apps/authenticating-with-a-github-app/managing-private-keys-for-github-apps).
|
||||
1. Install your {% data variables.product.prodname_github_app %} on the repositories it needs to act upon, optionally you may install the {% data variables.product.prodname_github_app %} on all repositories in your organization.
|
||||
1. Identify the `installation_id` that represents the connection between your {% data variables.product.prodname_github_app %} and the organization repositories it can access. Each {% data variables.product.prodname_github_app %} and organization pair have at most a single `installation_id`. You can identify this `installation_id` via [Get an organization installation for the authenticated app](/rest/apps#get-an-organization-installation-for-the-authenticated-app). This requires authenticating as a {% data variables.product.prodname_github_app %} using a JWT, for more information see [Authenticating as a {% data variables.product.prodname_github_app %}](/apps/creating-github-apps/authenticating-with-a-github-app/authenticating-as-a-github-app).
|
||||
1. Identify the `installation_id` that represents the connection between your {% data variables.product.prodname_github_app %} and the organization repositories it can access. Each {% data variables.product.prodname_github_app %} and organization pair have at most a single `installation_id`. You can identify this `installation_id` via [Get an organization installation for the authenticated app](/rest/apps/apps#get-an-organization-installation-for-the-authenticated-app). This requires authenticating as a {% data variables.product.prodname_github_app %} using a JWT, for more information see [Authenticating as a {% data variables.product.prodname_github_app %}](/apps/creating-github-apps/authenticating-with-a-github-app/authenticating-as-a-github-app).
|
||||
1. Generate an installation access token using the corresponding REST API endpoint, [Create an installation access token for an app](/rest/apps#create-an-installation-access-token-for-an-app). This requires authenticating as a {% data variables.product.prodname_github_app %} using a JWT, for more information see [Authenticating as a {% data variables.product.prodname_github_app %}](/apps/creating-github-apps/authenticating-with-a-github-app/authenticating-as-a-github-app), and [Authenticating as an installation](/apps/creating-github-apps/authenticating-with-a-github-app/authenticating-as-a-github-app-installation).
|
||||
1. Use this installation access token to interact with your repositories, either via the REST or GraphQL APIs, or via a Git client.
|
||||
|
||||
|
|
|
@ -23,4 +23,4 @@ You can add the following ssh key entries to your `~/.ssh/known_hosts` file to a
|
|||
|
||||
{% data reusables.ssh.known_hosts %}
|
||||
|
||||
For more information, see "[AUTOTITLE](/rest/meta#get-github-meta-information)."
|
||||
For more information, see "[AUTOTITLE](/rest/meta/meta#get-github-meta-information)."
|
||||
|
|
|
@ -50,7 +50,7 @@ Once an authorization is revoked, any tokens associated with the authorization w
|
|||
|
||||
## Token revoked by the {% data variables.product.prodname_oauth_app %}
|
||||
|
||||
The owner of an {% data variables.product.prodname_oauth_app %} can revoke an account's authorization of their app, this will also revoke any tokens associated with the authorization. For more information about revoking authorizations of your {% data variables.product.prodname_oauth_app %}, see "[AUTOTITLE](/rest/apps#delete-an-app-authorization)."
|
||||
The owner of an {% data variables.product.prodname_oauth_app %} can revoke an account's authorization of their app, this will also revoke any tokens associated with the authorization. For more information about revoking authorizations of your {% data variables.product.prodname_oauth_app %}, see "[AUTOTITLE](/rest/apps/oauth-applications#delete-an-app-authorization)."
|
||||
|
||||
{% data variables.product.prodname_oauth_app %} owners can also revoke individual tokens associated with an authorization. For more information about revoking individual tokens for your {% data variables.product.prodname_oauth_app %}, see "[AUTOTITLE](/rest/apps/oauth-applications#delete-an-app-token)".
|
||||
|
||||
|
|
|
@ -137,7 +137,7 @@ You can retrieve {% data variables.product.prodname_advanced_security %} usage i
|
|||
|
||||
{% ifversion ghec %}
|
||||
|
||||
For organization-level data, use the `/orgs/{org}/settings/billing/advanced-security` endpoint. For more information, see "[AUTOTITLE](/rest/billing#get-github-advanced-security-active-committers-for-an-organization)."
|
||||
For organization-level data, use the `/orgs/{org}/settings/billing/advanced-security` endpoint. For more information, see "[AUTOTITLE](/rest/billing/billing#get-github-advanced-security-active-committers-for-an-organization)."
|
||||
|
||||
{% endif %}
|
||||
|
||||
|
|
|
@ -47,7 +47,7 @@ The filepath has to be consistent across the runs to enable a computation of a s
|
|||
|
||||
SARIF files created by the {% data variables.code-scanning.codeql_workflow %}, or using the {% data variables.product.prodname_codeql_cli %} include fingerprint data. If you upload a SARIF file using the `upload-sarif` action and this data is missing, {% data variables.product.prodname_dotcom %} attempts to populate the `partialFingerprints` field from the source files. For more information about uploading results, see "[AUTOTITLE](/code-security/code-scanning/integrating-with-code-scanning/uploading-a-sarif-file-to-github)."
|
||||
|
||||
If you upload a SARIF file without fingerprint data using the `/code-scanning/sarifs` API endpoint, the {% data variables.product.prodname_code_scanning %} alerts will be processed and displayed, but users may see duplicate alerts. To avoid seeing duplicate alerts, you should calculate fingerprint data and populate the `partialFingerprints` property before you upload the SARIF file. You may find the script that the `upload-sarif` action uses a helpful starting point: https://github.com/github/codeql-action/blob/main/src/fingerprints.ts. For more information about the API, see "[AUTOTITLE](/rest/code-scanning#upload-an-analysis-as-sarif-data)."
|
||||
If you upload a SARIF file without fingerprint data using the `/code-scanning/sarifs` API endpoint, the {% data variables.product.prodname_code_scanning %} alerts will be processed and displayed, but users may see duplicate alerts. To avoid seeing duplicate alerts, you should calculate fingerprint data and populate the `partialFingerprints` property before you upload the SARIF file. You may find the script that the `upload-sarif` action uses a helpful starting point: https://github.com/github/codeql-action/blob/main/src/fingerprints.ts. For more information about the API, see "[AUTOTITLE](/rest/code-scanning/code-scanning#upload-an-analysis-as-sarif-data)."
|
||||
|
||||
## Understanding rules and results
|
||||
|
||||
|
@ -72,7 +72,7 @@ This precision enhances the efficiency of code review and resolution processes,
|
|||
You can provide the source root for conversion from absolute to relative URIs in one of the following ways.
|
||||
|
||||
- [`checkout_path`](https://github.com/github/codeql-action/blob/c2c0a2908e95769d01b907f9930050ecb5cf050d/analyze/action.yml#L44-L47) input to the `github/codeql-action/analyze` action
|
||||
- `checkout_uri` parameter to the SARIF upload API endpoint. For more information, see "[AUTOTITLE](/rest/code-scanning#upload-an-analysis-as-sarif-data)."
|
||||
- `checkout_uri` parameter to the SARIF upload API endpoint. For more information, see "[AUTOTITLE](/rest/code-scanning/code-scanning#upload-an-analysis-as-sarif-data)."
|
||||
- [`invocation.workingDirectory.uri`](https://docs.oasis-open.org/sarif/sarif/v2.1.0/csprd01/sarif-v2.1.0-csprd01.html#_Toc9244365) property in the SARIF file
|
||||
|
||||
If you provide a source root, any location of an artifact specified using an absolute URI must use the same URI scheme. If there is a mismatch between the URI scheme for the source root and one or more of the absolute URIs, the upload is rejected.
|
||||
|
|
|
@ -38,7 +38,7 @@ You can upload the results using {% data variables.product.prodname_actions %},
|
|||
- {% data variables.product.prodname_actions %} to run the {% data variables.product.prodname_codeql %} action, there is no further action required. The {% data variables.product.prodname_codeql %} action uploads the SARIF file automatically when it completes analysis.
|
||||
- {% data variables.product.prodname_actions %} to run a SARIF-compatible analysis tool, you could update the workflow to include a final step that uploads the results (see below).
|
||||
- The {% data variables.product.prodname_codeql_cli %} to run {% data variables.product.prodname_code_scanning %} in your CI system, you can use the CLI to upload results to {% data variables.product.prodname_dotcom %} (for more information, see "[AUTOTITLE](/code-security/code-scanning/integrating-with-code-scanning/using-code-scanning-with-your-existing-ci-system)").
|
||||
- A tool that generates results as an artifact outside of your repository, you can use the {% data variables.product.prodname_code_scanning %} API to upload the file (for more information, see "[AUTOTITLE](/rest/code-scanning#upload-an-analysis-as-sarif-data)").
|
||||
- A tool that generates results as an artifact outside of your repository, you can use the {% data variables.product.prodname_code_scanning %} API to upload the file (for more information, see "[AUTOTITLE](/rest/code-scanning/code-scanning#upload-an-analysis-as-sarif-data)").
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
{% note %}
|
||||
|
@ -156,4 +156,4 @@ jobs:
|
|||
- "[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions)"
|
||||
- "[AUTOTITLE](/actions/monitoring-and-troubleshooting-workflows/viewing-workflow-run-history)"
|
||||
- "[AUTOTITLE](/code-security/code-scanning/integrating-with-code-scanning/using-code-scanning-with-your-existing-ci-system)"
|
||||
- "[AUTOTITLE](/rest/code-scanning#upload-an-analysis-as-sarif-data)"
|
||||
- "[AUTOTITLE](/rest/code-scanning/code-scanning#upload-an-analysis-as-sarif-data)"
|
||||
|
|
|
@ -82,7 +82,7 @@ shortTitle: Manage secret alerts
|
|||
{% else %}
|
||||
1. To dismiss an alert, select the "Mark as" dropdown menu and click a reason for resolving an alert.
|
||||
{% endif %}{% ifversion secret-scanning-dismissal-comment %}
|
||||
1. Optionally, in the "Comment" field, add a dismissal comment. The dismissal comment will be added to the alert timeline and can be used as justification during auditing and reporting. You can view the history of all dismissed alerts and dismissal comments in the alert timeline. You can also retrieve or set a comment by using the {% data variables.product.prodname_secret_scanning_caps %} API. The comment is contained in the `resolution_comment` field. For more information, see "[AUTOTITLE](/rest/secret-scanning#update-a-secret-scanning-alert)" in the REST API documentation.
|
||||
1. Optionally, in the "Comment" field, add a dismissal comment. The dismissal comment will be added to the alert timeline and can be used as justification during auditing and reporting. You can view the history of all dismissed alerts and dismissal comments in the alert timeline. You can also retrieve or set a comment by using the {% data variables.product.prodname_secret_scanning_caps %} API. The comment is contained in the `resolution_comment` field. For more information, see "[AUTOTITLE](/rest/secret-scanning/secret-scanning#update-a-secret-scanning-alert)" in the REST API documentation.
|
||||
1. Click **Close alert**.
|
||||
{% endif %}
|
||||
|
||||
|
|
|
@ -51,7 +51,7 @@ The action is available for all {% ifversion fpt or ghec %}public repositories,
|
|||
|
||||
{% data reusables.dependency-review.about-dependency-review-action %}
|
||||
|
||||
The action uses the dependency review REST API to get the diff of dependency changes between the base commit and head commit. You can use the dependency review API to get the diff of dependency changes, including vulnerability data, between any two commits on a repository. For more information, see "[AUTOTITLE](/rest/dependency-graph#dependency-review)."{% ifversion dependency-review-submission-api %} The action also considers dependencies submitted via the {% data variables.dependency-submission-api.name %}. For more information about the {% data variables.dependency-submission-api.name %}, see "[AUTOTITLE](/code-security/supply-chain-security/understanding-your-software-supply-chain/using-the-dependency-submission-api)."
|
||||
The action uses the dependency review REST API to get the diff of dependency changes between the base commit and head commit. You can use the dependency review API to get the diff of dependency changes, including vulnerability data, between any two commits on a repository. For more information, see "[AUTOTITLE](/rest/dependency-graph/dependency-review)."{% ifversion dependency-review-submission-api %} The action also considers dependencies submitted via the {% data variables.dependency-submission-api.name %}. For more information about the {% data variables.dependency-submission-api.name %}, see "[AUTOTITLE](/code-security/supply-chain-security/understanding-your-software-supply-chain/using-the-dependency-submission-api)."
|
||||
|
||||
{% data reusables.dependency-review.works-with-submission-api-beta %}
|
||||
|
||||
|
|
|
@ -169,4 +169,4 @@ For full details of the options for this command, see [the {% data variables.pro
|
|||
|
||||
- "[AUTOTITLE](/codespaces/developing-in-a-codespace/opening-an-existing-codespace)"
|
||||
- "[AUTOTITLE](/codespaces/setting-up-your-project-for-codespaces/setting-up-your-repository/facilitating-quick-creation-and-resumption-of-codespaces)"
|
||||
- "[AUTOTITLE](/rest/codespaces)"
|
||||
- "[AUTOTITLE](/rest/codespaces/organizations)"
|
||||
|
|
|
@ -169,4 +169,4 @@ For more information, see [`gh codespace code`](https://cli.github.com/manual/gh
|
|||
|
||||
## Further reading
|
||||
|
||||
- "[AUTOTITLE](/rest/codespaces)"
|
||||
- "[AUTOTITLE](/rest/codespaces/organizations)"
|
||||
|
|
|
@ -31,7 +31,7 @@ Let's walk through an example.
|
|||
|
||||
## 1. Call a REST endpoint that returns an object's node ID
|
||||
|
||||
If you [request the authenticated user](/rest/users#get-the-authenticated-user):
|
||||
If you [request the authenticated user](/rest/users/users#get-the-authenticated-user):
|
||||
|
||||
```shell
|
||||
curl -i --header "Authorization: Bearer YOUR-TOKEN" {% data variables.product.api_url_pre %}/user
|
||||
|
|
|
@ -285,7 +285,7 @@ curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" -X DELETE \
|
|||
|
||||
### Deleting repositories from an organization on {% data variables.product.prodname_dotcom_the_website %}
|
||||
|
||||
After unlocking the {% data variables.product.prodname_dotcom_the_website %} organization's repositories, you should delete every repository you previously migrated using [the repository delete endpoint](/rest/repos#delete-a-repository). You'll need your access token for authentication:
|
||||
After unlocking the {% data variables.product.prodname_dotcom_the_website %} organization's repositories, you should delete every repository you previously migrated using [the repository delete endpoint](/rest/repos/repos#delete-a-repository). You'll need your access token for authentication:
|
||||
|
||||
```shell
|
||||
curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" -X DELETE \
|
||||
|
|
|
@ -48,8 +48,8 @@ As an organization owner, you can also query the SCIM REST API or GraphQL to lis
|
|||
The SCIM REST API will only return data for users that have SCIM metadata populated under their external identities. We recommend you compare a list of SCIM provisioned identities with a list of all your organization members.
|
||||
|
||||
For more information, see:
|
||||
- "[AUTOTITLE](/rest/scim#list-scim-provisioned-identities)"
|
||||
- "[AUTOTITLE](/rest/orgs#list-organization-members)"
|
||||
- "[AUTOTITLE](/rest/scim/scim#list-scim-provisioned-identities)"
|
||||
- "[AUTOTITLE](/rest/orgs/members#list-organization-members)"
|
||||
|
||||
#### Using GraphQL
|
||||
|
||||
|
@ -92,7 +92,7 @@ For more information on using the GraphQL API, see:
|
|||
|
||||
You can re-provision SCIM for users manually through your IdP. For example, to resolve provisioning errors for Okta, in the Okta admin portal, you can unassign and reassign users to the {% data variables.product.prodname_dotcom %} app. This should trigger Okta to make an API call to populate the SCIM metadata for these users on {% data variables.product.prodname_dotcom %}. For more information, see "[Unassign users from applications](https://help.okta.com/en/prod/Content/Topics/users-groups-profiles/usgp-unassign-apps.htm)" or "[Assign users to applications](https://help.okta.com/en/prod/Content/Topics/users-groups-profiles/usgp-assign-apps.htm)" in the Okta documentation.
|
||||
|
||||
To confirm that a user's SCIM identity is created, we recommend testing this process with a single organization member whom you have confirmed doesn't have a SCIM external identity. After manually updating the users in your IdP, you can check if the user's SCIM identity was created using the SCIM API or on {% data variables.product.prodname_dotcom %}. For more information, see "[Auditing users for missing SCIM metadata](#auditing-users-for-missing-scim-metadata)" or "[AUTOTITLE](/rest/scim#get-scim-provisioning-information-for-a-user)."
|
||||
To confirm that a user's SCIM identity is created, we recommend testing this process with a single organization member whom you have confirmed doesn't have a SCIM external identity. After manually updating the users in your IdP, you can check if the user's SCIM identity was created using the SCIM API or on {% data variables.product.prodname_dotcom %}. For more information, see "[Auditing users for missing SCIM metadata](#auditing-users-for-missing-scim-metadata)" or "[AUTOTITLE](/rest/scim/scim#get-scim-provisioning-information-for-a-user)."
|
||||
|
||||
If re-provisioning SCIM for users doesn't help, please contact {% data variables.product.prodname_dotcom %} Support.
|
||||
|
||||
|
|
|
@ -40,7 +40,7 @@ Parent teams cannot synchronize with IdP groups. If the team you want to connect
|
|||
|
||||
To manage repository access for any {% data variables.product.prodname_dotcom %} team, including teams connected to an IdP group, you must make changes with {% data variables.product.product_name %}. For more information, see "[AUTOTITLE](/organizations/organizing-members-into-teams/about-teams)" and "[AUTOTITLE](/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/managing-team-access-to-an-organization-repository)."
|
||||
|
||||
{% ifversion ghec %}You can also manage team synchronization with the API. For more information, see "[AUTOTITLE](/rest/teams#team-sync)."{% endif %}
|
||||
{% ifversion ghec %}You can also manage team synchronization with the API. For more information, see "[AUTOTITLE](/rest/teams/team-sync)."{% endif %}
|
||||
|
||||
{% ifversion ghec %}
|
||||
|
||||
|
|
|
@ -55,7 +55,7 @@ You can navigate between the checks summaries for various commits in a pull requ
|
|||
|
||||
### Skipping and requesting checks for individual commits
|
||||
|
||||
When a repository is set to automatically request checks for pushes, you can choose to skip checks for an individual commit you push. When a repository is _not_ set to automatically request checks for pushes, you can request checks for an individual commit you push. For more information on these settings, see "[AUTOTITLE](/rest/checks#update-repository-preferences-for-check-suites)."
|
||||
When a repository is set to automatically request checks for pushes, you can choose to skip checks for an individual commit you push. When a repository is _not_ set to automatically request checks for pushes, you can request checks for an individual commit you push. For more information on these settings, see "[AUTOTITLE](/rest/checks/suites#update-repository-preferences-for-check-suites)."
|
||||
|
||||
You can also skip workflow runs triggered by the `push` and `pull_request` events by including a command in your commit message. For more information, see "[AUTOTITLE](/actions/managing-workflow-runs/skipping-workflow-runs)"
|
||||
|
||||
|
|
|
@ -47,7 +47,7 @@ remote: error: Required status check "ci-build" is failing
|
|||
|
||||
Sometimes, the results of the status checks for the test merge commit and head commit will conflict. If the test merge commit has a status, the test merge commit must pass. Otherwise, the status of the head commit must pass before you can merge the branch.
|
||||
|
||||
If there is a conflict between the test merge commit and head commit, the checks for the test merge commit are shown in the pull request status checks box. This is indicated in the pull request status box by a line starting with `Showing checks for the merge commit`. For more information about test merge commits, see "[AUTOTITLE](/rest/pulls#get-a-pull-request)."
|
||||
If there is a conflict between the test merge commit and head commit, the checks for the test merge commit are shown in the pull request status checks box. This is indicated in the pull request status box by a line starting with `Showing checks for the merge commit`. For more information about test merge commits, see "[AUTOTITLE](/rest/pulls/pulls#get-a-pull-request)."
|
||||
|
||||
## Handling skipped but required checks
|
||||
|
||||
|
|
|
@ -73,7 +73,7 @@ If you want to match two or more code owners with the same pattern, all the code
|
|||
CODEOWNERS paths are case sensitive, because {% data variables.product.prodname_dotcom %} uses a case sensitive file system. Since CODEOWNERS are evaluated by {% data variables.product.prodname_dotcom %}, even systems that are case insensitive (for example, macOS) must use paths and files that are cased correctly in the CODEOWNERS file.
|
||||
|
||||
{% ifversion codeowners-errors %}
|
||||
If any line in your CODEOWNERS file contains invalid syntax, that line will be skipped. When you navigate to the CODEOWNERS file in your repository on {% data variables.location.product_location %}, you can see any errors highlighted. A list of errors in a repository's CODEOWNERS file is also accessible via the API. For more information, see "[AUTOTITLE](/rest/repos#list-codeowners-errors)."
|
||||
If any line in your CODEOWNERS file contains invalid syntax, that line will be skipped. When you navigate to the CODEOWNERS file in your repository on {% data variables.location.product_location %}, you can see any errors highlighted. A list of errors in a repository's CODEOWNERS file is also accessible via the API. For more information, see "[AUTOTITLE](/rest/repos/repos#list-codeowners-errors)."
|
||||
{% else %}
|
||||
If any line in your CODEOWNERS file contains invalid syntax, the file will not be detected and will not be used to request reviews.
|
||||
{% endif %}
|
||||
|
|
|
@ -50,4 +50,4 @@ The following REST API versions are currently supported:
|
|||
{{ apiVersion }}
|
||||
{% endfor %}
|
||||
|
||||
You can also make an API request to get all of the supported API versions. For more information, see "[AUTOTITLE](/rest/meta#get-all-api-versions)."
|
||||
You can also make an API request to get all of the supported API versions. For more information, see "[AUTOTITLE](/rest/meta/meta#get-all-api-versions)."
|
||||
|
|
|
@ -18,7 +18,7 @@ autogenerated: rest
|
|||
|
||||
{% data variables.product.prodname_dotcom %} events power the various activity streams on the site.
|
||||
|
||||
You can use the REST API to return different types of events triggered by activity on {% data variables.product.product_name %}. For more information about the specific events that you can receive, see "[AUTOTITLE](/webhooks-and-events/events/github-event-types)." Endpoints for repository issues are also available. For more information, see "[AUTOTITLE](/rest/issues#events)."
|
||||
You can use the REST API to return different types of events triggered by activity on {% data variables.product.product_name %}. For more information about the specific events that you can receive, see "[AUTOTITLE](/webhooks-and-events/events/github-event-types)." Endpoints for repository issues are also available. For more information, see "[AUTOTITLE](/rest/issues/events)."
|
||||
|
||||
Events are optimized for polling with the "ETag" header. If no new events have been triggered, you will see a "304 Not Modified" response, and your current rate limit will be untouched. There is also an "X-Poll-Interval" header that specifies how often (in seconds) you are allowed to poll. In times of high server load, the time may increase. Please obey the header.
|
||||
|
||||
|
|
|
@ -20,6 +20,6 @@ autogenerated: rest
|
|||
|
||||
This page lists endpoints that you can access while authenticated as a {% data variables.product.prodname_github_app %}. For more information, see "[AUTOTITLE](/apps/creating-github-apps/authenticating-with-a-github-app/authenticating-as-a-github-app)".
|
||||
|
||||
See "[AUTOTITLE](/rest/apps#installations)" for a list of endpoints that require authentication as a {% data variables.product.prodname_github_app %} installation.
|
||||
See "[AUTOTITLE](/rest/apps/installations)" for a list of endpoints that require authentication as a {% data variables.product.prodname_github_app %} installation.
|
||||
|
||||
<!-- Content after this section is automatically generated -->
|
||||
|
|
|
@ -16,6 +16,6 @@ autogenerated: rest
|
|||
|
||||
## About billing
|
||||
|
||||
You can get billing information for an enterprise. For more information, see "[AUTOTITLE](/rest/enterprise-admin#billing)."
|
||||
You can get billing information for an enterprise. For more information, see "[AUTOTITLE](/rest/enterprise-admin/billing)."
|
||||
|
||||
<!-- Content after this section is automatically generated -->
|
||||
|
|
|
@ -14,7 +14,7 @@ autogenerated: rest
|
|||
|
||||
## About deployment environments
|
||||
|
||||
For more information about environments, see "[AUTOTITLE](/actions/deployment/targeting-different-environments/using-environments-for-deployment)." To manage environment secrets, see "[AUTOTITLE](/rest/actions#secrets)."
|
||||
For more information about environments, see "[AUTOTITLE](/actions/deployment/targeting-different-environments/using-environments-for-deployment)." To manage environment secrets, see "[AUTOTITLE](/rest/actions/secrets)."
|
||||
|
||||
{% data reusables.gated-features.environments %}
|
||||
|
||||
|
|
|
@ -16,6 +16,6 @@ autogenerated: rest
|
|||
|
||||
## About Git commits
|
||||
|
||||
A Git commit is a snapshot of the hierarchy ([Git tree](/rest/git#trees)) and the contents of the files ([Git blob](/rest/git#blobs)) in a Git repository. These endpoints allow you to read and write [commit objects](https://git-scm.com/book/en/v2/Git-Internals-Git-Objects#_git_commit_objects) to your Git database on {% data variables.product.product_name %}.
|
||||
A Git commit is a snapshot of the hierarchy ([Git tree](/rest/git/trees)) and the contents of the files ([Git blob](/rest/git/blobs)) in a Git repository. These endpoints allow you to read and write [commit objects](https://git-scm.com/book/en/v2/Git-Internals-Git-Objects#_git_commit_objects) to your Git database on {% data variables.product.product_name %}.
|
||||
|
||||
<!-- Content after this section is automatically generated -->
|
||||
|
|
|
@ -16,6 +16,6 @@ autogenerated: rest
|
|||
|
||||
## About Git tags
|
||||
|
||||
A Git tag is similar to a [Git reference](/rest/git#refs), but the Git commit that it points to never changes. Git tags are helpful when you want to point to specific releases. These endpoints allow you to read and write [tag objects](https://git-scm.com/book/en/v2/Git-Internals-Git-References#_tags) to your Git database on {% data variables.product.product_name %}. The API only supports [annotated tag objects](https://git-scm.com/book/en/v2/Git-Internals-Git-References#_tags), not lightweight tags.
|
||||
A Git tag is similar to a [Git reference](/rest/git/refs), but the Git commit that it points to never changes. Git tags are helpful when you want to point to specific releases. These endpoints allow you to read and write [tag objects](https://git-scm.com/book/en/v2/Git-Internals-Git-References#_tags) to your Git database on {% data variables.product.product_name %}. The API only supports [annotated tag objects](https://git-scm.com/book/en/v2/Git-Internals-Git-References#_tags), not lightweight tags.
|
||||
|
||||
<!-- Content after this section is automatically generated -->
|
||||
|
|
|
@ -45,7 +45,7 @@ Next, we'll pass in our application's [OAuth token for a given user](/apps/oauth
|
|||
client = Octokit::Client.new :access_token => ENV["OAUTH_ACCESS_TOKEN"]
|
||||
```
|
||||
|
||||
Then, we're ready to fetch the [repositories that our application can access for the user](/rest/repos#list-repositories-for-the-authenticated-user):
|
||||
Then, we're ready to fetch the [repositories that our application can access for the user](/rest/repos/repos#list-repositories-for-the-authenticated-user):
|
||||
|
||||
``` ruby
|
||||
client.repositories.each do |repository|
|
||||
|
@ -64,7 +64,7 @@ end
|
|||
|
||||
## Discover the organizations that your app can access for a user
|
||||
|
||||
Applications can perform all sorts of organization-related tasks for a user. To perform these tasks, the app needs an [OAuth authorization](/apps/oauth-apps/building-oauth-apps/scopes-for-oauth-apps) with sufficient permission. For example, the `read:org` scope allows you to [list teams](/rest/teams#list-teams), and the `user` scope lets you [publicize the user’s organization membership](/rest/orgs#set-public-organization-membership-for-the-authenticated-user). Once a user has granted one or more of these scopes to your app, you're ready to fetch the user’s organizations.
|
||||
Applications can perform all sorts of organization-related tasks for a user. To perform these tasks, the app needs an [OAuth authorization](/apps/oauth-apps/building-oauth-apps/scopes-for-oauth-apps) with sufficient permission. For example, the `read:org` scope allows you to [list teams](/rest/teams/teams#list-teams), and the `user` scope lets you [publicize the user’s organization membership](/rest/orgs/members#set-public-organization-membership-for-the-authenticated-user). Once a user has granted one or more of these scopes to your app, you're ready to fetch the user’s organizations.
|
||||
|
||||
Just as we did when discovering repositories above, we'll start by requiring [GitHub's Octokit.rb](https://github.com/octokit/octokit.rb) Ruby library and configuring it to take care of pagination for us. For more information about pagination, see "[AUTOTITLE](/rest/guides/using-pagination-in-the-rest-api)."
|
||||
|
||||
|
@ -82,7 +82,7 @@ Next, we'll pass in our application's [OAuth token for a given user](/apps/oauth
|
|||
client = Octokit::Client.new :access_token => ENV["OAUTH_ACCESS_TOKEN"]
|
||||
```
|
||||
|
||||
Then, we can [list the organizations that our application can access for the user](/rest/orgs#list-organizations-for-the-authenticated-user):
|
||||
Then, we can [list the organizations that our application can access for the user](/rest/orgs/orgs#list-organizations-for-the-authenticated-user):
|
||||
|
||||
``` ruby
|
||||
client.organizations.each do |organization|
|
||||
|
@ -92,6 +92,6 @@ end
|
|||
|
||||
### Return all of the user's organization memberships
|
||||
|
||||
If you've read the docs from cover to cover, you may have noticed an [API method for listing a user's public organization memberships](/rest/orgs#list-organizations-for-a-user). Most applications should avoid this API method. This method only returns the user's public organization memberships, not their private organization memberships.
|
||||
If you've read the docs from cover to cover, you may have noticed an [API method for listing a user's public organization memberships](/rest/orgs/orgs#list-organizations-for-a-user). Most applications should avoid this API method. This method only returns the user's public organization memberships, not their private organization memberships.
|
||||
|
||||
As an application, you typically want all of the user's organizations that your app is authorized to access. The workflow above will give you exactly that.
|
||||
|
|
|
@ -270,7 +270,7 @@ something like this:
|
|||
```
|
||||
|
||||
Since we already have a list of repositories above, let's inspect each one, and
|
||||
call the [GET /repos/{owner}/{repo}/languages endpoint](/rest/repos#list-repository-languages):
|
||||
call the [GET /repos/{owner}/{repo}/languages endpoint](/rest/repos/repos#list-repository-languages):
|
||||
|
||||
``` ruby
|
||||
repos.each do |repo|
|
||||
|
@ -302,7 +302,7 @@ end
|
|||
language_bytes = [ :name => "language_bytes", :elements => language_byte_count]
|
||||
```
|
||||
|
||||
(For more information on D3 tree map magic, check out [this simple tutorial](/rest/repos#list-repository-languages).)
|
||||
(For more information on D3 tree map magic, check out [this simple tutorial](/rest/repos/repos#list-repository-languages).)
|
||||
|
||||
To wrap up, we pass this JSON information over to the same ERB template:
|
||||
|
||||
|
|
|
@ -41,7 +41,7 @@ The check suite reports the highest priority check run `conclusion` in the check
|
|||
|
||||
By default, GitHub creates a check suite automatically when code is pushed to the repository. This default flow sends the `check_suite` event (with `requested` action) to all GitHub Apps that have the `checks:write` permission. When your GitHub App receives the `check_suite` event, it can create new check runs for the latest commit. GitHub automatically adds new check runs to the correct [check suite](/rest/checks#check-suites) based on the check run's repository and SHA.
|
||||
|
||||
If you don't want to use the default automatic flow, you can control when you create check suites. To change the default settings for the creation of check suites, use the [Update repository preferences for check suites](/rest/checks#update-repository-preferences-for-check-suites) endpoint. All changes to the automatic flow settings are recorded in the audit log for the repository. If you have disabled the automatic flow, you can create a check suite using the [Create a check suite](/rest/checks#create-a-check-suite) endpoint. You should continue to use the [Create a check run](/rest/checks#create-a-check-run) endpoint to provide feedback on a commit.
|
||||
If you don't want to use the default automatic flow, you can control when you create check suites. To change the default settings for the creation of check suites, use the [Update repository preferences for check suites](/rest/checks/suites#update-repository-preferences-for-check-suites) endpoint. All changes to the automatic flow settings are recorded in the audit log for the repository. If you have disabled the automatic flow, you can create a check suite using the [Create a check suite](/rest/checks/suites#create-a-check-suite) endpoint. You should continue to use the [Create a check run](/rest/checks/runs#create-a-check-run) endpoint to provide feedback on a commit.
|
||||
|
||||
{% data reusables.apps.checks-availability %}
|
||||
|
||||
|
@ -82,7 +82,7 @@ When you set up a check run with requested actions (not to be confused with {% d
|
|||
|
||||
For example, a code linting app could use requested actions to display a button in a pull request to automatically fix detected syntax errors.
|
||||
|
||||
To create a button that can request additional actions from your app, use the [`actions` object](/rest/checks#create-a-check-run--parameters) when you [Create a check run](/rest/checks#create-a-check-run). For example, the `actions` object below displays a button in the **Checks** tab of a pull request with the label "Fix this." The button appears after the check run completes.
|
||||
To create a button that can request additional actions from your app, use the [`actions` object](/rest/checks/runs#create-a-check-run--parameters) when you [Create a check run](/rest/checks#create-a-check-run). For example, the `actions` object below displays a button in the **Checks** tab of a pull request with the label "Fix this." The button appears after the check run completes.
|
||||
|
||||
```json
|
||||
"actions": [{
|
||||
|
|
|
@ -41,14 +41,14 @@ the model and it opens up a ton of things you could potentially do with the API.
|
|||
|
||||
{% warning %}
|
||||
|
||||
**Warning!** Please do not depend on using Git directly or [`GET /repos/{owner}/{repo}/git/refs/{ref}`](/rest/git#get-a-reference) for updates to `merge` Git refs, because this content becomes outdated without warning.
|
||||
**Warning!** Please do not depend on using Git directly or [`GET /repos/{owner}/{repo}/git/refs/{ref}`](/rest/git/refs#get-a-reference) for updates to `merge` Git refs, because this content becomes outdated without warning.
|
||||
|
||||
{% endwarning %}
|
||||
|
||||
A consuming API needs to explicitly request a pull request to create a _test_ merge commit. A _test_ merge commit is created when you view the pull request in the UI and the "Merge" button is displayed, or when you [get](/rest/pulls#get-a-pull-request), [create](/rest/pulls#create-a-pull-request), or [edit](/rest/pulls#update-a-pull-request) a pull request using the REST API. Without this request, the `merge` Git refs will fall out of date until the next time someone views the pull request.
|
||||
A consuming API needs to explicitly request a pull request to create a _test_ merge commit. A _test_ merge commit is created when you view the pull request in the UI and the "Merge" button is displayed, or when you [get](/rest/pulls/pulls#get-a-pull-request), [create](/rest/pulls/pulls#create-a-pull-request), or [edit](/rest/pulls#update-a-pull-request) a pull request using the REST API. Without this request, the `merge` Git refs will fall out of date until the next time someone views the pull request.
|
||||
|
||||
If you are currently using polling methods that produce outdated `merge` Git refs, then GitHub recommends using the following steps to get the latest changes from the default branch:
|
||||
|
||||
1. Receive the pull request webhook.
|
||||
1. Call [`GET /repos/{owner}/{repo}/pulls/{pull_number}`](/rest/pulls#get-a-pull-request) to start a background job for creating the merge commit candidate.
|
||||
1. Poll your repository using [`GET /repos/{owner}/{repo}/pulls/{pull_number}`](/rest/pulls#get-a-pull-request) to see if the `mergeable` attribute is `true` or `false`. You can use Git directly or [`GET /repos/{owner}/{repo}/git/refs/{ref}`](/rest/git#get-a-reference) for updates to `merge` Git refs only after performing the previous steps.
|
||||
1. Call [`GET /repos/{owner}/{repo}/pulls/{pull_number}`](/rest/pulls/pulls#get-a-pull-request) to start a background job for creating the merge commit candidate.
|
||||
1. Poll your repository using [`GET /repos/{owner}/{repo}/pulls/{pull_number}`](/rest/pulls/pulls#get-a-pull-request) to see if the `mergeable` attribute is `true` or `false`. You can use Git directly or [`GET /repos/{owner}/{repo}/git/refs/{ref}`](/rest/git/refs#get-a-reference) for updates to `merge` Git refs only after performing the previous steps.
|
||||
|
|
|
@ -25,7 +25,7 @@ repository. As always, samples can be found in [our platform-samples repository]
|
|||
|
||||
## Pull Request Comments
|
||||
|
||||
To access comments on a Pull Request, you'll use [the endpoints to manage issues](/rest/issues#comments).
|
||||
To access comments on a Pull Request, you'll use [the endpoints to manage issues](/rest/issues/comments).
|
||||
This may seem counterintuitive at first. But once you understand that a Pull
|
||||
Request is just an Issue with code, it makes sense to use these endpoints to
|
||||
create comments on a Pull Request.
|
||||
|
@ -61,7 +61,7 @@ the comments to fetch information about each one.
|
|||
|
||||
Within the diff view, you can start a discussion on a particular aspect of a singular
|
||||
change made within the Pull Request. These comments occur on the individual lines
|
||||
within a changed file. The endpoint URL for this discussion comes from [the endpoint to manage pull request reviews](/rest/pulls#comments).
|
||||
within a changed file. The endpoint URL for this discussion comes from [the endpoint to manage pull request reviews](/rest/pulls/comments).
|
||||
|
||||
The following code fetches all the Pull Request comments made on files, given a single Pull Request number:
|
||||
|
||||
|
|
|
@ -22,12 +22,12 @@ If a license is matched, the license key and name returned conforms to the [SPDX
|
|||
|
||||
**Note:** These endpoints will also return a repository's license information:
|
||||
|
||||
- [Get a repository](/rest/repos#get-a-repository)
|
||||
- [List repositories for a user](/rest/repos#list-repositories-for-a-user)
|
||||
- [List organization repositories](/rest/repos#list-organization-repositories)
|
||||
- [List forks](/rest/repos#list-forks)
|
||||
- [List repositories watched by a user](/rest/activity#list-repositories-watched-by-a-user)
|
||||
- [List team repositories](/rest/teams#list-team-repositories)
|
||||
- [Get a repository](/rest/repos/repos#get-a-repository)
|
||||
- [List repositories for a user](/rest/repos/repos#list-repositories-for-a-user)
|
||||
- [List organization repositories](/rest/repos/repos#list-organization-repositories)
|
||||
- [List forks](/rest/repos/forks#list-forks)
|
||||
- [List repositories watched by a user](/rest/activity/watching#list-repositories-watched-by-a-user)
|
||||
- [List team repositories](/rest/teams/teams#list-team-repositories)
|
||||
|
||||
{% warning %}
|
||||
|
||||
|
|
|
@ -40,9 +40,9 @@ Pull requests have these possible link relations:
|
|||
- `self`: The API location of this pull request
|
||||
- `html`: The HTML location of this pull request
|
||||
- `issue`: The API location of this pull request's [issue](/rest/issues)
|
||||
- `comments`: The API location of this pull request's [issue comments](/rest/issues#comments)
|
||||
- `review_comments`: The API location of this pull request's [review comments](/rest/pulls#comments)
|
||||
- `review_comment`: The [URL template](/rest/using-the-rest-api/getting-started-with-the-rest-api#hypermedia) to construct the API location for a [review comment](/rest/pulls#comments) in this pull request's repository
|
||||
- `comments`: The API location of this pull request's [issue comments](/rest/issues/comments)
|
||||
- `review_comments`: The API location of this pull request's [review comments](/rest/pulls/comments)
|
||||
- `review_comment`: The [URL template](/rest/using-the-rest-api/getting-started-with-the-rest-api#hypermedia) to construct the API location for a [review comment](/rest/pulls/comments) in this pull request's repository
|
||||
- `commits`: The API location of this pull request's [commits](#list-commits-on-a-pull-request)
|
||||
- `statuses`: The API location of this pull request's [commit statuses](/rest/commits#commit-statuses), which are the statuses of its `head` branch
|
||||
|
||||
|
|
|
@ -718,6 +718,6 @@ You can then expand these templates using something like the [uri_template](http
|
|||
|
||||
## Next steps
|
||||
|
||||
This article demonstrated how to list and create issues in a repository. For more practice, try to comment on an issue, edit the title of an issue, or close an issue. For more information, see the ["Create an issue comment" endpoint](/rest/issues#create-an-issue-comment) and the ["Update an issue" endpoint](/rest/issues/issues#update-an-issue).
|
||||
This article demonstrated how to list and create issues in a repository. For more practice, try to comment on an issue, edit the title of an issue, or close an issue. For more information, see the ["Create an issue comment" endpoint](/rest/issues/comments#create-an-issue-comment) and the ["Update an issue" endpoint](/rest/issues/issues#update-an-issue).
|
||||
|
||||
For more information about other endpoints that you can use, see the [REST reference documentation](/rest).
|
||||
|
|
|
@ -52,7 +52,7 @@ The event objects returned from the Events API endpoints have the same structure
|
|||
|
||||
### Example WatchEvent event object
|
||||
|
||||
This example shows the format of the [WatchEvent](#watchevent) response when using the [Events API](/rest/activity#events).
|
||||
This example shows the format of the [WatchEvent](#watchevent) response when using the [Events API](/rest/activity/events).
|
||||
|
||||
```http
|
||||
HTTP/2 200
|
||||
|
@ -242,7 +242,7 @@ Key | Type | Description
|
|||
`push_id` | `integer` | Unique identifier for the push.
|
||||
`size`|`integer` | The number of commits in the push.
|
||||
`distinct_size`|`integer` | The number of distinct commits in the push.
|
||||
`ref`|`string` | The full [`git ref`](/rest/git#refs) that was pushed. Example: `refs/heads/main`.
|
||||
`ref`|`string` | The full [`git ref`](/rest/git/refs) that was pushed. Example: `refs/heads/main`.
|
||||
`head`|`string` | The SHA of the most recent commit on `ref` after the push.
|
||||
`before`|`string` | The SHA of the most recent commit on `ref` before the push.
|
||||
`commits`|`array` | An array of commit objects describing the pushed commits. (The array includes a maximum of 20 commits. If necessary, you can use the [Commits API](/rest/repos#commits) to fetch additional commits. This limit is applied to timeline events only and isn't applied to webhook deliveries.)
|
||||
|
|
|
@ -14,7 +14,7 @@ versions:
|
|||
topics:
|
||||
- Events
|
||||
---
|
||||
Issue events are triggered by activity in issues and pull requests and are available in the REST API for [Issue events](/rest/issues#events) and [Timeline events](/rest/issues#timeline). Each event type specifies whether the event is available in the REST API for issue events or timeline events.
|
||||
Issue events are triggered by activity in issues and pull requests and are available in the REST API for [Issue events](/rest/issues/events) and [Timeline events](/rest/issues/timeline). Each event type specifies whether the event is available in the REST API for issue events or timeline events.
|
||||
|
||||
GitHub's REST API considers every pull request to be an issue, but not every issue is a pull request. For this reason, the Issue Events and Timeline Events endpoints may return both issues and pull requests in the response. Pull requests have a `pull_request` property in the `issue` object. Because pull requests are issues, issue and pull request numbers do not overlap in a repository. For example, if you open your first issue in a repository, the number will be 1. If you then open a pull request, the number will be 2. Each event type specifies if the event occurs in pull request, issues, or both.
|
||||
|
||||
|
@ -204,7 +204,7 @@ Name | Type | Description
|
|||
`tree` | `object` | The Git tree of the commit.
|
||||
`message` | `string` | The commit message.
|
||||
`parents` | `array of objects` | A list of parent commits.
|
||||
`verification` | `object` | The result of verifying the commit's signature. For more information, see "[AUTOTITLE](/rest/git#get-a-commit)."
|
||||
`verification` | `object` | The result of verifying the commit's signature. For more information, see "[AUTOTITLE](/rest/git/commits#get-a-commit)."
|
||||
`event` | `string` | The event value is `"committed"`.
|
||||
|
||||
## connected
|
||||
|
|
|
@ -39,7 +39,7 @@ curl -H "Time-Zone: Europe/Amsterdam" -X POST {% data variables.product.api_url_
|
|||
|
||||
This means that we generate a timestamp for the moment your API call is made, in the timezone this header defines.
|
||||
|
||||
For example, the API to manage contents generates a git commit for each addition or change, and it uses the current time as the timestamp. For more information, see "[AUTOTITLE](/rest/repos#contents)." The `Time-Zone` header will determine the timezone used for generating that current timestamp.
|
||||
For example, the API to manage contents generates a git commit for each addition or change, and it uses the current time as the timestamp. For more information, see "[AUTOTITLE](/rest/repos/contents)." The `Time-Zone` header will determine the timezone used for generating that current timestamp.
|
||||
|
||||
### Using the last known timezone for the user
|
||||
|
||||
|
|
|
@ -30,7 +30,7 @@ When deploying a reverse proxy, you should follow all practices recommended by y
|
|||
|
||||
You should configure your reverse proxy to only allow HTTPS POST requests from the subset of {% data variables.product.prodname_dotcom %} IP ranges that are used to deliver webhooks. This ensures that your reverse proxy does not process or forward other requests.
|
||||
|
||||
The [`/meta` endpoint](/rest/meta#get-github-meta-information) returns a JSON object listing GitHub's IP ranges. IP ranges used to deliver webhooks are listed in the `hooks` element.
|
||||
The [`/meta` endpoint](/rest/meta/meta#get-github-meta-information) returns a JSON object listing GitHub's IP ranges. IP ranges used to deliver webhooks are listed in the `hooks` element.
|
||||
|
||||
### Validating webhook payloads
|
||||
|
||||
|
|
Загрузка…
Ссылка в новой задаче