зеркало из https://github.com/github/docs.git
Add missing code block languages for API, events, and Apps docs (#39180)
This commit is contained in:
Родитель
687fbca868
Коммит
1fda56a199
|
@ -66,6 +66,6 @@ If you want your app to use an installation or user access token to authenticate
|
|||
|
||||
You can then use the access token as the HTTP password. Replace `TOKEN` with the access token:
|
||||
|
||||
```
|
||||
git clone https://x-access-token:TOKEN@github.com/owner/repo.git"
|
||||
```shell
|
||||
git clone https://x-access-token:TOKEN@github.com/owner/repo.git
|
||||
```
|
||||
|
|
|
@ -133,13 +133,13 @@ These steps lead you through building a CLI and using device flow to get a user
|
|||
|
||||
In your terminal, from the directory where `app_cli.rb` is stored, run `./app_cli.rb help`. You should see this output:
|
||||
|
||||
```
|
||||
```shell
|
||||
`help` is not yet defined
|
||||
```
|
||||
|
||||
You can also test your script without a command or with an unhandled command. For example, `./app_cli.rb create-issue` should output:
|
||||
|
||||
```
|
||||
```shell
|
||||
Unknown command `create-issue`
|
||||
```
|
||||
|
||||
|
@ -204,7 +204,7 @@ These steps lead you through building a CLI and using device flow to get a user
|
|||
|
||||
In your terminal, from the directory where `app_cli.rb` is stored, run `./app_cli.rb help`. You should see this output:
|
||||
|
||||
```
|
||||
```shell
|
||||
usage: app_cli <help>
|
||||
```
|
||||
|
||||
|
@ -474,7 +474,7 @@ The `login` command will run the device flow to get a user access token. For mor
|
|||
|
||||
1. In your terminal, from the directory where `app_cli.rb` is stored, run `./app_cli.rb login`. You should see output that looks like this. The code will differ every time:
|
||||
|
||||
```
|
||||
```shell
|
||||
Please visit: {% data variables.product.oauth_host_code %}/login/device
|
||||
and enter code: CA86-8D94
|
||||
```
|
||||
|
@ -705,13 +705,13 @@ This tutorial assumes that your app code is stored in a file named `app_cli.rb`.
|
|||
|
||||
1. In your terminal, from the directory where `app_cli.rb` is stored, run `./app_cli.rb help`. You should see output that looks like this.
|
||||
|
||||
```
|
||||
```shell
|
||||
usage: app_cli <login | whoami | help>
|
||||
```
|
||||
|
||||
1. In your terminal, from the directory where `app_cli.rb` is stored, run `./app_cli.rb login`. You should see output that looks like this. The code will differ every time:
|
||||
|
||||
```
|
||||
```shell
|
||||
Please visit: {% data variables.product.oauth_host_code %}/login/device
|
||||
and enter code: CA86-8D94
|
||||
```
|
||||
|
@ -721,21 +721,21 @@ This tutorial assumes that your app code is stored in a file named `app_cli.rb`.
|
|||
1. Your terminal should now say "Successfully authenticated!".
|
||||
1. In your terminal, from the directory where `app_cli.rb` is stored, run `./app_cli.rb whoami`. You should see output that looks like this, where `octocat` is your username.
|
||||
|
||||
```
|
||||
```shell
|
||||
You are octocat
|
||||
```
|
||||
|
||||
1. Open the `.token` file in your editor, and modify the token. Now, the token is invalid.
|
||||
1. In your terminal, from the directory where `app_cli.rb` is stored, run `./app_cli.rb whoami`. You should see output that looks like this:
|
||||
|
||||
```
|
||||
```shell
|
||||
You are not authorized. Run the `login` command.
|
||||
```
|
||||
|
||||
1. Delete the `.token` file.
|
||||
1. In your terminal, from the directory where `app_cli.rb` is stored, run `./app_cli.rb whoami`. You should see output that looks like this:
|
||||
|
||||
```
|
||||
```shell
|
||||
You are not authorized. Run the `login` command.
|
||||
```
|
||||
|
||||
|
|
|
@ -308,7 +308,7 @@ For testing, you will use your computer or codespace as a server. Your app will
|
|||
|
||||
You should see output that looks like this, where `WEBHOOK_PROXY_URL` is your webhook proxy URL:
|
||||
|
||||
```
|
||||
```shell
|
||||
Forwarding WEBHOOK_PROXY_URL to http://localhost:3000/api/webhook
|
||||
Connected WEBHOOK_PROXY_URL
|
||||
```
|
||||
|
|
|
@ -44,29 +44,29 @@ To follow this tutorial, you must install the Sinatra and dotenv gems in your Ru
|
|||
|
||||
1. If you don't already have Bundler installed, run the following command in your terminal:
|
||||
|
||||
```
|
||||
```shell
|
||||
gem install bundler
|
||||
```
|
||||
|
||||
1. If you don't already have a Gemfile for your app, run the following command in your terminal:
|
||||
|
||||
```
|
||||
```shell
|
||||
bundle init
|
||||
```
|
||||
|
||||
1. If you don't already have a Gemfile.lock for your app, run the following command in your terminal:
|
||||
|
||||
```
|
||||
```shell
|
||||
bundle install
|
||||
```
|
||||
|
||||
1. Install the gems by running the following commands in your terminal:
|
||||
|
||||
```
|
||||
```shell
|
||||
bundle add sinatra
|
||||
```
|
||||
|
||||
```
|
||||
```shell
|
||||
bundle add dotenv
|
||||
```
|
||||
|
||||
|
@ -85,7 +85,7 @@ This tutorial will show you how to store the client ID and client secret in envi
|
|||
1. Add `.env` to your `.gitignore` file. This will prevent you from accidentally committing your client secret. For more information about `.gitignore` files, see "[AUTOTITLE](/get-started/getting-started-with-git/ignoring-files)."
|
||||
1. Add the following contents to your `.env` file. Replace `YOUR_CLIENT_ID` with the client ID of your app. Replace `YOUR_CLIENT_SECRET` with the client secret for your app.
|
||||
|
||||
```
|
||||
```text
|
||||
CLIENT_ID="YOUR_CLIENT_ID"
|
||||
CLIENT_SECRET="YOUR_CLIENT_SECRET"
|
||||
```
|
||||
|
|
|
@ -121,7 +121,7 @@ For testing, you will use your computer or codespace as a server. Your app will
|
|||
|
||||
You should see output that looks like this, where `WEBHOOK_PROXY_URL` is your webhook proxy URL:
|
||||
|
||||
```
|
||||
```shell
|
||||
Forwarding WEBHOOK_PROXY_URL to http://localhost:3000/api/webhook
|
||||
Connected WEBHOOK_PROXY_URL
|
||||
```
|
||||
|
|
|
@ -88,7 +88,7 @@ Parameter name | Type | Description
|
|||
|
||||
By default, the response takes the following form:
|
||||
|
||||
```
|
||||
```shell
|
||||
access_token=gho_16C7e42F292c6912E7710c838347Ae178B4a&scope=repo%2Cgist&token_type=bearer
|
||||
```
|
||||
|
||||
|
@ -162,7 +162,7 @@ Parameter name | Type | Description
|
|||
|
||||
By default, the response takes the following form:
|
||||
|
||||
```
|
||||
```shell
|
||||
device_code=3584d83530557fdd1f46af8289938c8ef79f9dc5&expires_in=900&interval=5&user_code=WDJB-MJHT&verification_uri=https%3A%2F%{% data variables.product.product_url %}%2Flogin%2Fdevice
|
||||
```
|
||||
|
||||
|
@ -222,7 +222,7 @@ Parameter name | Type | Description
|
|||
|
||||
By default, the response takes the following form:
|
||||
|
||||
```
|
||||
```shell
|
||||
access_token=gho_16C7e42F292c6912E7710c838347Ae178B4a&token_type=bearer&scope=repo%2Cgist
|
||||
```
|
||||
|
||||
|
@ -297,7 +297,7 @@ The optional `redirect_uri` parameter can also be used for loopback URLs. If the
|
|||
|
||||
For the `http://127.0.0.1/path` callback URL, you can use this `redirect_uri`:
|
||||
|
||||
```
|
||||
```http
|
||||
http://127.0.0.1:1234/path
|
||||
```
|
||||
|
||||
|
@ -319,7 +319,7 @@ You can link to authorization information for an {% data variables.product.prodn
|
|||
|
||||
To build this link, you'll need your {% data variables.product.prodname_oauth_app %}'s `client_id` that you received from GitHub when you registered the application.
|
||||
|
||||
```
|
||||
```http
|
||||
{% data variables.product.oauth_host_code %}/settings/connections/applications/:client_id
|
||||
```
|
||||
|
||||
|
|
|
@ -42,7 +42,7 @@ A GraphQL schema may use the term _implements_ to define how an object inherits
|
|||
|
||||
Here's a contrived example of a schema that defines interface `X` and object `Y`:
|
||||
|
||||
```
|
||||
```graphql
|
||||
interface X {
|
||||
some_field: String!
|
||||
other_field: String!
|
||||
|
|
|
@ -29,7 +29,7 @@ To facilitate migration to the new ID format, you can use the `X-Github-Next-Glo
|
|||
|
||||
Here is an example request using a `curl` command:
|
||||
|
||||
```
|
||||
```shell
|
||||
$ curl \
|
||||
-H "Authorization: Bearer $GITHUB_TOKEN" \
|
||||
-H "X-Github-Next-Global-ID: 1" \
|
||||
|
@ -39,7 +39,7 @@ $ curl \
|
|||
|
||||
Even though the legacy ID `MDQ6VXNlcjM0MDczMDM=` was used in the query, the response will contain the new ID format:
|
||||
|
||||
```
|
||||
```json
|
||||
{"data":{"node":{"id":"U_kgDOADP9xw"}}}
|
||||
```
|
||||
|
||||
|
@ -48,7 +48,7 @@ To perform bulk operations, you can use aliases to submit multiple node queries
|
|||
|
||||
You can also get the new ID for a collection of items. For example, if you wanted to get the new ID for the last 10 repositories in your organization, you could use a query like this:
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
organization(login: "github") {
|
||||
repositories(last: 10) {
|
||||
|
|
|
@ -24,7 +24,7 @@ GitHub dispatches `deployment` and `deployment_status` events when new deploymen
|
|||
|
||||
Below is a simple sequence diagram for how these interactions would work.
|
||||
|
||||
```
|
||||
```text
|
||||
+---------+ +--------+ +-----------+ +-------------+
|
||||
| Tooling | | GitHub | | 3rd Party | | Your Server |
|
||||
+---------+ +--------+ +-----------+ +-------------+
|
||||
|
|
|
@ -22,7 +22,7 @@ These endpoints are based on SCIM 2.0. For more information, refer to your IdP's
|
|||
|
||||
An IdP can use the following root URL to communicate with the endpoints in this category for a {% data variables.product.product_name %} instance.
|
||||
|
||||
```
|
||||
```http
|
||||
{% data variables.product.api_url_code %}/scim/v2/
|
||||
```
|
||||
|
||||
|
@ -45,7 +45,7 @@ To authenticate API requests, the person who configures SCIM on the IdP must use
|
|||
{% endnote %}
|
||||
|
||||
### Mapping of SAML and SCIM data
|
||||
|
||||
|
||||
The {% data variables.product.product_name %} instance links each user who authenticates successfully with SAML SSO to a SCIM identity. To link the identities successfully, the SAML IdP and the SCIM integration must use matching SAML `NameID` and SCIM `userName` values for each user.
|
||||
|
||||
{% ifversion ghes > 3.7 %}
|
||||
|
|
|
@ -707,7 +707,7 @@ jq '.[] | {title: .title, authorID: .user.id}' data.json
|
|||
|
||||
The previous two commands return something like:
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"title": "Update index.html",
|
||||
"authorID": 10701255
|
||||
|
@ -764,7 +764,7 @@ jq '.[] | {title: .title, authorID: .user.id}' data.json
|
|||
|
||||
The previous two commands return something like:
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"title": "Update index.html",
|
||||
"authorID": 10701255
|
||||
|
|
|
@ -33,7 +33,7 @@ curl --include --request GET \
|
|||
|
||||
If the response is paginated, the link header will look something like this:
|
||||
|
||||
```
|
||||
```http
|
||||
link: <https://api.github.com/repositories/1300192/issues?page=2>; rel="prev", <https://api.github.com/repositories/1300192/issues?page=4>; rel="next", <https://api.github.com/repositories/1300192/issues?page=515>; rel="last", <https://api.github.com/repositories/1300192/issues?page=1>; rel="first"
|
||||
```
|
||||
|
||||
|
@ -54,7 +54,7 @@ curl --include --request GET \
|
|||
--header "Accept: application/vnd.github+json"
|
||||
```
|
||||
|
||||
The URLs in the link header use query parameters to indicate what page of results to return. The query parameters in the link URLs may differ between endpoints: each paginated endpoint will use the `page`, `before`/`after`, or `since` query parameters. (Some endpoints use the `since` parameter for something other than pagination.) In all cases, you can use the URLs in the link header to fetch additional pages of results. For more information about query parameters see "[AUTOTITLE](/rest/guides/getting-started-with-the-rest-api#using-query-parameters)."
|
||||
The URLs in the link header use query parameters to indicate what page of results to return. The query parameters in the link URLs may differ between endpoints: each paginated endpoint will use the `page`, `before`/`after`, or `since` query parameters. (Some endpoints use the `since` parameter for something other than pagination.) In all cases, you can use the URLs in the link header to fetch additional pages of results. For more information about query parameters see "[AUTOTITLE](/rest/guides/getting-started-with-the-rest-api#using-query-parameters)."
|
||||
|
||||
## Changing the number of items per page
|
||||
|
||||
|
@ -70,7 +70,7 @@ curl --include --request GET \
|
|||
|
||||
The `per_page` parameter will automatically be included in the link header. For example:
|
||||
|
||||
```
|
||||
```http
|
||||
link: <https://api.github.com/repositories/1300192/issues?per_page=2&page=2>; rel="next", <https://api.github.com/repositories/1300192/issues?per_page=2&page=7715>; rel="last"
|
||||
```
|
||||
|
||||
|
@ -169,7 +169,7 @@ function parseData(data) {
|
|||
// Pull out the array of items
|
||||
const namespaceKey = Object.keys(data)[0];
|
||||
data = data[namespaceKey];
|
||||
|
||||
|
||||
return data;
|
||||
}
|
||||
|
||||
|
|
|
@ -21,7 +21,7 @@ autogenerated: rest
|
|||
|
||||
The following diagram provides a more detailed example:
|
||||
|
||||
```
|
||||
```text
|
||||
+---------+ +--------+ +---------------------+
|
||||
| Tooling | | GitHub | | Original Repository |
|
||||
+---------+ +--------+ +---------------------+
|
||||
|
|
|
@ -41,7 +41,7 @@ Each endpoint for searching uses [query parameters](https://en.wikipedia.org/wik
|
|||
|
||||
A query can contain any combination of search qualifiers supported on {% data variables.product.product_name %}. The format of the search query is:
|
||||
|
||||
```
|
||||
```text
|
||||
SEARCH_KEYWORD_1 SEARCH_KEYWORD_N QUALIFIER_1 QUALIFIER_N
|
||||
```
|
||||
|
||||
|
@ -49,7 +49,7 @@ For example, if you wanted to search for all _repositories_ owned by `defunkt` t
|
|||
contained the word `GitHub` and `Octocat` in the README file, you would use the
|
||||
following query with the _search repositories_ endpoint:
|
||||
|
||||
```
|
||||
```text
|
||||
GitHub Octocat in:readme user:defunkt
|
||||
```
|
||||
|
||||
|
|
|
@ -52,7 +52,7 @@ The event objects returned from the Events API endpoints have the same structure
|
|||
|
||||
This example shows the format of the [WatchEvent](#watchevent) response when using the [Events API](/rest/activity#events).
|
||||
|
||||
```
|
||||
```http
|
||||
HTTP/2 200
|
||||
Link: <https://api.github.com/resource?page=2>; rel="next",
|
||||
<https://api.github.com/resource?page=5>; rel="last"
|
||||
|
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
To receive the `project_card` attribute, project boards must be [enabled](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/disabling-project-boards-in-a-repository) for a repository, and you must provide a custom [media type](/rest/overview/media-types) in the `Accept` header:
|
||||
|
||||
```
|
||||
```text
|
||||
application/vnd.github.starfox-preview+json
|
||||
```
|
||||
|
||||
|
|
Загрузка…
Ссылка в новой задаче