зеркало из https://github.com/github/docs.git
Merge branch 'main' into patch-1
This commit is contained in:
Janice
GitHub
Коммит
83fe9e2774
|
|
@ -107,7 +107,7 @@ jobs:
|
|||
with:
|
||||
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
|
||||
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
|
||||
aws-region: $AWS_REGION
|
||||
aws-region: ${{ env.AWS_REGION }}
|
||||
|
||||
- name: Login to Amazon ECR
|
||||
id: login-ecr
|
||||
|
|
@ -124,22 +124,22 @@ jobs:
|
|||
# be deployed to ECS.
|
||||
docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
|
||||
docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
|
||||
echo "image=$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG" >> $GITHUB_ENV
|
||||
echo "::set-output name=image::$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG"
|
||||
|
||||
- name: Fill in the new image ID in the Amazon ECS task definition
|
||||
id: task-def
|
||||
uses: aws-actions/amazon-ecs-render-task-definition@v1
|
||||
with:
|
||||
task-definition: $ECS_TASK_DEFINITION
|
||||
container-name: $CONTAINER_NAME
|
||||
task-definition: ${{ env.ECS_TASK_DEFINITION }}
|
||||
container-name: ${{ env.CONTAINER_NAME }}
|
||||
image: ${{ steps.build-image.outputs.image }}
|
||||
|
||||
- name: Deploy Amazon ECS task definition
|
||||
uses: aws-actions/amazon-ecs-deploy-task-definition@v1
|
||||
with:
|
||||
task-definition: ${{ steps.task-def.outputs.task-definition }}
|
||||
service: $ECS_SERVICE
|
||||
cluster: $ECS_CLUSTER
|
||||
service: ${{ env.ECS_SERVICE }}
|
||||
cluster: ${{ env.ECS_CLUSTER }}
|
||||
wait-for-service-stability: true
|
||||
```
|
||||
{% endraw %}
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ jobs:
|
|||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
# Setup .npmrc file to publish to npm
|
||||
- uses: actions/setup-node@v1
|
||||
- uses: actions/setup-node@v2
|
||||
with:
|
||||
node-version: '12.x'
|
||||
registry-url: 'https://registry.npmjs.org'
|
||||
|
|
@ -130,7 +130,7 @@ jobs:
|
|||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
# Setup .npmrc file to publish to GitHub Packages
|
||||
- uses: actions/setup-node@v1
|
||||
- uses: actions/setup-node@v2
|
||||
with:
|
||||
node-version: '12.x'
|
||||
registry-url: 'https://npm.pkg.github.com'
|
||||
|
|
@ -167,7 +167,7 @@ jobs:
|
|||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
# Setup .npmrc file to publish to npm
|
||||
- uses: actions/setup-node@v1
|
||||
- uses: actions/setup-node@v2
|
||||
with:
|
||||
node-version: '12.x'
|
||||
registry-url: 'https://registry.npmjs.org'
|
||||
|
|
|
|||
|
|
@ -343,7 +343,7 @@ jobs:
|
|||
- run: |
|
||||
echo "Comment on PR #${{ github.event.issue.number }}"
|
||||
|
||||
issue-commented:
|
||||
issue_commented:
|
||||
# This job only runs for issue comments
|
||||
name: Issue comment
|
||||
if: ${{ !github.event.issue.pull_request }}
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ versions:
|
|||
|
||||
### Introduction
|
||||
|
||||
This guide will introduce you to [Github Apps](/apps/) and the [Checks API](/rest/reference/checks), which you'll use to build a continuous integration (CI) server that runs tests.
|
||||
This guide will introduce you to [GitHub Apps](/apps/) and the [Checks API](/rest/reference/checks), which you'll use to build a continuous integration (CI) server that runs tests.
|
||||
|
||||
CI is a software practice that requires frequently committing code to a shared repository. Committing code more often raises errors sooner and reduces the amount of code a developer needs to debug when finding the source of an error. Frequent code updates also make it easier to merge changes from different members of a software development team. This is great for developers, who can spend more time writing code and less time debugging errors or resolving merge conflicts. 🙌
|
||||
|
||||
|
|
@ -49,7 +49,7 @@ To get an idea of what your Checks API CI server will do when you've completed t
|
|||
|
||||
### Prerequisites
|
||||
|
||||
Before you get started, you may want to familiarize yourself with [Github Apps](/apps/), [Webhooks](/webhooks), and the [Checks API](/rest/reference/checks), if you're not already. You'll find more APIs in the [REST API docs](/rest). The Checks API is also available to use in [GraphQL](/graphql), but this quickstart focuses on REST. See the GraphQL [Checks Suite](/graphql/reference/objects#checksuite) and [Check Run](/graphql/reference/objects#checkrun) objects for more details.
|
||||
Before you get started, you may want to familiarize yourself with [GitHub Apps](/apps/), [Webhooks](/webhooks), and the [Checks API](/rest/reference/checks), if you're not already. You'll find more APIs in the [REST API docs](/rest). The Checks API is also available to use in [GraphQL](/graphql), but this quickstart focuses on REST. See the GraphQL [Checks Suite](/graphql/reference/objects#checksuite) and [Check Run](/graphql/reference/objects#checkrun) objects for more details.
|
||||
|
||||
You'll use the [Ruby programming language](https://www.ruby-lang.org/en/), the [Smee](https://smee.io/) webhook payload delivery service, the [Octokit.rb Ruby library](http://octokit.github.io/octokit.rb/) for the GitHub REST API, and the [Sinatra web framework](http://sinatrarb.com/) to create your Checks API CI server app.
|
||||
|
||||
|
|
@ -203,7 +203,7 @@ Great! You've told GitHub to create a check run. You can see the check run statu
|
|||
|
||||
### Step 1.4. Updating a check run
|
||||
|
||||
When your `create_check_run` method runs, it asks GitHub to create a new check run. When Github finishes creating the check run, you'll receive the `check_run` webhook event with the `created` action. That event is your signal to begin running the check.
|
||||
When your `create_check_run` method runs, it asks GitHub to create a new check run. When GitHub finishes creating the check run, you'll receive the `check_run` webhook event with the `created` action. That event is your signal to begin running the check.
|
||||
|
||||
You'll want to update your event handler to look for the `created` action. While you're updating the event handler, you can add a conditional for the `rerequested` action. When someone re-runs a single test on GitHub by clicking the "Re-run" button, GitHub sends the `rerequested` check run event to your app. When a check run is `rerequested`, you'll want to start the process all over and create a new check run.
|
||||
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ GitHub Apps use [sliding rules for rate limits](/apps/building-github-apps/under
|
|||
|
||||
#### Register a new GitHub App
|
||||
|
||||
Once you've decided to make the switch to Github Apps, you'll need to [create a new GitHub App](/apps/building-github-apps/).
|
||||
Once you've decided to make the switch to GitHub Apps, you'll need to [create a new GitHub App](/apps/building-github-apps/).
|
||||
|
||||
#### Determine the permissions your app requires
|
||||
|
||||
|
|
@ -62,7 +62,7 @@ In your GitHub App's settings, you can specify whether your app needs `No Access
|
|||
|
||||
#### Subscribe to webhooks
|
||||
|
||||
After you've created a new GitHub App and selected its permissions, you can select the webhook events you wish to subscribe it to. See "[Editing a Github App's permissions](/apps/managing-github-apps/editing-a-github-app-s-permissions/)" to learn how to subscribe to webhooks.
|
||||
After you've created a new GitHub App and selected its permissions, you can select the webhook events you wish to subscribe it to. See "[Editing a GitHub App's permissions](/apps/managing-github-apps/editing-a-github-app-s-permissions/)" to learn how to subscribe to webhooks.
|
||||
|
||||
#### Understand the different methods of authentication
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ versions:
|
|||
|
||||
{% warning %}
|
||||
|
||||
If you offer a GitHub App in {% data variables.product.prodname_marketplace %}, your app must identify users following the OAuth authorization flow. You don't need to set up a separate OAuth App to support this flow. See "[Identifying and authorizing users for GitHub Apps](/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps/)" for more information.
|
||||
If you offer a {% data variables.product.prodname_github_app %} in {% data variables.product.prodname_marketplace %}, your app must identify users following the OAuth authorization flow. You don't need to set up a separate {% data variables.product.prodname_oauth_app %} to support this flow. See "[Identifying and authorizing users for {% data variables.product.prodname_github_apps %}](/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps/)" for more information.
|
||||
|
||||
{% endwarning %}
|
||||
|
||||
|
|
@ -24,7 +24,7 @@ Before a customer purchases your {% data variables.product.prodname_marketplace
|
|||
|
||||
The customer completes the purchase by clicking **Complete order and begin installation**.
|
||||
|
||||
GitHub then sends the [`marketplace_purchase`](/webhooks/event-payloads/#marketplace_purchase) webhook with the `purchased` action to your app.
|
||||
{% data variables.product.product_name %} then sends the [`marketplace_purchase`](/webhooks/event-payloads/#marketplace_purchase) webhook with the `purchased` action to your app.
|
||||
|
||||
Read the `effective_date` and `marketplace_purchase` object from the `marketplace_purchase` webhook to determine which plan the customer purchased, when the billing cycle starts, and when the next billing cycle begins.
|
||||
|
||||
|
|
@ -34,27 +34,27 @@ See "[{% data variables.product.prodname_marketplace %} webhook events](/marketp
|
|||
|
||||
### Step 2. Installation
|
||||
|
||||
If your app is a GitHub App, GitHub prompts the customer to select which repositories the app can access when they purchase it. GitHub then installs the app on the account the customer selected and grants access to the selected repositories.
|
||||
If your app is a {% data variables.product.prodname_github_app %}, {% data variables.product.product_name %} prompts the customer to select which repositories the app can access when they purchase it. {% data variables.product.product_name %} then installs the app on the account the customer selected and grants access to the selected repositories.
|
||||
|
||||
At this point, if you specified a **Setup URL** in your GitHub App settings, Github will redirect the customer to that URL. If you do not specify a setup URL, you will not be able to handle purchases of your GitHub App.
|
||||
At this point, if you specified a **Setup URL** in your {% data variables.product.prodname_github_app %} settings, {% data variables.product.product_name %} will redirect the customer to that URL. If you do not specify a setup URL, you will not be able to handle purchases of your {% data variables.product.prodname_github_app %}.
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** The **Setup URL** is described as optional in GitHub App settings, but it is a required field if you want to offer your app in {% data variables.product.prodname_marketplace %}.
|
||||
**Note:** The **Setup URL** is described as optional in {% data variables.product.prodname_github_app %} settings, but it is a required field if you want to offer your app in {% data variables.product.prodname_marketplace %}.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
If your app is an OAuth App, GitHub does not install it anywhere. Instead, GitHub redirects the customer to the **Installation URL** you specified in your [{% data variables.product.prodname_marketplace %} listing](/marketplace/listing-on-github-marketplace/writing-github-marketplace-listing-descriptions/#listing-urls).
|
||||
If your app is an {% data variables.product.prodname_oauth_app %}, {% data variables.product.product_name %} does not install it anywhere. Instead, {% data variables.product.product_name %} redirects the customer to the **Installation URL** you specified in your [{% data variables.product.prodname_marketplace %} listing](/marketplace/listing-on-github-marketplace/writing-github-marketplace-listing-descriptions/#listing-urls).
|
||||
|
||||
When a customer purchases an OAuth App, GitHub redirects the customer to the URL you choose (either Setup URL or Installation URL) and the URL includes the customer's selected pricing plan as a query parameter: `marketplace_listing_plan_id`.
|
||||
When a customer purchases an {% data variables.product.prodname_oauth_app %}, {% data variables.product.product_name %} redirects the customer to the URL you choose (either Setup URL or Installation URL) and the URL includes the customer's selected pricing plan as a query parameter: `marketplace_listing_plan_id`.
|
||||
|
||||
### Step 3. Authorization
|
||||
|
||||
When a customer purchases your app, you must send the customer through the OAuth authorization flow:
|
||||
|
||||
* If your app is a GitHub App, begin the authorization flow as soon as GitHub redirects the customer to the **Setup URL**. Follow the steps in "[Identifying and authorizing users for GitHub Apps](/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps/)."
|
||||
* If your app is a {% data variables.product.prodname_github_app %}, begin the authorization flow as soon as {% data variables.product.product_name %} redirects the customer to the **Setup URL**. Follow the steps in "[Identifying and authorizing users for {% data variables.product.prodname_github_apps %}](/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps/)."
|
||||
|
||||
* If your app is an OAuth App, begin the authorization flow as soon as GitHub redirects the customer to the **Installation URL**. Follow the steps in "[Authorizing OAuth Apps](/apps/building-oauth-apps/authorizing-oauth-apps/)."
|
||||
* If your app is an {% data variables.product.prodname_oauth_app %}, begin the authorization flow as soon as {% data variables.product.product_name %} redirects the customer to the **Installation URL**. Follow the steps in "[Authorizing {% data variables.product.prodname_oauth_apps %}](/apps/building-oauth-apps/authorizing-oauth-apps/)."
|
||||
|
||||
For either type of app, the first step is to redirect the customer to https://github.com/login/oauth/authorize.
|
||||
|
||||
|
|
|
|||
|
|
@ -64,9 +64,9 @@ After you enable SCIM, the following provisioning features are available for any
|
|||
|
||||
|
||||
{% note %}
|
||||
|
||||
|
||||
**Note**: If you don't see your organization in the list, go to `https://github.com/orgs/ORGANIZATION-NAME/sso` in your browser and authenticate with your organization via SAML SSO using your administrator account on the IdP. For example, if your organization's name is `octo-org`, the URL would be `https://github.com/orgs/octo-org/sso`. For more information, see "[About authentication with SAML single sign-on](/github/authenticating-to-github/about-authentication-with-saml-single-sign-on)."
|
||||
|
||||
|
||||
{% endnote %}
|
||||
1. Click **Authorize OktaOAN**.
|
||||
|
||||
|
|
|
|||
|
|
@ -165,7 +165,7 @@ To help you gracefully handle these situations, all API responses for requests
|
|||
made with valid tokens also contain an [`X-OAuth-Scopes` header][oauth scopes].
|
||||
This header contains the list of scopes of the token that was used to make the
|
||||
request. In addition to that, the OAuth Applications API provides an endpoint to {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.19" %}
|
||||
[check a token for validity][/rest/reference/apps#check-a-token]{% else %}[check a token for validity][/rest/reference/apps#check-an-authorization]{% endif %}.
|
||||
[check a token for validity](/rest/reference/apps#check-a-token){% else %}[check a token for validity](/rest/reference/apps#check-an-authorization){% endif %}.
|
||||
Use this information to detect changes in token scopes, and inform your users of
|
||||
changes in available application functionality.
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ versions:
|
|||
|
||||
### Clojure
|
||||
|
||||
Library name | Repository
|
||||
Library name | Repository
|
||||
|---|---|
|
||||
**Tentacles**| [Raynes/tentacles](https://github.com/Raynes/tentacles)
|
||||
|
||||
|
|
@ -80,7 +80,7 @@ Library name | Repository |
|
|||
|
||||
Library name | Repository |
|
||||
|---|---|
|
||||
**Github.jl**|[WestleyArgentum/Github.jl](https://github.com/WestleyArgentum/GitHub.jl)
|
||||
**GitHub.jl**|[WestleyArgentum/GitHub.jl](https://github.com/WestleyArgentum/GitHub.jl)
|
||||
|
||||
### OCaml
|
||||
|
||||
|
|
@ -93,7 +93,7 @@ Library name | Repository |
|
|||
Library name | Repository | metacpan Website for the Library
|
||||
|---|---|---|
|
||||
**Pithub**|[plu/Pithub](https://github.com/plu/Pithub)|[Pithub CPAN](http://metacpan.org/module/Pithub)
|
||||
**Net::Github**|[fayland/perl-net-github](https://github.com/fayland/perl-net-github)|[Net:Github CPAN](https://metacpan.org/pod/Net::GitHub)
|
||||
**Net::GitHub**|[fayland/perl-net-github](https://github.com/fayland/perl-net-github)|[Net:GitHub CPAN](https://metacpan.org/pod/Net::GitHub)
|
||||
|
||||
### PHP
|
||||
|
||||
|
|
@ -105,8 +105,8 @@ Library name | Repository
|
|||
**GitHub Joomla! Package**|[joomla-framework/github-api](https://github.com/joomla-framework/github-api)
|
||||
**GitHub Nette Extension**|[kdyby/github](https://github.com/kdyby/github)
|
||||
**GitHub API Easy Access**|[milo/github-api](https://github.com/milo/github-api)
|
||||
**GitHub bridge for Laravel**|[GrahamCampbell/Laravel-Github](https://github.com/GrahamCampbell/Laravel-GitHub)
|
||||
**PHP7 Client & WebHook wrapper**|[FlexyProject/GithubAPI](https://github.com/FlexyProject/GitHubAPI)
|
||||
**GitHub bridge for Laravel**|[GrahamCampbell/Laravel-GitHub](https://github.com/GrahamCampbell/Laravel-GitHub)
|
||||
**PHP7 Client & WebHook wrapper**|[FlexyProject/GitHubAPI](https://github.com/FlexyProject/GitHubAPI)
|
||||
|
||||
### Python
|
||||
|
||||
|
|
|
|||
|
|
@ -19,14 +19,14 @@
|
|||
- issues
|
||||
- labels
|
||||
- title: Add releases to GitHub
|
||||
description: Publish Github releases in an action
|
||||
description: Publish GitHub releases in an action
|
||||
languages: 'Dockerfile, Shell'
|
||||
href: elgohr/Github-Release-Action
|
||||
tags:
|
||||
- releases
|
||||
- publishing
|
||||
- title: Publish a docker image to Dockerhub
|
||||
description: A Github Action used to build and publish Docker images
|
||||
description: A GitHub Action used to build and publish Docker images
|
||||
languages: 'Dockerfile, Shell'
|
||||
href: elgohr/Publish-Docker-Github-Action
|
||||
tags:
|
||||
|
|
@ -106,7 +106,7 @@
|
|||
- wiki
|
||||
- publishing
|
||||
- title: Label your Pull Requests auto-magically (using committed files)
|
||||
description: Github action to label your pull requests auto-magically (using committed files)
|
||||
description: GitHub action to label your pull requests auto-magically (using committed files)
|
||||
languages: 'TypeScript, Dockerfile, JavaScript'
|
||||
href: Decathlon/pull-request-labeler-action
|
||||
tags:
|
||||
|
|
@ -114,7 +114,7 @@
|
|||
- issues
|
||||
- labels
|
||||
- title: Add Label to your Pull Requests based on the author team name
|
||||
description: Github action to label your pull requests based on the author name
|
||||
description: GitHub action to label your pull requests based on the author name
|
||||
languages: 'TypeScript, JavaScript'
|
||||
href: JulienKode/team-labeler-action
|
||||
tags:
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче