зеркало из https://github.com/github/docs.git
New translation batch for fr (#33395)
This commit is contained in:
Родитель
564ef59988
Коммит
0f3d358be3
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: Creating a composite action
|
||||
title: Création d’une action composite
|
||||
shortTitle: Create a composite action
|
||||
intro: 'In this guide, you''ll learn how to build a composite action.'
|
||||
intro: 'Dans ce guide, vous allez apprendre à générer une action composite.'
|
||||
redirect_from:
|
||||
- /actions/creating-actions/creating-a-composite-run-steps-action
|
||||
versions:
|
||||
|
@ -12,58 +12,61 @@ versions:
|
|||
type: tutorial
|
||||
topics:
|
||||
- Action development
|
||||
ms.openlocfilehash: 5c7d332d2b3626a5628e85b09c35ffa6a0ca5f33
|
||||
ms.sourcegitcommit: 4f08a208a0d2e13dc109678750a962ea2f67e1ba
|
||||
ms.translationtype: HT
|
||||
ms.contentlocale: fr-FR
|
||||
ms.lasthandoff: 12/06/2022
|
||||
ms.locfileid: '148192038'
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
{% data reusables.actions.enterprise-beta %} {% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
## Introduction
|
||||
|
||||
In this guide, you'll learn about the basic components needed to create and use a packaged composite action. To focus this guide on the components needed to package the action, the functionality of the action's code is minimal. The action prints "Hello World" and then "Goodbye", or if you provide a custom name, it prints "Hello [who-to-greet]" and then "Goodbye". The action also maps a random number to the `random-number` output variable, and runs a script named `goodbye.sh`.
|
||||
Dans ce guide, vous allez découvrir les composants de base qui sont nécessaires pour créer et utiliser une action composite empaquetée. Afin de nous concentrer sur les composants nécessaires à l’empaquetage de l’action, nous avons réduit la fonctionnalité du code de l’action à son strict minimum. L’action affiche « Hello World », puis « Goodbye ». Si vous fournissez un nom personnalisé, elle affichera « Hello [who-to-greet] », puis « Goodbye ». L’action mappe également un nombre aléatoire à la variable de sortie `random-number` et exécute un script nommé `goodbye.sh`.
|
||||
|
||||
Once you complete this project, you should understand how to build your own composite action and test it in a workflow.
|
||||
Une fois que vous aurez terminé ce projet, vous saurez comment créer votre propre action composite et la tester dans un workflow.
|
||||
|
||||
{% data reusables.actions.context-injection-warning %}
|
||||
|
||||
## Prerequisites
|
||||
## Prérequis
|
||||
|
||||
Before you begin, you'll create a repository on {% ifversion ghae %}{% data variables.product.product_name %}{% else %}{% data variables.location.product_location %}{% endif %}.
|
||||
Avant de commencer, vous allez créer un référentiel dans {% ifversion ghae %}{% data variables.product.product_name %}{% else %}{% data variables.location.product_location %}{% endif %}.
|
||||
|
||||
1. Create a new public repository on {% data variables.location.product_location %}. You can choose any repository name, or use the following `hello-world-composite-action` example. You can add these files after your project has been pushed to {% data variables.product.product_name %}. For more information, see "[Create a new repository](/articles/creating-a-new-repository)."
|
||||
1. Créez un nouveau référentiel public dans {% data variables.location.product_location %}. Vous pouvez choisir n’importe quel nom de dépôt ou utiliser l’exemple `hello-world-composite-action` suivant. Vous pouvez ajouter ces fichiers une fois que votre projet a été poussé vers {% data variables.product.product_name %}. Pour en savoir plus, consultez « [Créer un dépôt](/articles/creating-a-new-repository) ».
|
||||
|
||||
1. Clone your repository to your computer. For more information, see "[Cloning a repository](/articles/cloning-a-repository)."
|
||||
1. Clonez votre dépôt sur votre ordinateur. Pour plus d’informations, consultez « [Clonage d’un dépôt](/articles/cloning-a-repository) ».
|
||||
|
||||
1. From your terminal, change directories into your new repository.
|
||||
1. À partir de votre terminal, remplacez les répertoires par votre nouveau dépôt.
|
||||
|
||||
```shell
|
||||
cd hello-world-composite-action
|
||||
```
|
||||
|
||||
2. In the `hello-world-composite-action` repository, create a new file called `goodbye.sh`, and add the following example code:
|
||||
2. Dans le dépôt `hello-world-composite-action`, créez un fichier nommé `goodbye.sh`et ajoutez l’exemple de code suivant :
|
||||
|
||||
```bash
|
||||
echo "Goodbye"
|
||||
```
|
||||
|
||||
3. From your terminal, make `goodbye.sh` executable.
|
||||
3. À partir de votre terminal, rendez `goodbye.sh` exécutable.
|
||||
|
||||
```shell
|
||||
chmod +x goodbye.sh
|
||||
```
|
||||
|
||||
1. From your terminal, check in your `goodbye.sh` file.
|
||||
1. À partir de votre terminal, effectuez le check-in de votre fichier `goodbye.sh`.
|
||||
```shell
|
||||
git add goodbye.sh
|
||||
git commit -m "Add goodbye script"
|
||||
git push
|
||||
```
|
||||
|
||||
## Creating an action metadata file
|
||||
## Création d’un fichier de métadonnées d’action
|
||||
|
||||
1. In the `hello-world-composite-action` repository, create a new file called `action.yml` and add the following example code. For more information about this syntax, see "[`runs` for a composite actions](/actions/creating-actions/metadata-syntax-for-github-actions#runs-for-composite-actions)".
|
||||
1. Dans le dépôt `hello-world-composite-action`, créez un fichier nommé `action.yml` et ajoutez l’exemple de code suivant. Pour plus d’informations sur cette syntaxe, consultez « [`runs` pour les actions composites](/actions/creating-actions/metadata-syntax-for-github-actions#runs-for-composite-actions) ».
|
||||
|
||||
{% raw %}
|
||||
**action.yml**
|
||||
{% raw %} **action.yml**
|
||||
```yaml
|
||||
name: 'Hello World'
|
||||
description: 'Greet someone'
|
||||
|
@ -93,14 +96,13 @@ Before you begin, you'll create a repository on {% ifversion ghae %}{% data vari
|
|||
- run: goodbye.sh
|
||||
shell: bash
|
||||
```
|
||||
{% endraw %}
|
||||
This file defines the `who-to-greet` input, maps the random generated number to the `random-number` output variable, adds the action's path to the runner system path (to locate the `goodbye.sh` script during execution), and runs the `goodbye.sh` script.
|
||||
{% endraw %} Ce fichier définit l’entrée `who-to-greet`, mappe le nombre généré aléatoirement à la variable de sortie `random-number`, ajoute le chemin d’accès de l’action au chemin du système de l’exécuteur (pour localiser le script `goodbye.sh` pendant l’exécution ) et exécute le script `goodbye.sh`.
|
||||
|
||||
For more information about managing outputs, see "[`outputs` for a composite action](/actions/creating-actions/metadata-syntax-for-github-actions#outputs-for-composite-actions)".
|
||||
Pour plus d’informations sur la gestion des sorties, consultez « [`outputs` pour une action composite](/actions/creating-actions/metadata-syntax-for-github-actions#outputs-for-composite-actions) ».
|
||||
|
||||
For more information about how to use `github.action_path`, see "[`github context`](/actions/reference/context-and-expression-syntax-for-github-actions#github-context)".
|
||||
Pour plus d’informations sur l’utilisation de `github.action_path`, consultez « [`github context`](/actions/reference/context-and-expression-syntax-for-github-actions#github-context) ».
|
||||
|
||||
1. From your terminal, check in your `action.yml` file.
|
||||
1. À partir de votre terminal, effectuez le check-in de votre fichier `action.yml`.
|
||||
|
||||
```shell
|
||||
git add action.yml
|
||||
|
@ -108,18 +110,18 @@ Before you begin, you'll create a repository on {% ifversion ghae %}{% data vari
|
|||
git push
|
||||
```
|
||||
|
||||
1. From your terminal, add a tag. This example uses a tag called `v1`. For more information, see "[About actions](/actions/creating-actions/about-actions#using-release-management-for-actions)."
|
||||
1. À partir de votre terminal, ajoutez une étiquette. Cet exemple utilise une étiquette nommée `v1`. Pour plus d’informations, consultez « [À propos des actions](/actions/creating-actions/about-actions#using-release-management-for-actions) ».
|
||||
|
||||
```shell
|
||||
git tag -a -m "Description of this release" v1
|
||||
git push --follow-tags
|
||||
```
|
||||
|
||||
## Testing out your action in a workflow
|
||||
## Tester votre action dans un workflow
|
||||
|
||||
The following workflow code uses the completed hello world action that you made in "[Creating an action metadata file](/actions/creating-actions/creating-a-composite-action#creating-an-action-metadata-file)".
|
||||
Le code de workflow suivant utilise l’action Hello World achevée que vous avez effectuée dans « [Création d’un fichier de métadonnées d’action](/actions/creating-actions/creating-a-composite-action#creating-an-action-metadata-file) ».
|
||||
|
||||
Copy the workflow code into a `.github/workflows/main.yml` file in another repository, but replace `actions/hello-world-composite-action@v1` with the repository and tag you created. You can also replace the `who-to-greet` input with your name.
|
||||
Copiez le code de workflow dans un fichier `.github/workflows/main.yml` d’un autre dépôt, mais remplacez `actions/hello-world-composite-action@v1` par le dépôt et l’étiquette que vous avez créés. Vous pouvez également remplacer l’entrée `who-to-greet` par votre nom.
|
||||
|
||||
**.github/workflows/main.yml**
|
||||
```yaml
|
||||
|
@ -139,4 +141,4 @@ jobs:
|
|||
shell: bash
|
||||
```
|
||||
|
||||
From your repository, click the **Actions** tab, and select the latest workflow run. The output should include: "Hello Mona the Octocat", the result of the "Goodbye" script, and a random number.
|
||||
Dans votre dépôt, cliquez sur l’onglet **Actions**, puis sélectionnez la dernière exécution du workflow. La sortie doit inclure : « Hello Mona the Octocat », le résultat de l’exécution du script « Goodbye » et un nombre aléatoire.
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: À propos du renforcement de la sécurité avec OpenID Connect
|
||||
shortTitle: About security hardening with OpenID Connect
|
||||
shortTitle: Security hardening with OpenID Connect
|
||||
intro: OpenID Connect permet à vos workflows d’échanger des jetons de courte durée directement à partir de votre fournisseur de cloud.
|
||||
miniTocMaxHeadingLevel: 4
|
||||
versions:
|
||||
|
@ -10,12 +10,12 @@ versions:
|
|||
type: tutorial
|
||||
topics:
|
||||
- Security
|
||||
ms.openlocfilehash: 23c541fa3c99b706877fc29c52174c404d5fca3d
|
||||
ms.sourcegitcommit: 47bd0e48c7dba1dde49baff60bc1eddc91ab10c5
|
||||
ms.openlocfilehash: 90a2f8c6cb2114f060bfbd0f422cb1ef6dbca604
|
||||
ms.sourcegitcommit: 4f08a208a0d2e13dc109678750a962ea2f67e1ba
|
||||
ms.translationtype: HT
|
||||
ms.contentlocale: fr-FR
|
||||
ms.lasthandoff: 09/05/2022
|
||||
ms.locfileid: '147710266'
|
||||
ms.lasthandoff: 12/06/2022
|
||||
ms.locfileid: '148192030'
|
||||
---
|
||||
{% data reusables.actions.enterprise-beta %} {% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
|
@ -76,7 +76,7 @@ L’exemple de jeton OIDC suivant utilise un sujet (`sub`) qui référence un en
|
|||
"repository": "octo-org/octo-repo",
|
||||
"repository_owner": "octo-org",
|
||||
"actor_id": "12",
|
||||
"repo_visibility": private,
|
||||
"repository_visibility": private,
|
||||
"repository_id": "74",
|
||||
"repository_owner_id": "65",
|
||||
"run_id": "example-run-id",
|
||||
|
@ -131,7 +131,7 @@ Le jeton inclut également des revendications personnalisées fournies par {% da
|
|||
| `job_workflow_ref`| Il s’agit du chemin de référence jusqu’au workflow réutilisable utilisé par ce travail. Pour plus d’informations, consultez « [Utilisation d’OpenID Connect avec des workflows réutilisables](/actions/deployment/security-hardening-your-deployments/using-openid-connect-with-reusable-workflows) ». |
|
||||
| `ref`| _(Référence)_ Référence git qui a déclenché l’exécution du workflow. |
|
||||
| `ref_type`| Type de `ref`, par exemple : « branche ». |
|
||||
| `repo_visibility` | Visibilité du dépôt dans lequel le workflow s’exécute. Accepte les valeurs suivantes : `internal`, `private` et`public`. |
|
||||
| `repository_visibility` | Visibilité du dépôt dans lequel le workflow s’exécute. Accepte les valeurs suivantes : `internal`, `private` et`public`. |
|
||||
| `repository`| Dépôt à partir duquel le workflow s’exécute. |
|
||||
| `repository_id`| ID du dépôt à partir duquel le workflow s’exécute. |
|
||||
| `repository_owner`| Nom de l’organisation dans laquelle `repository` est stocké. |
|
||||
|
@ -249,7 +249,7 @@ Vous pouvez durcir la sécurité de votre configuration OIDC en personnalisant
|
|||
|
||||
{% ifversion ghec %} : pour une couche de sécurité supplémentaire, vous pouvez ajouter l’URL `issuer` au slug de votre entreprise. Cela vous permet de définir des conditions pour la revendication de l’émetteur (`iss`), en la configurant pour accepter uniquement les jetons JWT provenant d’une URL unique `issuer` qui doit inclure le slug de votre entreprise.{% endif %}
|
||||
- Vous pouvez normaliser votre configuration OIDC en définissant des conditions pour la revendication de l’objet (`sub`) qui exigent des jetons JWT provenant d’un dépôt spécifique, d’un workflow réutilisable ou d’une autre source.
|
||||
- Vous pouvez définir des stratégies OIDC précises à l’aide de revendications de jeton OIDC supplémentaires, comme `repository_id` et `repo_visibility`. Pour plus d’informations, consultez « [Présentation du jeton OIDC](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#understanding-the-oidc-token) ».
|
||||
- Vous pouvez définir des stratégies OIDC précises à l’aide de revendications de jeton OIDC supplémentaires, comme `repository_id` et `repository_visibility`. Pour plus d’informations, consultez « [Présentation du jeton OIDC](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#understanding-the-oidc-token) ».
|
||||
|
||||
Pour personnaliser ces formats de revendication, les administrateurs d’organisation et de dépôt peuvent utiliser les points de terminaison de l’API REST qui sont décrits dans les sections suivantes.
|
||||
|
||||
|
@ -259,7 +259,7 @@ Pour personnaliser ces formats de revendication, les administrateurs d’organis
|
|||
|
||||
Par défaut, le jeton JWT est émis par le fournisseur OIDC de {% data variables.product.prodname_dotcom %} sur `https://token.actions.githubusercontent.com`. Ce chemin est présenté à votre fournisseur de cloud à l’aide de la valeur `iss` du jeton JWT.
|
||||
|
||||
Les administrateurs d’entreprise peuvent renforcer leur configuration OIDC en configurant leur entreprise de manière à recevoir des jetons provenant d’une URL unique à l’adresse `https://api.github.com/enterprises/<enterpriseSlug>/actions/oidc/customization/issuer`. Remplacez `<enterpriseSlug>` par la valeur slug de votre entreprise.
|
||||
Les administrateurs d’entreprise peuvent renforcer leur configuration OIDC en configurant leur entreprise de manière à recevoir des jetons provenant d’une URL unique à l’adresse `https://token.actions.githubusercontent.com/<enterpriseSlug>`. Remplacez `<enterpriseSlug>` par la valeur slug de votre entreprise.
|
||||
|
||||
Cette configuration signifie que votre entreprise recevra le jeton OIDC provenant d’une URL unique. Vous pourrez ensuite configurer votre fournisseur de cloud pour qu’il accepte uniquement les jetons provenant de cette URL. Cela garantit que seuls les dépôts de l’entreprise pourront accéder à vos ressources cloud à l’aide d’OIDC.
|
||||
|
||||
|
@ -273,7 +273,7 @@ Une fois ce paramètre appliqué, le jeton JWT contient la valeur `iss` mise à
|
|||
"sub": "repo:octocat-inc/private-server:ref:refs/heads/main"
|
||||
"aud": "http://octocat-inc.example/octocat-inc"
|
||||
"enterprise": "octocat-inc"
|
||||
"iss": "https://api.github.com/enterprises/octocat-inc/actions/oidc/customization/issuer",
|
||||
"iss": "https://token.actions.githubusercontent.com/octocat-inc",
|
||||
"bf": 1755350653,
|
||||
"exp": 1755351553,
|
||||
"iat": 1755351253
|
||||
|
@ -282,22 +282,24 @@ Une fois ce paramètre appliqué, le jeton JWT contient la valeur `iss` mise à
|
|||
|
||||
{% endif %}
|
||||
|
||||
### Personnalisation des revendications d’objet pour une organisation
|
||||
### Personnalisation des revendications d’objet pour une organisation ou un référentiel
|
||||
|
||||
Pour configurer la sécurité, la conformité et la normalisation à l’échelle de l’organisation, vous pouvez personnaliser les revendications standard en fonction des conditions d’accès exigées. Si votre fournisseur de cloud prend en charge l’application de conditions aux revendications d’objet, vous pouvez créer une condition qui vérifie si la valeur `sub` correspond au chemin du workflow réutilisable, par exemple `"job_workflow_ref: "octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main""`. Le format exact varie en fonction de la configuration OIDC de votre fournisseur de cloud. Pour configurer la condition de correspondance de {% data variables.product.prodname_dotcom %}, vous pouvez utiliser l’API REST pour exiger que la revendication `sub` comprenne toujours une revendication personnalisée spécifique, telle que `job_workflow_ref`. Pour plus d’informations, consultez « [Définir le modèle de personnalisation d’une revendication d’objet OIDC dans une organisation](/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-an-organization) ».
|
||||
|
||||
La personnalisation des revendications applique un nouveau format pour l’intégralité de la revendication `sub`, qui remplace le format prédéfini `sub` par défaut dans le jeton décrit dans « [Exemples de revendications d’objet](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#example-subject-claims) ».
|
||||
|
||||
Les exemples de modèles suivants illustrent différentes façons de personnaliser la revendication d’objet. Pour configurer ces paramètres dans {% data variables.product.prodname_dotcom %}, les administrateurs de l’organisation utilisent l’API REST pour spécifier la liste des revendications qui doivent être incluses dans la revendication d’objet (`sub`). {% data reusables.actions.use-request-body-api %}
|
||||
|
||||
Pour personnaliser vos revendications d’objet, vous devez d’abord créer une condition correspondante dans la configuration OIDC de votre fournisseur de cloud, avant de personnaliser la configuration à l’aide de l’API REST. Une fois la configuration terminée, chaque fois qu’un nouveau travail s’exécute, le jeton OIDC généré pendant ce travail suit le nouveau modèle de personnalisation. Si la condition de correspondance n’existe pas dans la configuration OIDC du fournisseur de cloud avant l’exécution du travail, le jeton généré risque de ne pas être accepté par le fournisseur de cloud, car les conditions cloud peuvent ne pas être synchronisées.
|
||||
Pour aider à améliorer la sécurité, la conformité et la normalisation, vous pouvez personnaliser les revendications standard en fonction des conditions d’accès exigées. Si votre fournisseur de cloud prend en charge l’application de conditions aux revendications d’objet, vous pouvez créer une condition qui vérifie si la valeur `sub` correspond au chemin du workflow réutilisable, par exemple `"job_workflow_ref: "octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main""`. Le format exact varie en fonction de la configuration OIDC de votre fournisseur de cloud. Pour configurer la condition de correspondance de {% data variables.product.prodname_dotcom %}, vous pouvez utiliser l’API REST pour exiger que la revendication `sub` comprenne toujours une revendication personnalisée spécifique, telle que `job_workflow_ref`. Vous pouvez utiliser [API REST OIDC](/rest/actions/oidc) pour appliquer un modèle de personnalisation à la revendication d’objet OIDC ; par exemple, vous pouvez exiger que la revendication `sub` dans le jeton OIDC inclue toujours une revendication personnalisée spécifique, telle que `job_workflow_ref`.
|
||||
|
||||
{% note %}
|
||||
|
||||
**Remarque** : Lorsque le modèle d’organisation est appliqué, il n’affecte pas les dépôts existants qui utilisent déjà OIDC. Pour les dépôts existants, ainsi que pour les nouveaux dépôts créés après l’application du modèle, les propriétaires des dépôts devront accepter de recevoir cette configuration. Pour plus d’informations, consultez « [Définir l’indicateur d’acceptation d’une personnalisation de revendication d’objet OIDC pour un dépôt](/rest/actions/oidc#set-the-opt-in-flag-of-an-oidc-subject-claim-customization-for-a-repository) ».
|
||||
**Remarque** : lorsque le modèle d’organisation est appliqué, il n’affecte pas les référentiels existants qui utilisent déjà OIDC. Pour les référentiels existants, ainsi que pour les nouveaux référentiels créés après l’application du modèle, les propriétaires des référentiels devront accepter de recevoir cette configuration ou ils peuvent demander une configuration différente spécifique au référentiel. Pour plus d’informations, consultez « [Définir le modèle de personnalisation d’une revendication d’objet OIDC dans un référentiel](/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-a-repository) ».
|
||||
|
||||
{% endnote %}
|
||||
|
||||
La personnalisation des revendications applique un nouveau format pour l’intégralité de la revendication `sub`, qui remplace le format prédéfini `sub` par défaut dans le jeton décrit dans « [Exemples de revendications d’objet](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#example-subject-claims) ».
|
||||
|
||||
Les exemples de modèles suivants illustrent différentes façons de personnaliser la revendication d’objet. Pour configurer ces paramètres dans {% data variables.product.prodname_dotcom %}, les administrateurs utilisent l’API REST pour spécifier la liste des revendications qui doivent être incluses dans la revendication d’objet (`sub`).
|
||||
|
||||
{% data reusables.actions.use-request-body-api %}
|
||||
|
||||
Pour personnaliser vos revendications d’objet, vous devez d’abord créer une condition correspondante dans la configuration OIDC de votre fournisseur de cloud, avant de personnaliser la configuration à l’aide de l’API REST. Une fois la configuration terminée, chaque fois qu’un nouveau travail s’exécute, le jeton OIDC généré pendant ce travail suit le nouveau modèle de personnalisation. Si la condition de correspondance n’existe pas dans la configuration OIDC du fournisseur de cloud avant l’exécution du travail, le jeton généré risque de ne pas être accepté par le fournisseur de cloud, car les conditions cloud peuvent ne pas être synchronisées.
|
||||
|
||||
#### Exemple : Autorisation d’un dépôt en fonction de la visibilité et du propriétaire
|
||||
|
||||
Cet exemple de modèle permet à la revendication `sub` d’avoir un nouveau format, en utilisant `repository_owner` et `repository_visibility` :
|
||||
|
@ -315,7 +317,9 @@ Dans la configuration OIDC de votre fournisseur de cloud, configurez la conditi
|
|||
|
||||
#### Exemple : Autorisation de l’accès à tous les dépôts d’un propriétaire donné
|
||||
|
||||
Cet exemple de modèle permet à la revendication `sub` d’avoir un nouveau format avec uniquement la valeur `repository_owner`. {% data reusables.actions.use-request-body-api %}
|
||||
Cet exemple de modèle permet à la revendication `sub` d’avoir un nouveau format avec uniquement la valeur `repository_owner`.
|
||||
|
||||
{% data reusables.actions.use-request-body-api %}
|
||||
|
||||
```json
|
||||
{
|
||||
|
@ -346,7 +350,9 @@ Dans la configuration OIDC de votre fournisseur de cloud, configurez la conditi
|
|||
|
||||
#### Exemple : Exiger un workflow réutilisable et d’autres revendications
|
||||
|
||||
L’exemple de modèle suivant combine l’exigence d’un workflow réutilisable spécifique avec des revendications supplémentaires. {% data reusables.actions.use-request-body-api %}
|
||||
L’exemple de modèle suivant combine l’exigence d’un workflow réutilisable spécifique avec des revendications supplémentaires.
|
||||
|
||||
{% data reusables.actions.use-request-body-api %}
|
||||
|
||||
Cet exemple montre également comment utiliser `"context"` pour définir vos conditions. Il s’agit de la partie qui suit le dépôt au [format `sub` par défaut](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#example-subject-claims). Par exemple, lorsque le travail fait référence à un environnement, le contexte contient : `environment:<environmentName>`.
|
||||
|
||||
|
@ -382,7 +388,9 @@ Dans la configuration OIDC de votre fournisseur de cloud, configurez la conditi
|
|||
|
||||
#### Exemple : Utilisation de GUID générés par le système
|
||||
|
||||
Cet exemple de modèle autorise les revendications OIDC prévisibles avec des GUID générés par le système qui ne changent pas entre les renommages d’entités (par exemple, le renommage d’un dépôt). {% data reusables.actions.use-request-body-api %}
|
||||
Cet exemple de modèle autorise les revendications OIDC prévisibles avec des GUID générés par le système qui ne changent pas entre les renommages d’entités (par exemple, le renommage d’un dépôt).
|
||||
|
||||
{% data reusables.actions.use-request-body-api %}
|
||||
|
||||
```json
|
||||
{
|
||||
|
@ -408,7 +416,9 @@ Dans la configuration OIDC de votre fournisseur de cloud, configurez la conditi
|
|||
|
||||
#### Réinitialisation de vos personnalisations
|
||||
|
||||
Cet exemple de modèle réinitialise le format des revendications d’objet vers celui par défaut. {% data reusables.actions.use-request-body-api %} Ce modèle désactive toute stratégie de personnalisation appliquée au niveau de l’organisation.
|
||||
Cet exemple de modèle réinitialise le format des revendications d’objet vers celui par défaut. Ce modèle refuse toute stratégie de personnalisation appliquée au niveau de l’organisation.
|
||||
|
||||
{% data reusables.actions.use-request-body-api %}
|
||||
|
||||
```json
|
||||
{
|
||||
|
@ -423,7 +433,9 @@ Dans la configuration OIDC de votre fournisseur de cloud, configurez la conditi
|
|||
|
||||
#### Utilisation des revendications d’objet par défaut
|
||||
|
||||
Pour les dépôts qui peuvent recevoir une stratégie de revendication d’objet de la part de leur organisation, le propriétaire des dépôts peut choisir plus tard d’utiliser plutôt le format de revendication par défaut `sub`. Pour configurer cela, l’administrateur du dépôt doit utiliser le point de terminaison de l’API REST mentionné dans « [Définir l’indicateur de refus d’une personnalisation de revendication d’objet OIDC pour un dépôt](/rest/actions/oidc#set-the-opt-out-flag-of-an-oidc-subject-claim-customization-for-a-repository) », avec le corps de demande suivant :
|
||||
Pour les dépôts qui peuvent recevoir une stratégie de revendication d’objet de la part de leur organisation, le propriétaire des dépôts peut choisir plus tard d’utiliser plutôt le format de revendication par défaut `sub`. Cela signifie que le référentiel n’utilisera pas le modèle personnalisé de l’organisation.
|
||||
|
||||
Pour configurer le référentiel afin qu’il utilise le format de revendication par défaut `sub`, un administrateur de référentiel doit utiliser le point de terminaison de l’API REST sur « [Définir le modèle de personnalisation d’une revendication d’objet OIDC pour un référentiel](/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-a-repository) » avec le corps de la requête suivant :
|
||||
|
||||
```json
|
||||
{
|
||||
|
@ -431,6 +443,18 @@ Pour les dépôts qui peuvent recevoir une stratégie de revendication d’objet
|
|||
}
|
||||
```
|
||||
|
||||
#### Exemple : Configuration d’un référentiel pour utiliser un modèle d’organisation
|
||||
|
||||
Un administrateur de référentiel peut configurer son référentiel pour utiliser le modèle créé par l’administrateur de son organisation.
|
||||
|
||||
Pour configurer le référentiel afin qu’il utilise le modèle de l’organisation, un administrateur de référentiel doit utiliser le point de terminaison de l’API REST sur « [Définir le modèle de personnalisation d’une revendication d’objet OIDC pour un référentiel](/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-a-repository) » avec le corps de la requête suivant :
|
||||
|
||||
```json
|
||||
{
|
||||
"use_default": false
|
||||
}
|
||||
```
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Mise à jour de vos workflows pour OIDC
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Lancement d’un basculement vers votre appliance réplica
|
||||
intro: 'Vous pouvez basculer vers une appliance réplica {% data variables.product.prodname_ghe_server %} à l’aide de la ligne de commande pour la maintenance et les tests, ou en cas de défaillance de l’appliance primaire.'
|
||||
title: Initiating a failover to your replica appliance
|
||||
intro: 'You can failover to a {% data variables.product.prodname_ghe_server %} replica appliance using the command line for maintenance and testing, or if the primary appliance fails.'
|
||||
redirect_from:
|
||||
- /enterprise/admin/installation/initiating-a-failover-to-your-replica-appliance
|
||||
- /enterprise/admin/enterprise-management/initiating-a-failover-to-your-replica-appliance
|
||||
|
@ -13,59 +13,60 @@ topics:
|
|||
- High availability
|
||||
- Infrastructure
|
||||
shortTitle: Initiate failover to appliance
|
||||
ms.openlocfilehash: d1e9c579d431e03154040392a2b58405fef8ab42
|
||||
ms.sourcegitcommit: 47bd0e48c7dba1dde49baff60bc1eddc91ab10c5
|
||||
ms.translationtype: HT
|
||||
ms.contentlocale: fr-FR
|
||||
ms.lasthandoff: 09/05/2022
|
||||
ms.locfileid: '147770888'
|
||||
---
|
||||
La durée du basculement dépend du temps nécessaire pour promouvoir manuellement le réplica et rediriger le trafic. La durée moyenne varie entre 20 et 30 minutes.
|
||||
The time required to failover depends on how long it takes to manually promote the replica and redirect traffic. The average time ranges between 20-30 minutes.
|
||||
|
||||
{% data reusables.enterprise_installation.promoting-a-replica %}
|
||||
|
||||
1. Si l’appliance principale est disponible, pour permettre à la réplication d’aboutir avant le changement d’appliance, sur l’appliance principale, faites passer celle-ci en mode maintenance.
|
||||
1. If the primary appliance is available, to allow replication to finish before you switch appliances, on the primary appliance, put the primary appliance into maintenance mode.
|
||||
|
||||
- Faites passer l’appliance en mode maintenance.
|
||||
- Put the appliance into maintenance mode.
|
||||
|
||||
- Pour utiliser la console de gestion, consultez « [Activation et planification du mode maintenance](/enterprise/admin/guides/installation/enabling-and-scheduling-maintenance-mode/) »
|
||||
- To use the management console, see "[Enabling and scheduling maintenance mode](/enterprise/admin/guides/installation/enabling-and-scheduling-maintenance-mode/)"
|
||||
|
||||
- Vous pouvez également utiliser la commande `ghe-maintenance -s`.
|
||||
- You can also use the `ghe-maintenance -s` command.
|
||||
```shell
|
||||
$ ghe-maintenance -s
|
||||
```
|
||||
|
||||
- Une fois que le nombre d’opérations Git, de requêtes MySQL et de travaux Resque actifs a atteint zéro, patientez 30 secondes.
|
||||
- When the number of active Git operations, MySQL queries, and Resque jobs reaches zero, wait 30 seconds.
|
||||
|
||||
{% note %}
|
||||
|
||||
**Remarque :** Vous trouverez toujours des travaux Nomad en cours d’exécution, même en mode maintenance. Vous pouvez donc les ignorer sans risque.
|
||||
**Note:** Nomad will always have jobs running, even in maintenance mode, so you can safely ignore these jobs.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
- Pour vérifier que tous les canaux de réplication indique `OK`, utilisez la commande `ghe-repl-status -vv`.
|
||||
- To verify all replication channels report `OK`, use the `ghe-repl-status -vv` command.
|
||||
|
||||
```shell
|
||||
$ ghe-repl-status -vv
|
||||
```
|
||||
|
||||
4. Sur l’appliance réplica, pour arrêter la réplication et promouvoir l’appliance réplica à l’état principal, utilisez la commande `ghe-repl-promote`. Celle-ci fera aussi passer automatiquement le nœud principal en mode maintenance s’il est accessible.
|
||||
4. On the replica appliance, to stop replication and promote the replica appliance to primary status, use the `ghe-repl-promote` command. This will also automatically put the primary node in maintenance mode if it’s reachable.
|
||||
```shell
|
||||
$ ghe-repl-promote
|
||||
```
|
||||
5. Mettez à jour l’enregistrement DNS pour le faire pointer vers l’adresse IP du réplica. Le trafic est dirigé vers le réplica une fois la période TTL écoulée. Si vous utilisez un équilibreur de charge, vérifiez qu’il est configuré pour envoyer le trafic au réplica.
|
||||
6. Informez les utilisateurs qu’ils peuvent reprendre le cours normal des opérations.
|
||||
7. Si vous le souhaitez, configurez la réplication de l’appliance principale vers des appliances existantes et la précédente appliance principale. Pour plus d’informations, consultez « [À propos de la configuration à haute disponibilité](/enterprise/admin/guides/installation/about-high-availability-configuration/#utilities-for-replication-management) ».
|
||||
8. Les appliances que vous n’avez pas l’intention de configurer pour la réplication et qui faisaient partie de la configuration à haute disponibilité avant le basculement, doivent être retirées de la configuration à haute disponibilité par UUID.
|
||||
- Sur les anciennes appliances, obtenez leur UUID via `cat /data/user/common/uuid`.
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** If the primary node is unavailable, warnings and timeouts may occur but can be ignored.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
5. Update the DNS record to point to the IP address of the replica. Traffic is directed to the replica after the TTL period elapses. If you are using a load balancer, ensure it is configured to send traffic to the replica.
|
||||
6. Notify users that they can resume normal operations.
|
||||
7. If desired, set up replication from the new primary to existing appliances and the previous primary. For more information, see "[About high availability configuration](/enterprise/admin/guides/installation/about-high-availability-configuration/#utilities-for-replication-management)."
|
||||
8. Appliances you do not intend to setup replication to that were part of the high availability configuration prior the failover, need to be removed from the high availability configuration by UUID.
|
||||
- On the former appliances, get their UUID via `cat /data/user/common/uuid`.
|
||||
```shell
|
||||
$ cat /data/user/common/uuid
|
||||
```
|
||||
- Sur la nouvelle appliance principale, supprimez les UUID à l’aide de `ghe-repl-teardown`. Remplacez *`UUID`* par un UUID que vous avez récupéré à l’étape précédente.
|
||||
- On the new primary, remove the UUIDs using `ghe-repl-teardown`. Please replace *`UUID`* with a UUID you retrieved in the previous step.
|
||||
```shell
|
||||
$ ghe-repl-teardown -u <em>UUID</em>
|
||||
$ ghe-repl-teardown -u UUID
|
||||
```
|
||||
|
||||
## Pour aller plus loin
|
||||
## Further reading
|
||||
|
||||
- « [Utilitaires pour la gestion de la réplication](/enterprise/admin/guides/installation/about-high-availability-configuration/#utilities-for-replication-management) »
|
||||
- "[Utilities for replication management](/enterprise/admin/guides/installation/about-high-availability-configuration/#utilities-for-replication-management)"
|
||||
|
|
|
@ -117,11 +117,11 @@ For more information about the audit log REST API, see "[Enterprise administrati
|
|||
|
||||
### Example 1: All events in an enterprise, for a specific date, with pagination
|
||||
|
||||
You can use page-based pagination or cursor based pagination. For more information, see "[Traversing with Pagination](/rest/guides/traversing-with-pagination)."
|
||||
You can use page-based pagination or cursor based pagination. For more information about pagination, see "[Using pagination in the REST API](/rest/guides/using-pagination-in-the-rest-api)."
|
||||
|
||||
#### Example with page-based pagination
|
||||
|
||||
The query below searches for audit log events created on Jan 1st, 2022 in the `avocado-corp` enterprise, and return the first page with a maximum of 100 items per page using [REST API pagination](/rest/overview/resources-in-the-rest-api#pagination):
|
||||
The query below searches for audit log events created on Jan 1st, 2022 in the `avocado-corp` enterprise, and return the first page with a maximum of 100 items per page using pagination. For more information about pagination, see "[Using pagination in the REST API](/rest/guides/using-pagination-in-the-rest-api)."
|
||||
|
||||
```shell
|
||||
curl -H "Authorization: Bearer TOKEN" \
|
||||
|
@ -131,7 +131,7 @@ curl -H "Authorization: Bearer TOKEN" \
|
|||
|
||||
#### Example with cursor-based pagination
|
||||
|
||||
The query below searches for audit log events created on Jan 1st, 2022 in the `avocado-corp` enterprise, and returns the first page with a maximum of 100 items per page using [REST API pagination](/rest/overview/resources-in-the-rest-api#pagination). The `--include` flag causes the headers to be returned along with the response.
|
||||
The query below searches for audit log events created on Jan 1st, 2022 in the `avocado-corp` enterprise, and returns the first page with a maximum of 100 items per page using pagination. For more information about pagination, see "[Using pagination in the REST API](/rest/guides/using-pagination-in-the-rest-api)." The `--include` flag causes the headers to be returned along with the response.
|
||||
|
||||
```
|
||||
curl --include -H "Authorization: Bearer TOKEN" \
|
||||
|
|
|
@ -26,7 +26,7 @@ topics:
|
|||
|
||||
If your project communicates with an external service, you might use a token or private key for authentication. Tokens and private keys are examples of secrets that a service provider can issue. If you check a secret into a repository, anyone who has read access to the repository can use the secret to access the external service with your privileges. We recommend that you store secrets in a dedicated, secure location outside of the repository for your project.
|
||||
|
||||
{% data variables.product.prodname_secret_scanning_caps %} will scan your entire Git history on all branches present in your {% data variables.product.prodname_dotcom %} repository for secrets{% ifversion ghec or ghes > 3.4 or ghae > 3.4 %}, even if the repository is archived{% endif %}.
|
||||
{% data variables.product.prodname_secret_scanning_caps %} will scan your entire Git history on all branches present in your {% data variables.product.prodname_dotcom %} repository for secrets{% ifversion ghec or ghes > 3.4 or ghae > 3.4 %}, even if the repository is archived{% endif %}. {% ifversion secret-scanning-issue-body-comments %}{% data reusables.secret-scanning.scan-issue-description-and-comments %}{% endif %}
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
{% data variables.product.prodname_secret_scanning_caps %} is available on {% data variables.product.prodname_dotcom_the_website %} in two forms:
|
||||
|
@ -46,7 +46,7 @@ You can also enable {% data variables.product.prodname_secret_scanning %} as a p
|
|||
{% ifversion fpt or ghec %}
|
||||
## About {% data variables.product.prodname_secret_scanning_partner %}
|
||||
|
||||
When you make a repository public, or push changes to a public repository, {% data variables.product.product_name %} always scans the code for secrets that match partner patterns. If {% data variables.product.prodname_secret_scanning %} detects a potential secret, we notify the service provider who issued the secret. The service provider validates the string and then decides whether they should revoke the secret, issue a new secret, or contact you directly. Their action will depend on the associated risks to you or them. For more information, see "[Supported secrets for partner patterns](/code-security/secret-scanning/secret-scanning-patterns#supported-secrets-for-partner-patterns)."
|
||||
When you make a repository public, or push changes to a public repository, {% data variables.product.product_name %} always scans the code for secrets that match partner patterns. {% ifversion secret-scanning-issue-body-comments %}{% data reusables.secret-scanning.scan-issue-description-and-comments %}{% endif %} If {% data variables.product.prodname_secret_scanning %} detects a potential secret, we notify the service provider who issued the secret. The service provider validates the string and then decides whether they should revoke the secret, issue a new secret, or contact you directly. Their action will depend on the associated risks to you or them. For more information, see "[Supported secrets for partner patterns](/code-security/secret-scanning/secret-scanning-patterns#supported-secrets-for-partner-patterns)."
|
||||
|
||||
You cannot change the configuration of {% data variables.product.prodname_secret_scanning %} on public repositories.
|
||||
|
||||
|
@ -68,7 +68,15 @@ You cannot change the configuration of {% data variables.product.prodname_secret
|
|||
## About {% data variables.product.prodname_secret_scanning %} on {% data variables.product.product_name %}
|
||||
{% endif %}
|
||||
|
||||
{% data variables.product.prodname_secret_scanning_GHAS_caps %} is available on all organization-owned repositories as part of {% data variables.product.prodname_GH_advanced_security %}. It is not available on user-owned repositories. When you enable {% data variables.product.prodname_secret_scanning %} for a repository, {% data variables.product.prodname_dotcom %} scans the code for patterns that match secrets used by many service providers. {% ifversion secret-scanning-backfills %}{% data variables.product.prodname_dotcom %} will also periodically run a full git history scan of existing content in {% data variables.product.prodname_GH_advanced_security %} repositories where {% data variables.product.prodname_secret_scanning %} is enabled, and send alert notifications following the {% data variables.product.prodname_secret_scanning %} alert notification settings. {% endif %}For more information, see "{% ifversion ghec %}[Supported secrets for advanced security](/code-security/secret-scanning/secret-scanning-patterns#supported-secrets-for-advanced-security){% else %}[{% data variables.product.prodname_secret_scanning_caps %} patterns](/code-security/secret-scanning/secret-scanning-patterns){% endif %}."
|
||||
{% data variables.product.prodname_secret_scanning_GHAS_caps %} is available on all organization-owned repositories as part of {% data variables.product.prodname_GH_advanced_security %}. It is not available on user-owned repositories. When you enable {% data variables.product.prodname_secret_scanning %} for a repository, {% data variables.product.prodname_dotcom %} scans the code for patterns that match secrets used by many service providers. {% ifversion secret-scanning-issue-body-comments %}{% data reusables.secret-scanning.scan-issue-description-and-comments %}{% endif %} {% ifversion secret-scanning-backfills %}{% data variables.product.prodname_dotcom %} will also periodically run a full git history scan of existing content in {% data variables.product.prodname_GH_advanced_security %} repositories where {% data variables.product.prodname_secret_scanning %} is enabled, and send alert notifications following the {% data variables.product.prodname_secret_scanning %} alert notification settings. {% endif %}For more information, see "{% ifversion ghec %}[Supported secrets for advanced security](/code-security/secret-scanning/secret-scanning-patterns#supported-secrets-for-advanced-security){% else %}[{% data variables.product.prodname_secret_scanning_caps %} patterns](/code-security/secret-scanning/secret-scanning-patterns){% endif %}."
|
||||
|
||||
{% ifversion secret-scanning-issue-body-comments %}
|
||||
{% note %}
|
||||
|
||||
**Note:** {% data variables.product.prodname_secret_scanning_caps %} for issue descriptions and comments is in public beta and subject to change.
|
||||
|
||||
{% endnote %}
|
||||
{% endif %}
|
||||
|
||||
If you're a repository administrator you can enable {% data variables.product.prodname_secret_scanning_GHAS %} for any repository{% ifversion ghec or ghes > 3.4 or ghae > 3.4 %}, including archived repositories{% endif %}. Organization owners can also enable {% data variables.product.prodname_secret_scanning_GHAS %} for all repositories or for all new repositories within an organization. For more information, see "[Managing security and analysis settings for your repository](/github/administering-a-repository/managing-security-and-analysis-settings-for-your-repository)" and "[Managing security and analysis settings for your organization](/organizations/keeping-your-organization-secure/managing-security-and-analysis-settings-for-your-organization)."
|
||||
|
||||
|
@ -80,7 +88,7 @@ If you're a repository administrator you can enable {% data variables.product.pr
|
|||
|
||||
### About {% data variables.product.prodname_secret_scanning %} alerts
|
||||
|
||||
When you enable {% data variables.product.prodname_secret_scanning %} for a repository or push commits to a repository with {% data variables.product.prodname_secret_scanning %} enabled, {% data variables.product.prodname_dotcom %} scans the contents of those commits for secrets that match patterns defined by service providers{% ifversion ghes or ghae or ghec %} and any custom patterns defined in your enterprise, organization, or repository{% endif %}. {% ifversion secret-scanning-backfills %}{% data variables.product.prodname_dotcom %} also periodically runs a scan of all historical content in repositories with {% data variables.product.prodname_secret_scanning %} enabled.{% endif%}
|
||||
When you enable {% data variables.product.prodname_secret_scanning %} for a repository or push commits to a repository with {% data variables.product.prodname_secret_scanning %} enabled, {% data variables.product.prodname_dotcom %} scans the contents of those commits for secrets that match patterns defined by service providers{% ifversion ghes or ghae or ghec %} and any custom patterns defined in your enterprise, organization, or repository{% endif %}. {% ifversion secret-scanning-issue-body-comments %}{% data reusables.secret-scanning.scan-issue-description-and-comments %}{% endif %} {% ifversion secret-scanning-backfills %}{% data variables.product.prodname_dotcom %} also periodically runs a scan of all historical content in repositories with {% data variables.product.prodname_secret_scanning %} enabled.{% endif%}
|
||||
|
||||
If {% data variables.product.prodname_secret_scanning %} detects a secret, {% data variables.product.prodname_dotcom %} generates an alert.
|
||||
|
||||
|
|
|
@ -24,7 +24,14 @@ shortTitle: Configure secret scans
|
|||
|
||||
## Enabling {% data variables.product.prodname_secret_scanning_GHAS %}
|
||||
|
||||
You can enable {% data variables.product.prodname_secret_scanning_GHAS %} for any repository that is owned by an organization. Once enabled, {% data reusables.secret-scanning.secret-scanning-process %}
|
||||
You can enable {% data variables.product.prodname_secret_scanning_GHAS %} for any repository that is owned by an organization. Once enabled, {% data reusables.secret-scanning.secret-scanning-process %} {% ifversion secret-scanning-issue-body-comments %}{% data reusables.secret-scanning.scan-issue-description-and-comments %}
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** {% data variables.product.prodname_secret_scanning_caps %} for issue descriptions and comments is in public beta and subject to change.
|
||||
|
||||
{% endnote %}
|
||||
{% endif %}
|
||||
|
||||
{% ifversion secret-scanning-enterprise-level %}
|
||||
{% note %}
|
||||
|
@ -37,14 +44,14 @@ You can enable {% data variables.product.prodname_secret_scanning_GHAS %} for an
|
|||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
{% data reusables.repositories.navigate-to-code-security-and-analysis %}
|
||||
4. If {% data variables.product.prodname_advanced_security %} is not already enabled for the repository, to the right of "{% data variables.product.prodname_GH_advanced_security %}", click **Enable**.
|
||||
1. If {% data variables.product.prodname_advanced_security %} is not already enabled for the repository, to the right of "{% data variables.product.prodname_GH_advanced_security %}", click **Enable**.
|
||||
{% ifversion fpt or ghec %}![Enable {% data variables.product.prodname_GH_advanced_security %} for your repository](/assets/images/help/repository/enable-ghas-dotcom.png)
|
||||
{% elsif ghes or ghae %}![Enable {% data variables.product.prodname_GH_advanced_security %} for your repository](/assets/images/enterprise/3.1/help/repository/enable-ghas.png){% endif %}
|
||||
5. Review the impact of enabling {% data variables.product.prodname_advanced_security %}, then click **Enable {% data variables.product.prodname_GH_advanced_security %} for this repository**.
|
||||
6. When you enable {% data variables.product.prodname_advanced_security %}, {% data variables.product.prodname_secret_scanning %} may automatically be enabled for the repository due to the organization's settings. If "{% data variables.product.prodname_secret_scanning_caps %}" is shown with an **Enable** button, you still need to enable {% data variables.product.prodname_secret_scanning %} by clicking **Enable**. If you see a **Disable** button, {% data variables.product.prodname_secret_scanning %} is already enabled.
|
||||
2. Review the impact of enabling {% data variables.product.prodname_advanced_security %}, then click **Enable {% data variables.product.prodname_GH_advanced_security %} for this repository**.
|
||||
3. When you enable {% data variables.product.prodname_advanced_security %}, {% data variables.product.prodname_secret_scanning %} may automatically be enabled for the repository due to the organization's settings. If "{% data variables.product.prodname_secret_scanning_caps %}" is shown with an **Enable** button, you still need to enable {% data variables.product.prodname_secret_scanning %} by clicking **Enable**. If you see a **Disable** button, {% data variables.product.prodname_secret_scanning %} is already enabled.
|
||||
![Enable {% data variables.product.prodname_secret_scanning %} for your repository](/assets/images/help/repository/enable-secret-scanning-dotcom.png)
|
||||
{% ifversion secret-scanning-push-protection %}
|
||||
7. Optionally, if you want to enable push protection, click **Enable** to the right of "Push protection." {% data reusables.secret-scanning.push-protection-overview %} For more information, see "[Protecting pushes with {% data variables.product.prodname_secret_scanning %}](/code-security/secret-scanning/protecting-pushes-with-secret-scanning)."
|
||||
1. Optionally, if you want to enable push protection, click **Enable** to the right of "Push protection." {% data reusables.secret-scanning.push-protection-overview %} For more information, see "[Protecting pushes with {% data variables.product.prodname_secret_scanning %}](/code-security/secret-scanning/protecting-pushes-with-secret-scanning)."
|
||||
![Enable push protection for your repository](/assets/images/help/repository/secret-scanning-enable-push-protection.png)
|
||||
{% endif %}
|
||||
{% ifversion ghae %}
|
||||
|
|
|
@ -31,8 +31,13 @@ After you enable SCIM, the following provisioning features are available for any
|
|||
|
||||
Alternatively, you can configure SAML SSO for an enterprise using Okta. SCIM for enterprise accounts is only available with Enterprise Managed Users. For more information, see "[Configuring SAML single sign-on for your enterprise using Okta](/admin/identity-and-access-management/managing-iam-for-your-enterprise/configuring-saml-single-sign-on-for-your-enterprise-using-okta)" and "[Configuring SCIM provisioning for Enterprise Managed Users with Okta](/admin/identity-and-access-management/managing-iam-with-enterprise-managed-users/configuring-scim-provisioning-for-enterprise-managed-users-with-okta)."
|
||||
|
||||
## Adding the {% data variables.product.prodname_ghe_cloud %} application in Okta
|
||||
## Configuring SAML in Okta
|
||||
|
||||
{% data reusables.saml.okta-ae-applications-menu %}
|
||||
{% data reusables.saml.okta-browse-app-catalog %}
|
||||
{% data reusables.saml.okta-add-ghec-org-integration %}
|
||||
1. Fill out the form, providing the name of your organization on {% data variables.product.prodname_dotcom %} and a unique name for your OAuth App Integration application.
|
||||
{% data reusables.saml.assign-yourself-to-okta %}
|
||||
{% data reusables.saml.okta-sign-on-tab %}
|
||||
{% data reusables.saml.okta-view-setup-instructions %}
|
||||
1. Enable and test SAML SSO on {% data variables.product.prodname_dotcom %} using the sign on URL, issuer URL, and public certificates from the "How to Configure SAML 2.0" guide. For more information, see "[Enabling and testing SAML single sign-on for your organization](/organizations/managing-saml-single-sign-on-for-your-organization/enabling-and-testing-saml-single-sign-on-for-your-organization#enabling-and-testing-saml-single-sign-on-for-your-organization)."
|
||||
|
|
|
@ -18,7 +18,7 @@ children:
|
|||
- /delivering-deployments
|
||||
- /rendering-data-as-graphs
|
||||
- /working-with-comments
|
||||
- /traversing-with-pagination
|
||||
- /using-pagination-in-the-rest-api
|
||||
- /building-a-ci-server
|
||||
- /best-practices-for-integrators
|
||||
- /getting-started-with-the-git-database-api
|
||||
|
|
|
@ -1,350 +0,0 @@
|
|||
---
|
||||
title: Traversing with pagination
|
||||
intro: Explore how to use pagination to manage your responses with some examples using the Search API.
|
||||
redirect_from:
|
||||
- /guides/traversing-with-pagination
|
||||
- /v3/guides/traversing-with-pagination
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- API
|
||||
shortTitle: Traverse with pagination
|
||||
miniTocMaxHeadingLevel: 3
|
||||
---
|
||||
|
||||
The {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API provides a vast wealth of information for developers to consume.
|
||||
Most of the time, you might even find that you're asking for _too much_ information,
|
||||
and in order to keep our servers happy, the API will automatically [paginate the requested items](/rest/overview/resources-in-the-rest-api#pagination).
|
||||
|
||||
In this guide, we'll make some calls to the Search API, and iterate over
|
||||
the results using pagination. You can find the complete source code for this project
|
||||
in the [platform-samples][platform samples] repository.
|
||||
|
||||
{% data reusables.rest-api.dotcom-only-guide-note %}
|
||||
|
||||
|
||||
|
||||
## Basics of Pagination
|
||||
|
||||
To start with, it's important to know a few facts about receiving paginated items:
|
||||
|
||||
|
||||
1. Different API calls respond with different defaults. For example, a call to
|
||||
[List public repositories](/rest/reference/repos#list-public-repositories)
|
||||
provides paginated items in sets of 30, whereas a call to the GitHub Search API
|
||||
provides items in sets of 100
|
||||
2. You can specify how many items to receive (up to a maximum of 100); but,
|
||||
3. For technical reasons, not every endpoint behaves the same. For example,
|
||||
[events](/rest/reference/activity#events) won't let you set a maximum for items to receive.
|
||||
Be sure to read the documentation on how to handle paginated results for specific endpoints.
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note**: You should always rely on URLs included in the link header. Don't try to guess or construct your own URLs.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
|
||||
### Link header
|
||||
|
||||
The response header includes information about pagination. For more information about headers, see "[Getting started with the REST API](/rest/guides/getting-started-with-the-rest-api#about-the-response-code-and-headers)." To get the response header, include the `-I` flag in your request. For example:
|
||||
|
||||
```shell
|
||||
$ curl -I -H "Accept: application/vnd.github+json" -H "Authorization: Bearer YOUR_TOKEN" https://api.github.com/enterprises/advacado-corp/audit-log
|
||||
|
||||
```
|
||||
|
||||
The `-I` flag returns only the response header. If the response is paginated, the response header will include a `link` header. The header will look something like this:
|
||||
|
||||
```
|
||||
link: <https://api.github.com/enterprises/13827/audit-log?after=MS42NjQzODM5MTkzNDdlKzEyfDM0MkI6NDdBNDo4RTFGMEM6NUIyQkZCMzo2MzM0N0JBRg%3D%3D&before=>; rel="next"
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
```
|
||||
link: <https://api.github.com/repositories/1300192/issues?page=2>; rel="next", <https://api.github.com/repositories/1300192/issues?page=511>; rel="last"
|
||||
```
|
||||
### Types of pagination
|
||||
|
||||
{% data variables.product.company_short %}'s API uses two pagination methods: page-based pagination and cursor-based pagination. If the `link` header includes `page`, then the operation uses page-based pagination. If the `link` header includes `before` and `after`, then the operation uses cursor-based pagination.
|
||||
|
||||
|
||||
#### Page based pagination
|
||||
|
||||
The link header for page-based pagination will tell you information about the previous, next, first, and last pages. If you did not request a specific page, then the response will default to the first page and information about the first and previous pages will be omitted.
|
||||
|
||||
For example, for a request that did not specify a page, this header states that the next page is `2` and the last page is `511`.
|
||||
|
||||
```
|
||||
link: <https://api.github.com/repositories/1300192/issues?page=2>; rel="next", <https://api.github.com/repositories/1300192/issues?page=511>; rel="last"
|
||||
```
|
||||
|
||||
For example, for a request that specified page 5, this header states that the previous page is `4`, the next page is `6`, the last page is `511`, and the first page is `1`.
|
||||
|
||||
```
|
||||
link: <https://api.github.com/repositories/1300192/issues?page=4>; rel="prev", <https://api.github.com/repositories/1300192/issues?page=6>; rel="next", <https://api.github.com/repositories/1300192/issues?page=511>; rel="last", <https://api.github.com/repositories/1300192/issues?page=1>; rel="first"
|
||||
```
|
||||
|
||||
#### Cursor based pagination
|
||||
|
||||
Cursor pagination uses terms `before` and `after` in order to navigate through pages. `rel="next"` and `rel="prev"` this mark the cursor point in the data set and provides a reference for traveling to the page `before` and `after` the current page.
|
||||
|
||||
```
|
||||
link: <https://api.github.com/enterprises/13827/audit-log?after=MS42NjQzODMzMzk2MzZlKzEyfFdxSzIxdGU0MlBWNUp5UzhBWDF6LWc%3D&before=>; rel="next",
|
||||
<https://api.github.com/enterprises/13827/audit-log?after=&before=>; rel="first",
|
||||
<https://api.github.com/enterprises/13827/audit-log?after=&before=MS42NjQzODM5MTcyMjllKzEyfDI4NDE6NEVFNDoxODBDRkM5OjY5REE0MzI6NjMzNDdCQUQ%3D>; rel="prev"
|
||||
```
|
||||
|
||||
In this example, `rel=next` says that the next page is located at:
|
||||
|
||||
```
|
||||
after=MS42NjQzODM5MTkzNDdlKzEyfDM0MkI6NDdBNDo4RTFGMEM6NUIyQkZCMzo2MzM0N0JBRg%3D%3D&before=
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
### Using pagination
|
||||
|
||||
#### Cursor based pagination
|
||||
|
||||
Using cursor based pagination requires you to use the terms `before` and `after`. To navigate using `before` and `after`, copy the link header generated above into your curl request:
|
||||
|
||||
```shell
|
||||
$ curl -I -H "Accept: application/vnd.github+json" -H "Authorization: Bearer YOUR_TOKEN" https://api.github.com/enterprises/13827/audit-log?after=MS42NjQzODM5MTkzNDdlKzEyfDM0MkI6NDdBNDo4RTFGMEM6NUIyQkZCMzo2MzM0N0JBRg%3D%3D&before=
|
||||
```
|
||||
|
||||
The above example will generate a page of results and new header information that you can use to make the next request. `rel="next"` provides the next page of results. `rel="prev"` provides the previous page of results. The important part of the output here is the link header needs to be generated rather than manually imputed. Copy the entire link from the following output.
|
||||
|
||||
```
|
||||
link: <https://api.github.com/enterprises/13827/audit-log?after=MS42NjQzODMzMzk2MzZlKzEyfFdxSzIxdGU0MlBWNUp5UzhBWDF6LWc%3D&before=>; rel="next",
|
||||
<https://api.github.com/enterprises/13827/audit-log?after=&before=>; rel="first",
|
||||
<https://api.github.com/enterprises/13827/audit-log?after=&before=MS42NjQzODM5MTcyMjllKzEyfDI4NDE6NEVFNDoxODBDRkM5OjY5REE0MzI6NjMzNDdCQUQ%3D>; rel="prev"
|
||||
```
|
||||
|
||||
Unlike page-based pagination, the results will not return the last page number in the response.
|
||||
|
||||
link: <https://api.github.com/enterprises/13827/audit-log?after=MS42NjQzODMzMzk2MzZlKzEyfFdxSzIxdGU0MlBWNUp5UzhBWDF6LWc%3D&before=>; rel="next",
|
||||
<https://api.github.com/enterprises/13827/audit-log?after=&before=>; rel="first",
|
||||
<https://api.github.com/enterprises/13827/audit-log?after=&before=MS42NjQzODM5MTcyMjllKzEyfDI4NDE6NEVFNDoxODBDRkM5OjY5REE0MzI6NjMzNDdCQUQ%3D>; rel="prev"
|
||||
|
||||
Because cursor based pagination creates a reference point in the data set, it cannot calculate the total number of results.
|
||||
|
||||
|
||||
#### Page based pagination
|
||||
|
||||
To navigate using page based pagination pass in a `page`
|
||||
parameter. By default, `page` always starts at `1`. In the following example, we have made a curl request to the search API Mozilla projects use the phrase `addClass`. Instead of starting at 1, lets jump to page 14.
|
||||
|
||||
```shell
|
||||
$ curl -I "https://api.github.com/search/code?q=addClass+user:mozilla&page=14"
|
||||
```
|
||||
|
||||
Here's an except of the link header in the HTTP request:
|
||||
|
||||
Link: <https://api.github.com/search/code?q=addClass+user%3Amozilla&page=15>; rel="next",
|
||||
<https://api.github.com/search/code?q=addClass+user%3Amozilla&page=34>; rel="last",
|
||||
<https://api.github.com/search/code?q=addClass+user%3Amozilla&page=1>; rel="first",
|
||||
<https://api.github.com/search/code?q=addClass+user%3Amozilla&page=13>; rel="prev"
|
||||
|
||||
In this example, `rel="next"` is at 15, and `rel="last"` is 34. But now we've
|
||||
got some more information: `rel="first"` indicates the URL for the _first_ page,
|
||||
and more importantly, `rel="prev"` lets you know the page number of the previous
|
||||
page. Using this information, you could construct some UI that lets users jump
|
||||
between the first, previous, next, or last list of results in an API call.
|
||||
|
||||
|
||||
### Changing the number of items received
|
||||
|
||||
#### Page based pagination
|
||||
|
||||
By passing the `per_page` parameter, you can specify how many items you want
|
||||
each page to return, up to 100 items. Let's try asking for 50 items about `addClass`:
|
||||
|
||||
```shell
|
||||
$ curl -I "https://api.github.com/search/code?q=addClass+user:mozilla&per_page=50"
|
||||
```
|
||||
|
||||
Notice what it does to the header response:
|
||||
|
||||
Link: <https://api.github.com/search/code?q=addClass+user%3Amozilla&per_page=50&page=2>; rel="next",
|
||||
<https://api.github.com/search/code?q=addClass+user%3Amozilla&per_page=50&page=20>; rel="last"
|
||||
|
||||
As you might have guessed, the `rel="last"` information says that the last page
|
||||
is now 20. This is because we are asking for more information per page about
|
||||
our results.
|
||||
|
||||
#### Cursor based pagination
|
||||
|
||||
You can also pass the `per_page` parameter for cursor-based pagination.
|
||||
|
||||
```shell
|
||||
$ curl -I -H "Accept: application/vnd.github+json" -H "Authorization: Bearer YOUR_TOKEN" https://api.github.com/enterprises/13827/audit-log?after=MS42NjQzODM5MTkzNDdlKzEyfDM0MkI6NDdBNDo4RTFGMEM6NUIyQkZCMzo2MzM0N0JBRg%3D%3D&before=&per_page=50
|
||||
```
|
||||
|
||||
## Consuming the information
|
||||
|
||||
You don't want to be making low-level curl calls just to be able to work with
|
||||
pagination, so let's write a little Ruby script that does everything we've
|
||||
just described above.
|
||||
|
||||
As always, first we'll require [GitHub's Octokit.rb][octokit.rb] Ruby library, and
|
||||
pass in our [{% data variables.product.pat_generic %}][personal token]:
|
||||
|
||||
``` ruby
|
||||
require 'octokit'
|
||||
|
||||
# !!! DO NOT EVER USE HARD-CODED VALUES IN A REAL APP !!!
|
||||
# Instead, set and test environment variables, like below
|
||||
client = Octokit::Client.new :access_token => ENV['MY_PERSONAL_TOKEN']
|
||||
```
|
||||
|
||||
Next, we'll execute the search, using Octokit's `search_code` method. Unlike
|
||||
using `curl`, we can also immediately retrieve the number of results, so let's
|
||||
do that:
|
||||
|
||||
``` ruby
|
||||
results = client.search_code('addClass user:mozilla')
|
||||
total_count = results.total_count
|
||||
```
|
||||
|
||||
Now, let's grab the number of the last page, similar to `page=34>; rel="last"`
|
||||
information in the link header. Octokit.rb support pagination information through
|
||||
an implementation called "[Hypermedia link relations][hypermedia-relations]."
|
||||
We won't go into detail about what that is, but, suffice to say, each element
|
||||
in the `results` variable has a hash called `rels`, which can contain information
|
||||
about `:next`, `:last`, `:first`, and `:prev`, depending on which result you're
|
||||
on. These relations also contain information about the resulting URL, by calling
|
||||
`rels[:last].href`.
|
||||
|
||||
Knowing this, let's grab the page number of the last result, and present all
|
||||
this information to the user:
|
||||
|
||||
``` ruby
|
||||
last_response = client.last_response
|
||||
number_of_pages = last_response.rels[:last].href.match(/page=(\d+).*$/)[1]
|
||||
|
||||
puts "There are #{total_count} results, on #{number_of_pages} pages!"
|
||||
```
|
||||
|
||||
Finally, let's iterate through the results. You could do this with a loop `for i in 1..number_of_pages.to_i`,
|
||||
but instead, let's follow the `rels[:next]` headers to retrieve information from
|
||||
each page. For the sake of simplicity, let's just grab the file path of the first
|
||||
result from each page. To do this, we'll need a loop; and at the end of every loop,
|
||||
we'll retrieve the data set for the next page by following the `rels[:next]` information.
|
||||
The loop will finish when there is no `rels[:next]` information to consume (in other
|
||||
words, we are at `rels[:last]`). It might look something like this:
|
||||
|
||||
``` ruby
|
||||
puts last_response.data.items.first.path
|
||||
until last_response.rels[:next].nil?
|
||||
last_response = last_response.rels[:next].get
|
||||
puts last_response.data.items.first.path
|
||||
end
|
||||
```
|
||||
|
||||
Changing the number of items per page is extremely simple with Octokit.rb. Simply
|
||||
pass a `per_page` options hash to the initial client construction. After that,
|
||||
your code should remain intact:
|
||||
|
||||
``` ruby
|
||||
require 'octokit'
|
||||
|
||||
# !!! DO NOT EVER USE HARD-CODED VALUES IN A REAL APP !!!
|
||||
# Instead, set and test environment variables, like below
|
||||
client = Octokit::Client.new :access_token => ENV['MY_PERSONAL_TOKEN']
|
||||
|
||||
results = client.search_code('addClass user:mozilla', :per_page => 100)
|
||||
total_count = results.total_count
|
||||
|
||||
last_response = client.last_response
|
||||
number_of_pages = last_response.rels[:last].href.match(/page=(\d+).*$/)[1]
|
||||
|
||||
puts last_response.rels[:last].href
|
||||
puts "There are #{total_count} results, on #{number_of_pages} pages!"
|
||||
|
||||
puts "And here's the first path for every set"
|
||||
|
||||
puts last_response.data.items.first.path
|
||||
until last_response.rels[:next].nil?
|
||||
last_response = last_response.rels[:next].get
|
||||
puts last_response.data.items.first.path
|
||||
end
|
||||
```
|
||||
|
||||
## Constructing Pagination Links
|
||||
|
||||
Normally, with pagination, your goal isn't to concatenate all of the possible
|
||||
results, but rather, to produce a set of navigation, like this:
|
||||
|
||||
![Sample of pagination links](/assets/images/pagination_sample.png)
|
||||
|
||||
Let's sketch out a micro-version of what that might entail.
|
||||
|
||||
From the code above, we already know we can get the `number_of_pages` in the
|
||||
paginated results from the first call:
|
||||
|
||||
``` ruby
|
||||
require 'octokit'
|
||||
|
||||
# !!! DO NOT EVER USE HARD-CODED VALUES IN A REAL APP !!!
|
||||
# Instead, set and test environment variables, like below
|
||||
client = Octokit::Client.new :access_token => ENV['MY_PERSONAL_TOKEN']
|
||||
|
||||
results = client.search_code('addClass user:mozilla')
|
||||
total_count = results.total_count
|
||||
|
||||
last_response = client.last_response
|
||||
number_of_pages = last_response.rels[:last].href.match(/page=(\d+).*$/)[1]
|
||||
|
||||
puts last_response.rels[:last].href
|
||||
puts "There are #{total_count} results, on #{number_of_pages} pages!"
|
||||
```
|
||||
|
||||
From there, we can construct a beautiful ASCII representation of the number boxes:
|
||||
``` ruby
|
||||
numbers = ""
|
||||
for i in 1..number_of_pages.to_i
|
||||
numbers << "[#{i}] "
|
||||
end
|
||||
puts numbers
|
||||
```
|
||||
|
||||
Let's simulate a user clicking on one of these boxes, by constructing a random
|
||||
number:
|
||||
|
||||
``` ruby
|
||||
random_page = Random.new
|
||||
random_page = random_page.rand(1..number_of_pages.to_i)
|
||||
|
||||
puts "A User appeared, and clicked number #{random_page}!"
|
||||
```
|
||||
|
||||
Now that we have a page number, we can use Octokit to explicitly retrieve that
|
||||
individual page, by passing the `:page` option:
|
||||
|
||||
``` ruby
|
||||
clicked_results = client.search_code('addClass user:mozilla', :page => random_page)
|
||||
```
|
||||
|
||||
If we wanted to get fancy, we could also grab the previous and next pages, in
|
||||
order to generate links for back (`<<`) and forward (`>>`) elements:
|
||||
|
||||
``` ruby
|
||||
prev_page_href = client.last_response.rels[:prev] ? client.last_response.rels[:prev].href : "(none)"
|
||||
next_page_href = client.last_response.rels[:next] ? client.last_response.rels[:next].href : "(none)"
|
||||
|
||||
puts "The prev page link is #{prev_page_href}"
|
||||
puts "The next page link is #{next_page_href}"
|
||||
```
|
||||
|
||||
[pagination]: /rest#pagination
|
||||
[platform samples]: https://github.com/github/platform-samples/tree/master/api/ruby/traversing-with-pagination
|
||||
[octokit.rb]: https://github.com/octokit/octokit.rb
|
||||
[personal token]: /articles/creating-an-access-token-for-command-line-use
|
||||
[hypermedia-relations]: https://github.com/octokit/octokit.rb#pagination
|
||||
[listing commits]: /rest/reference/commits#list-commits
|
|
@ -10,6 +10,7 @@ featuredLinks:
|
|||
- /rest/guides/getting-started-with-the-rest-api
|
||||
- /rest/guides/basics-of-authentication
|
||||
- /rest/guides/best-practices-for-integrators
|
||||
- /rest/guides/using-pagination-in-the-rest-api
|
||||
popular:
|
||||
- /rest/overview/resources-in-the-rest-api
|
||||
- /rest/overview/api-versions
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Ressources disponibles dans l’API REST
|
||||
intro: 'Découvrez comment parcourir les ressources fournies par l’API {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %}.'
|
||||
title: Resources in the REST API
|
||||
intro: 'Learn how to navigate the resources provided by the {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API.'
|
||||
redirect_from:
|
||||
- /rest/initialize-the-repo
|
||||
versions:
|
||||
|
@ -11,23 +11,19 @@ versions:
|
|||
miniTocMaxHeadingLevel: 3
|
||||
topics:
|
||||
- API
|
||||
ms.openlocfilehash: 4fd3e2aad72ee0ffc4778a86dc99cd5bb6f9d2c5
|
||||
ms.sourcegitcommit: 4daa156856e651cb3854ead40e35bd918e481ad6
|
||||
ms.translationtype: HT
|
||||
ms.contentlocale: fr-FR
|
||||
ms.lasthandoff: 12/02/2022
|
||||
ms.locfileid: '148190398'
|
||||
---
|
||||
{% ifversion api-date-versioning %}
|
||||
## Version de l'API
|
||||
|
||||
Les ressources disponibles peuvent varier selon les versions de l’API REST. Vous devez utiliser l’en-tête `X-GitHub-Api-Version` pour spécifier une version d’API. Pour plus d’informations, consultez « [Versions d’API](/rest/overview/api-versions) ».
|
||||
{% ifversion api-date-versioning %}
|
||||
## API version
|
||||
|
||||
Available resources may vary between REST API versions. You should use the `X-GitHub-Api-Version` header to specify an API version. For more information, see "[API Versions](/rest/overview/api-versions)."
|
||||
|
||||
{% endif %}
|
||||
|
||||
## schéma
|
||||
## Schema
|
||||
|
||||
{% ifversion fpt or ghec %}Tout l’accès à l’API se fait par HTTPS et{% else %}L’API est accessible{% endif %} à partir de `{% data variables.product.api_url_code %}`. Toutes les données sont envoyées et reçues au format JSON.
|
||||
{% ifversion fpt or ghec %}All API access is over HTTPS, and{% else %}The API is{% endif %} accessed from `{% data variables.product.api_url_code %}`. All data is
|
||||
sent and received as JSON.
|
||||
|
||||
```shell
|
||||
$ curl -I {% data variables.product.api_url_pre %}/users/octocat/orgs
|
||||
|
@ -48,45 +44,55 @@ $ curl -I {% data variables.product.api_url_pre %}/users/octocat/orgs
|
|||
> X-Content-Type-Options: nosniff
|
||||
```
|
||||
|
||||
Les champs vides sont inclus avec la valeur `null` au lieu d’être omis.
|
||||
Blank fields are included as `null` instead of being omitted.
|
||||
|
||||
Tous les horodatages sont retournés au format UTC ISO 8601 :
|
||||
All timestamps return in UTC time, ISO 8601 format:
|
||||
|
||||
YYYY-MM-DDTHH:MM:SSZ
|
||||
|
||||
Pour plus d’informations sur les fuseaux horaires dans les horodatages, consultez [cette section](#timezones).
|
||||
For more information about timezones in timestamps, see [this section](#timezones).
|
||||
|
||||
### Représentations récapitulatives
|
||||
### Summary representations
|
||||
|
||||
Lorsque vous récupérez une liste de ressources, la réponse inclut un _sous-ensemble_ des attributs de cette ressource. Il s’agit de la représentation « récapitulative » de la ressource. (Certains attributs sont coûteux en calcul pour l’API.
|
||||
Pour des raisons de performances, ils sont exclus de la représentation récapitulative.
|
||||
Récupérez la représentation « détaillée » pour les obtenir.)
|
||||
When you fetch a list of resources, the response includes a _subset_ of the
|
||||
attributes for that resource. This is the "summary" representation of the
|
||||
resource. (Some attributes are computationally expensive for the API to provide.
|
||||
For performance reasons, the summary representation excludes those attributes.
|
||||
To obtain those attributes, fetch the "detailed" representation.)
|
||||
|
||||
**Exemple :** Lorsque vous demandez la liste des référentiels, vous obtenez la représentation récapitulative de chaque référentiel. Ici, nous récupérons la liste des référentiels appartenant à l’organisation [octokit](https://github.com/octokit) :
|
||||
**Example**: When you get a list of repositories, you get the summary
|
||||
representation of each repository. Here, we fetch the list of repositories owned
|
||||
by the [octokit](https://github.com/octokit) organization:
|
||||
|
||||
GET /orgs/octokit/repos
|
||||
|
||||
### Représentations détaillées
|
||||
### Detailed representations
|
||||
|
||||
Lorsque vous récupérez une ressource individuelle, la réponse inclut généralement _tous_ les attributs de cette ressource. Il s’agit de la représentation « détaillée » de la ressource. (Notez que l’autorisation influe parfois sur le niveau de détail de la représentation.)
|
||||
When you fetch an individual resource, the response typically includes _all_
|
||||
attributes for that resource. This is the "detailed" representation of the
|
||||
resource. (Note that authorization sometimes influences the amount of detail
|
||||
included in the representation.)
|
||||
|
||||
**Exemple :** Lorsque vous demandez un référentiel individuel, vous obtenez sa représentation détaillée. Ici, nous récupérons le référentiel [octokit/octokit.rb](https://github.com/octokit/octokit.rb) :
|
||||
**Example**: When you get an individual repository, you get the detailed
|
||||
representation of the repository. Here, we fetch the
|
||||
[octokit/octokit.rb](https://github.com/octokit/octokit.rb) repository:
|
||||
|
||||
GET /repos/octokit/octokit.rb
|
||||
|
||||
La documentation fournit un exemple de réponse pour chaque méthode d’API. L’exemple de réponse illustre tous les attributs retournés par cette méthode.
|
||||
The documentation provides an example response for each API method. The example
|
||||
response illustrates all attributes that are returned by that method.
|
||||
|
||||
## Authentification
|
||||
## Authentication
|
||||
|
||||
{% ifversion ghae %} Nous vous recommandons de vous authentifier auprès de l’API REST {% data variables.product.product_name %} en créant un jeton OAuth2 par le biais du [flux d’application web](/developers/apps/authorizing-oauth-apps#web-application-flow). {% else %} Il existe deux façons de s’authentifier par le biais de l’API REST {% data variables.product.product_name %}.{% endif %} Les demandes exigeant une authentification retournent `404 Not Found`, au lieu de `403 Forbidden`, dans certains endroits. Cela permet d’éviter les fuites accidentelles de référentiels privés auprès d’utilisateurs non autorisés.
|
||||
{% ifversion ghae %} We recommend authenticating to the {% data variables.product.product_name %} REST API by creating an OAuth2 token through the [web application flow](/developers/apps/authorizing-oauth-apps#web-application-flow). {% else %} There are two ways to authenticate through {% data variables.product.product_name %} REST API.{% endif %} Requests that require authentication will return `404 Not Found`, instead of `403 Forbidden`, in some places. This is to prevent the accidental leakage of private repositories to unauthorized users.
|
||||
|
||||
### Authentification de base
|
||||
### Basic authentication
|
||||
|
||||
```shell
|
||||
$ curl -u "username" {% data variables.product.api_url_pre %}
|
||||
```
|
||||
|
||||
### Jeton OAuth2 (envoyé dans un en-tête)
|
||||
### OAuth2 token (sent in a header)
|
||||
|
||||
```shell
|
||||
$ curl -H "Authorization: Bearer OAUTH-TOKEN" {% data variables.product.api_url_pre %}
|
||||
|
@ -94,20 +100,20 @@ $ curl -H "Authorization: Bearer OAUTH-TOKEN" {% data variables.product.api_url_
|
|||
|
||||
{% note %}
|
||||
|
||||
Remarque : GitHub recommande d’envoyer des jetons OAuth à l’aide de l’en-tête d’autorisation.
|
||||
Note: GitHub recommends sending OAuth tokens using the Authorization header.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{% note %}
|
||||
|
||||
**Remarque :** {% data reusables.getting-started.bearer-vs-token %}
|
||||
**Note:** {% data reusables.getting-started.bearer-vs-token %}
|
||||
|
||||
{% endnote %}
|
||||
|
||||
[En savoir plus sur OAuth2](/apps/building-oauth-apps/). Notez que les jetons OAuth2 peuvent être obtenus à l’aide du [flux d’application web](/developers/apps/authorizing-oauth-apps#web-application-flow) pour les applications de production.
|
||||
Read [more about OAuth2](/apps/building-oauth-apps/). Note that OAuth2 tokens can be acquired using the [web application flow](/developers/apps/authorizing-oauth-apps#web-application-flow) for production applications.
|
||||
|
||||
{% ifversion fpt or ghes or ghec %}
|
||||
### Clé/secret OAuth2
|
||||
### OAuth2 key/secret
|
||||
|
||||
{% data reusables.apps.deprecating_auth_with_query_parameters %}
|
||||
|
||||
|
@ -115,20 +121,22 @@ Remarque : GitHub recommande d’envoyer des jetons OAuth à l’aide de l’en-
|
|||
curl -u my_client_id:my_client_secret '{% data variables.product.api_url_pre %}/user/repos'
|
||||
```
|
||||
|
||||
L’utilisation de `client_id` et de `client_secret` ne permet _pas_ de vous authentifier en tant qu’utilisateur, mais seulement d’identifier votre application OAuth pour augmenter votre limite de débit. Les autorisations sont accordées uniquement aux utilisateurs, et non aux applications. Vous ne récupérerez que les données qu’un utilisateur non authentifié verrait. C’est pourquoi la clé et le secret OAuth2 doivent être utilisés exclusivement dans les scénarios de serveur à serveur. Ne communiquez pas la clé secrète client de votre application OAuth à vos utilisateurs.
|
||||
Using your `client_id` and `client_secret` does _not_ authenticate as a user, it will only identify your OAuth App to increase your rate limit. Permissions are only granted to users, not applications, and you will only get back data that an unauthenticated user would see. For this reason, you should only use the OAuth2 key/secret in server-to-server scenarios. Don't leak your OAuth App's client secret to your users.
|
||||
|
||||
{% ifversion ghes %} Vous ne pourrez pas vous authentifier à l’aide de votre clé OAuth2 et de votre secret en mode privé. Toute tentative d’authentification retournera `401 Unauthorized`. Pour plus d’informations, consultez « [Activation du mode privé](/admin/configuration/configuring-your-enterprise/enabling-private-mode) ».
|
||||
{% endif %} {% endif %}
|
||||
{% ifversion ghes %}
|
||||
You will be unable to authenticate using your OAuth2 key and secret while in private mode, and trying to authenticate will return `401 Unauthorized`. For more information, see "[Enabling private mode](/admin/configuration/configuring-your-enterprise/enabling-private-mode)".
|
||||
{% endif %}
|
||||
{% endif %}
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
|
||||
[En savoir plus sur la limitation de débit non authentifiée](#increasing-the-unauthenticated-rate-limit-for-oauth-apps).
|
||||
Read [more about unauthenticated rate limiting](#increasing-the-unauthenticated-rate-limit-for-oauth-apps).
|
||||
|
||||
{% endif %}
|
||||
|
||||
### Limite d’échecs de connexion
|
||||
### Failed login limit
|
||||
|
||||
L’authentification avec des informations d’identification non valides retourne `401 Unauthorized` :
|
||||
Authenticating with invalid credentials will return `401 Unauthorized`:
|
||||
|
||||
```shell
|
||||
$ curl -I {% data variables.product.api_url_pre %} -u foo:bar
|
||||
|
@ -140,7 +148,9 @@ $ curl -I {% data variables.product.api_url_pre %} -u foo:bar
|
|||
> }
|
||||
```
|
||||
|
||||
En cas de détection de plusieurs demandes comportant des informations d’identification non valides dans un court délai, l’API rejette temporairement toutes les tentatives d’authentification de l’utilisateur (y compris celles qui contiennent des informations d’identification valides) avec `403 Forbidden` :
|
||||
After detecting several requests with invalid credentials within a short period,
|
||||
the API will temporarily reject all authentication attempts for that user
|
||||
(including ones with valid credentials) with `403 Forbidden`:
|
||||
|
||||
```shell
|
||||
$ curl -i {% data variables.product.api_url_pre %} -u {% ifversion fpt or ghae or ghec %}
|
||||
|
@ -152,55 +162,62 @@ $ curl -i {% data variables.product.api_url_pre %} -u {% ifversion fpt or ghae o
|
|||
> }
|
||||
```
|
||||
|
||||
## Paramètres
|
||||
## Parameters
|
||||
|
||||
De nombreuses méthodes API prennent des paramètres facultatifs. Pour les demandes `GET`, tous les paramètres non spécifiés en tant que segment dans le chemin peuvent être transmis sous la forme d’un paramètre de chaîne de requête HTTP :
|
||||
Many API methods take optional parameters. For `GET` requests, any parameters not
|
||||
specified as a segment in the path can be passed as an HTTP query string
|
||||
parameter:
|
||||
|
||||
```shell
|
||||
$ curl -i "{% data variables.product.api_url_pre %}/repos/vmg/redcarpet/issues?state=closed"
|
||||
```
|
||||
|
||||
Dans cet exemple, les valeurs « vmg » et « redcarpet » sont fournies pour les paramètres `:owner` et `:repo` du chemin alors que `:state` est passé dans la chaîne de requête.
|
||||
In this example, the 'vmg' and 'redcarpet' values are provided for the `:owner`
|
||||
and `:repo` parameters in the path while `:state` is passed in the query
|
||||
string.
|
||||
|
||||
Pour les demandes `POST`, `PATCH`, `PUT` et `DELETE`, les paramètres non inclus dans l’URL doivent être codés en tant que JSON avec le Content-Type « application/json » :
|
||||
For `POST`, `PATCH`, `PUT`, and `DELETE` requests, parameters not included in the URL should be encoded as JSON
|
||||
with a Content-Type of 'application/json':
|
||||
|
||||
```shell
|
||||
$ curl -i -u username -d '{"scopes":["repo_deployment"]}' {% data variables.product.api_url_pre %}/authorizations
|
||||
```
|
||||
|
||||
## Point de terminaison racine
|
||||
## Root endpoint
|
||||
|
||||
Vous pouvez émettre une demande `GET` au point de terminaison racine pour obtenir toutes les catégories de points de terminaison prises en charge par l’API REST :
|
||||
You can issue a `GET` request to the root endpoint to get all the endpoint categories that the REST API supports:
|
||||
|
||||
```shell
|
||||
$ curl {% ifversion fpt or ghae or ghec %}
|
||||
-u USERNAME:TOKEN {% endif %}{% ifversion ghes %}-u USERNAME:PASSWORD {% endif %}{% data variables.product.api_url_pre %}
|
||||
```
|
||||
|
||||
## ID de nœud global GraphQL
|
||||
## GraphQL global node IDs
|
||||
|
||||
Pour savoir comment trouver les `node_id` au moyen de l’API REST et les utiliser dans les opérations GraphQL, consultez le guide « [Utilisation des ID de nœud globaux](/graphql/guides/using-global-node-ids) ».
|
||||
See the guide on "[Using Global Node IDs](/graphql/guides/using-global-node-ids)" for detailed information about how to find `node_id`s via the REST API and use them in GraphQL operations.
|
||||
|
||||
## Erreurs de client
|
||||
## Client errors
|
||||
|
||||
Il existe trois types possibles d’erreurs clientes sur les appels d’API qui reçoivent des corps de demande :
|
||||
There are three possible types of client errors on API calls that
|
||||
receive request bodies:
|
||||
|
||||
1. L’envoi de JSON non valide entraîne une réponse `400 Bad Request`.
|
||||
1. Sending invalid JSON will result in a `400 Bad Request` response.
|
||||
|
||||
HTTP/2 400
|
||||
Content-Length: 35
|
||||
|
||||
{"message":"Problems parsing JSON"}
|
||||
|
||||
2. L’envoi du mauvais type de valeurs JSON entraîne une réponse `400 Bad
|
||||
Request`.
|
||||
2. Sending the wrong type of JSON values will result in a `400 Bad
|
||||
Request` response.
|
||||
|
||||
HTTP/2 400
|
||||
Content-Length: 40
|
||||
|
||||
{"message":"Body should be a JSON object"}
|
||||
|
||||
3. L’envoi de champs non valides entraîne une réponse `422 Unprocessable Entity`.
|
||||
3. Sending invalid fields will result in a `422 Unprocessable Entity`
|
||||
response.
|
||||
|
||||
HTTP/2 422
|
||||
Content-Length: 149
|
||||
|
@ -216,47 +233,60 @@ Il existe trois types possibles d’erreurs clientes sur les appels d’API qui
|
|||
]
|
||||
}
|
||||
|
||||
Tous les objets d’erreur possèdent des propriétés de ressource et de champ qui permettent au client d’identifier le problème. Il existe également un code d’erreur indiquant ce qui est incorrect dans le champ. Voici les codes d’erreur de validation possibles :
|
||||
All error objects have resource and field properties so that your client
|
||||
can tell what the problem is. There's also an error code to let you
|
||||
know what is wrong with the field. These are the possible validation error
|
||||
codes:
|
||||
|
||||
Nom du code d’erreur | Description
|
||||
Error code name | Description
|
||||
-----------|-----------|
|
||||
`missing` | Une ressource n’existe pas.
|
||||
`missing_field` | Un champ obligatoire sur une ressource n’a pas été défini.
|
||||
`invalid` | La mise en forme d’un champ n’est pas valide. Pour plus d’informations, consultez la documentation.
|
||||
`already_exists` | Une autre ressource possède la même valeur que ce champ. Cela peut se produire dans les ressources qui doivent disposer d’une clé unique (par exemple les noms d’étiquette).
|
||||
`unprocessable` | Les entrées fournies ne sont pas valides.
|
||||
`missing` | A resource does not exist.
|
||||
`missing_field` | A required field on a resource has not been set.
|
||||
`invalid` | The formatting of a field is invalid. Review the documentation for more specific information.
|
||||
`already_exists` | Another resource has the same value as this field. This can happen in resources that must have some unique key (such as label names).
|
||||
`unprocessable` | The inputs provided were invalid.
|
||||
|
||||
Les ressources peuvent également envoyer des erreurs de validation personnalisées (où `code` a la valeur `custom`). Les erreurs personnalisées présentent toujours un champ `message` décrivant l’erreur. La plupart des erreurs incluent également un champ `documentation_url` pointant vers un contenu susceptible de vous aider à résoudre l’erreur.
|
||||
Resources may also send custom validation errors (where `code` is `custom`). Custom errors will always have a `message` field describing the error, and most errors will also include a `documentation_url` field pointing to some content that might help you resolve the error.
|
||||
|
||||
## Redirections HTTP
|
||||
## HTTP redirects
|
||||
|
||||
L’API REST {% data variables.product.product_name %} utilise la redirection HTTP le cas échéant. Les clients doivent partir du principe que toute demande peut entraîner une redirection. La réception d’une redirection HTTP ne constitue *pas* une erreur ; les clients doivent suivre cette redirection. Les réponses de redirection comportent un champ d’en-tête `Location` qui contient l’URI de la ressource à laquelle le client doit répéter les demandes.
|
||||
The {% data variables.product.product_name %} REST API uses HTTP redirection where appropriate. Clients should assume that any
|
||||
request may result in a redirection. Receiving an HTTP redirection is *not* an
|
||||
error and clients should follow that redirect. Redirect responses will have a
|
||||
`Location` header field which contains the URI of the resource to which the
|
||||
client should repeat the requests.
|
||||
|
||||
Code d’état | Description
|
||||
Status Code | Description
|
||||
-----------|-----------|
|
||||
`301` | Redirection permanente. L’URI que vous avez utilisé pour effectuer la demande a été remplacé par celui spécifié dans le champ d’en-tête `Location`. Cette demande et toutes les suivantes qui seront envoyées à cette ressource doivent être dirigées vers le nouvel URI.
|
||||
`302`, `307` | Redirection temporaire. La demande doit être répétée telle quelle dans l’URI spécifié dans le champ d’en-tête `Location`, mais les clients doivent continuer à utiliser l’URI d’origine pour les demandes futures.
|
||||
`301` | Permanent redirection. The URI you used to make the request has been superseded by the one specified in the `Location` header field. This and all future requests to this resource should be directed to the new URI.
|
||||
`302`, `307` | Temporary redirection. The request should be repeated verbatim to the URI specified in the `Location` header field but clients should continue to use the original URI for future requests.
|
||||
|
||||
D’autres codes d’état de redirection peuvent être utilisés conformément à la spécification HTTP 1.1.
|
||||
Other redirection status codes may be used in accordance with the HTTP 1.1 spec.
|
||||
|
||||
## Verbes HTTP
|
||||
## HTTP verbs
|
||||
|
||||
Dans la mesure du possible, l’API REST {% data variables.product.product_name %} s’efforce d’utiliser les verbes HTTP appropriés pour chaque action. Notez que les verbes HTTP respectent la casse.
|
||||
Where possible, the {% data variables.product.product_name %} REST API strives to use appropriate HTTP verbs for each
|
||||
action. Note that HTTP verbs are case-sensitive.
|
||||
|
||||
Verbe | Description
|
||||
Verb | Description
|
||||
-----|-----------
|
||||
`HEAD` | Peut être émis sur n’importe quelle ressource pour obtenir uniquement les informations d’en-tête HTTP.
|
||||
`GET` | Utilisé pour récupérer des ressources.
|
||||
`POST` | Utilisé pour créer des ressources.
|
||||
`PATCH` | Utilisé pour mettre à jour des ressources avec des données JSON partielles. Par exemple, une ressource Issue comporte des attributs `title` et `body`. Une demande `PATCH` peut accepter un ou plusieurs attributs pour mettre à jour la ressource.
|
||||
`PUT` | Utilisé pour remplacer des ressources ou des collections. Pour les demandes `PUT` dépourvues d’attribut `body`, veillez à définir l’en-tête `Content-Length` sur zéro.
|
||||
`DELETE` |Utilisé pour supprimer des ressources.
|
||||
`HEAD` | Can be issued against any resource to get just the HTTP header info.
|
||||
`GET` | Used for retrieving resources.
|
||||
`POST` | Used for creating resources.
|
||||
`PATCH` | Used for updating resources with partial JSON data. For instance, an Issue resource has `title` and `body` attributes. A `PATCH` request may accept one or more of the attributes to update the resource.
|
||||
`PUT` | Used for replacing resources or collections. For `PUT` requests with no `body` attribute, be sure to set the `Content-Length` header to zero.
|
||||
`DELETE` |Used for deleting resources.
|
||||
|
||||
## Hypermédia
|
||||
## Hypermedia
|
||||
|
||||
Toutes les ressources peuvent comporter une ou plusieurs propriétés `*_url` liées à d’autres ressources. Ces propriétés visent à fournir des URL explicites afin d’éviter aux clients d’API appropriés d’avoir à construire des URL eux-mêmes. Il est vivement recommandé aux clients d’API de les utiliser. Cela facilite les mises à niveau futures de l’API pour les développeurs. Toutes les URL doivent représenter des modèles d’URI [RFC 6570][rfc] appropriés.
|
||||
All resources may have one or more `*_url` properties linking to other
|
||||
resources. These are meant to provide explicit URLs so that proper API clients
|
||||
don't need to construct URLs on their own. It is highly recommended that API
|
||||
clients use these. Doing so will make future upgrades of the API easier for
|
||||
developers. All URLs are expected to be proper [RFC 6570][rfc] URI templates.
|
||||
|
||||
Vous pouvez ensuite développer ces modèles à l’aide de la gemme [uri_template][uri] ou d’un objet similaire :
|
||||
You can then expand these templates using something like the [uri_template][uri]
|
||||
gem:
|
||||
|
||||
>> tmpl = URITemplate.new('/notifications{?since,all,participating}')
|
||||
>> tmpl.expand
|
||||
|
@ -273,54 +303,11 @@ Vous pouvez ensuite développer ces modèles à l’aide de la gemme [uri_templa
|
|||
|
||||
## Pagination
|
||||
|
||||
Les demandes qui retournent plusieurs éléments sont paginés à 30 éléments par défaut. Vous pouvez spécifier d’autres pages avec le paramètre `page`. Pour certaines ressources, vous avez également la possibilité de définir une taille de page personnalisée (100 maximum) avec le paramètre `per_page`.
|
||||
Notez que, pour des raisons techniques, tous les points de terminaison ne respectent pas le paramètre `per_page` (cf. les [événements](/rest/reference/activity#events) par exemple).
|
||||
When a response from the REST API would include many results, {% data variables.product.company_short %} will paginate the results and return a subset of the results. You can use the link header from the response to request additional pages of data. If an endpoint supports the `per_page` query parameter, then you can control how many results are returned on a page. For more information about pagination, see "[Using pagination in the REST API](/rest/guides/using-pagination-in-the-rest-api)."
|
||||
|
||||
```shell
|
||||
$ curl '{% data variables.product.api_url_pre %}/user/repos?page=2&per_page=100'
|
||||
```
|
||||
## Timeouts
|
||||
|
||||
Notez que la numérotation de page commence à 1 et que, si le paramètre `page` est omis, la première page est retournée.
|
||||
|
||||
Certains points de terminaison utilisent la pagination basée sur le curseur. Un curseur est une chaîne qui pointe vers un emplacement dans le jeu de résultats.
|
||||
Avec la pagination basée sur le curseur, il n’existe aucun concept fixe de « pages » dans le jeu de résultats. Vous ne pouvez donc pas accéder à une page spécifique.
|
||||
Il est en revanche possible de parcourir les résultats à l’aide des paramètres `before` et `after`.
|
||||
|
||||
Pour plus d’informations sur la pagination, consultez notre guide sur [Parcours avec la pagination][pagination-guide].
|
||||
|
||||
### En-tête de lien
|
||||
|
||||
{% note %}
|
||||
|
||||
**Remarque :** Il est important de former des appels comportant des valeurs d’en-tête Link au lieu de construire vos propres URL.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
[L’en-tête Link](https://datatracker.ietf.org/doc/html/rfc5988) inclut des informations de pagination. Par exemple :
|
||||
|
||||
Link: <{% data variables.product.api_url_code %}/user/repos?page=3&per_page=100>; rel="next",
|
||||
<{% data variables.product.api_url_code %}/user/repos?page=50&per_page=100>; rel="last"
|
||||
|
||||
_L’exemple inclut un saut de ligne pour la lisibilité._
|
||||
|
||||
Si le point de terminaison utilise la pagination basée sur le curseur, l’en-tête Link est le suivant :
|
||||
|
||||
Link: <{% data variables.product.api_url_code %}/orgs/ORG/audit-log?after=MTYwMTkxOTU5NjQxM3xZbGI4VE5EZ1dvZTlla09uWjhoZFpR&before=>; rel="next",
|
||||
|
||||
Cet en-tête de réponse `Link` contient une ou plusieurs relations de lien [Hypermedia](/rest#hypermedia), dont certaines peuvent nécessiter l’expansion en tant que [modèles d’URI](https://datatracker.ietf.org/doc/html/rfc6570).
|
||||
|
||||
Les valeurs possibles de `rel` sont les suivantes :
|
||||
|
||||
Nom | Description
|
||||
-----------|-----------|
|
||||
`next` |Relation de lien de la page de résultats suivante.
|
||||
`last` |Relation de lien de la dernière page de résultats.
|
||||
`first` |Relation de lien de la première page de résultats.
|
||||
`prev` |Relation de lien de la page de résultats précédente.
|
||||
|
||||
## Délais d'attente
|
||||
|
||||
Si {% data variables.product.prodname_dotcom %} prend plus de 10 secondes pour traiter une demande d’API, {% data variables.product.prodname_dotcom %} met fin à la demande et vous recevrez une réponse d’expiration du délai d’attente semblable à la suivante :
|
||||
If {% data variables.product.prodname_dotcom %} takes more than 10 seconds to process an API request, {% data variables.product.prodname_dotcom %} will terminate the request and you will receive a timeout response like this:
|
||||
|
||||
```json
|
||||
{
|
||||
|
@ -328,23 +315,23 @@ Si {% data variables.product.prodname_dotcom %} prend plus de 10 secondes pour
|
|||
}
|
||||
```
|
||||
|
||||
{% data variables.product.product_name %} se réserve le droit de modifier le délai d’expiration pour protéger la vitesse et la fiabilité de l’API.
|
||||
{% data variables.product.product_name %} reserves the right to change the timeout window to protect the speed and reliability of the API.
|
||||
|
||||
## Limitation du débit
|
||||
## Rate limiting
|
||||
|
||||
Les limites de débit varient selon les types de demandes d’API envoyés à {% data variables.location.product_location %}.
|
||||
Different types of API requests to {% data variables.location.product_location %} are subject to different rate limits.
|
||||
|
||||
En outre, l’API de recherche présente des limites dédiées. Pour plus d’informations, consultez « [Recherche](/rest/reference/search#rate-limit) » dans la documentation de l’API REST.
|
||||
Additionally, the Search API has dedicated limits. For more information, see "[Search](/rest/reference/search#rate-limit)" in the REST API documentation.
|
||||
|
||||
{% data reusables.enterprise.rate_limit %}
|
||||
|
||||
{% data reusables.rest-api.always-check-your-limit %}
|
||||
|
||||
### Demandes provenant de comptes personnels
|
||||
### Requests from personal accounts
|
||||
|
||||
Les demandes d’API directes que vous authentifiez avec un {% data variables.product.pat_generic %} sont des demandes d’utilisateur à serveur. Une application OAuth ou une application GitHub peut également effectuer une demande d’utilisateur à serveur en votre nom après avoir autorisé l’application. Pour plus d’informations, consultez « [Création d’un {% data variables.product.pat_generic %}](/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) », « [Autorisation des applications OAuth](/authentication/keeping-your-account-and-data-secure/authorizing-oauth-apps) » et « [Autorisation des applications GitHub](/authentication/keeping-your-account-and-data-secure/authorizing-github-apps) ».
|
||||
Direct API requests that you authenticate with a {% data variables.product.pat_generic %} are user-to-server requests. An OAuth App or GitHub App can also make a user-to-server request on your behalf after you authorize the app. For more information, see "[Creating a {% data variables.product.pat_generic %}](/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token)," "[Authorizing OAuth Apps](/authentication/keeping-your-account-and-data-secure/authorizing-oauth-apps)," and "[Authorizing GitHub Apps](/authentication/keeping-your-account-and-data-secure/authorizing-github-apps)."
|
||||
|
||||
{% data variables.product.product_name %} associe toutes les demandes d’utilisateur à serveur à l’utilisateur authentifié. Dans le cas des applications OAuth et GitHub, il s’agit de l’utilisateur qui a autorisé l’application. Toutes les demandes d’utilisateur à serveur sont comptabilisées par rapport à la limite de débit de l’utilisateur authentifié.
|
||||
{% data variables.product.product_name %} associates all user-to-server requests with the authenticated user. For OAuth Apps and GitHub Apps, this is the user who authorized the app. All user-to-server requests count toward the authenticated user's rate limit.
|
||||
|
||||
{% data reusables.apps.user-to-server-rate-limits %}
|
||||
|
||||
|
@ -354,33 +341,33 @@ Les demandes d’API directes que vous authentifiez avec un {% data variables.pr
|
|||
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
|
||||
Pour les demandes non authentifiées, la limite de débit autorise jusqu’à 60 demandes par heure. Les demandes non authentifiées sont associées à l’adresse IP d’origine, et non à la personne qui les effectue.
|
||||
For unauthenticated requests, the rate limit allows for up to 60 requests per hour. Unauthenticated requests are associated with the originating IP address, and not the person making requests.
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
### Demandes provenant d’applications GitHub
|
||||
### Requests from GitHub Apps
|
||||
|
||||
Les demandes d’une application GitHub peuvent être des demandes d’utilisateur à serveur ou de serveur à serveur. Pour plus d’informations sur les limites de débit des applications GitHub, consultez « [Limites de débit des applications GitHub](/developers/apps/building-github-apps/rate-limits-for-github-apps) ».
|
||||
Requests from a GitHub App may be either user-to-server or server-to-server requests. For more information about rate limits for GitHub Apps, see "[Rate limits for GitHub Apps](/developers/apps/building-github-apps/rate-limits-for-github-apps)."
|
||||
|
||||
### Demandes provenant de GitHub Actions
|
||||
### Requests from GitHub Actions
|
||||
|
||||
Vous pouvez utiliser le jeton `GITHUB_TOKEN` intégré pour authentifier les demandes dans des flux de travail GitHub Actions. Pour plus d’informations, consultez « [Authentification automatique par jeton](/actions/security-guides/automatic-token-authentication) ».
|
||||
You can use the built-in `GITHUB_TOKEN` to authenticate requests in GitHub Actions workflows. For more information, see "[Automatic token authentication](/actions/security-guides/automatic-token-authentication)."
|
||||
|
||||
Avec `GITHUB_TOKEN`, la limite de débit s’élève à 1 000 demandes par heure et par dépôt.{% ifversion fpt or ghec %} Pour les demandes adressées à des ressources appartenant à un compte d’entreprise sur {% data variables.location.product_location %}, la limite de débit de {% data variables.product.prodname_ghe_cloud %} s’applique, soit 15 000 demandes par heure et par dépôt.{% endif %}
|
||||
When using `GITHUB_TOKEN`, the rate limit is 1,000 requests per hour per repository.{% ifversion fpt or ghec %} For requests to resources that belong to an enterprise account on {% data variables.location.product_location %}, {% data variables.product.prodname_ghe_cloud %}'s rate limit applies, and the limit is 15,000 requests per hour per repository.{% endif %}
|
||||
|
||||
### Vérification de l’état de la limite de débit
|
||||
### Checking your rate limit status
|
||||
|
||||
L’API Limite de débit et les en-têtes HTTP d’une réponse font autorité concernant le nombre actuel d’appels d’API disponibles à tout moment pour vous ou votre application.
|
||||
The Rate Limit API and a response's HTTP headers are authoritative sources for the current number of API calls available to you or your app at any given time.
|
||||
|
||||
#### API Limite de débit
|
||||
#### Rate Limit API
|
||||
|
||||
Vous pouvez utiliser l’API Limite de débit pour vérifier l’état de votre limite de débit sans avoir à atteindre la limite actuelle. Pour plus d’informations, consultez « [Limite de débit](/rest/reference/rate-limit) ».
|
||||
You can use the Rate Limit API to check your rate limit status without incurring a hit to the current limit. For more information, see "[Rate limit](/rest/reference/rate-limit)."
|
||||
|
||||
#### En-têtes HTTP de limite de débit
|
||||
#### Rate limit HTTP headers
|
||||
|
||||
Les en-têtes HTTP retournés d’une demande d’API indiquent l’état de la limite de débit actuelle :
|
||||
The returned HTTP headers of any API request show your current rate limit status:
|
||||
|
||||
```shell
|
||||
$ curl -I {% data variables.product.api_url_pre %}/users/octocat
|
||||
|
@ -392,21 +379,21 @@ $ curl -I {% data variables.product.api_url_pre %}/users/octocat
|
|||
> x-ratelimit-reset: 1372700873
|
||||
```
|
||||
|
||||
Nom de l’en-tête | Description
|
||||
Header Name | Description
|
||||
-----------|-----------|
|
||||
`x-ratelimit-limit` | Nombre maximal de demandes autorisées par heure.
|
||||
`x-ratelimit-remaining` | Nombre de demandes restantes dans la fenêtre de limite de débit actuelle.
|
||||
`x-ratelimit-used` | Nombre de demandes que vous avez faites dans la fenêtre de limite de débit actuelle.
|
||||
`x-ratelimit-reset` | Heure à laquelle la fenêtre de limite de débit actuelle se réinitialise en [secondes d’époque UTC](http://en.wikipedia.org/wiki/Unix_time).
|
||||
`x-ratelimit-limit` | The maximum number of requests you're permitted to make per hour.
|
||||
`x-ratelimit-remaining` | The number of requests remaining in the current rate limit window.
|
||||
`x-ratelimit-used` | The number of requests you've made in the current rate limit window.
|
||||
`x-ratelimit-reset` | The time at which the current rate limit window resets in [UTC epoch seconds](http://en.wikipedia.org/wiki/Unix_time).
|
||||
|
||||
Si vous avez besoin de l’heure dans un autre format, il est possible d’effectuer l’opération dans n’importe quel langage de programmation moderne. Dans le cas, par exemple, où vous ouvrez la console sur votre navigateur web, vous pouvez facilement obtenir l’heure de réinitialisation en tant qu’objet JavaScript Date.
|
||||
If you need the time in a different format, any modern programming language can get the job done. For example, if you open up the console on your web browser, you can easily get the reset time as a JavaScript Date object.
|
||||
|
||||
``` javascript
|
||||
new Date(1372700873 * 1000)
|
||||
// => Mon Jul 01 2013 13:47:53 GMT-0400 (EDT)
|
||||
```
|
||||
|
||||
Si vous dépassez la limite de débit, une réponse d’erreur est retournée :
|
||||
If you exceed the rate limit, an error response returns:
|
||||
|
||||
```shell
|
||||
> HTTP/2 403
|
||||
|
@ -422,9 +409,9 @@ Si vous dépassez la limite de débit, une réponse d’erreur est retournée :
|
|||
> }
|
||||
```
|
||||
|
||||
### Augmentation de la limite de débit non authentifié des applications OAuth
|
||||
### Increasing the unauthenticated rate limit for OAuth Apps
|
||||
|
||||
Si votre application OAuth doit effectuer des appels non authentifiés avec une limite de débit plus élevée, vous pouvez transmettre l’ID client et le secret de votre application avant l’itinéraire du point de terminaison.
|
||||
If your OAuth App needs to make unauthenticated calls with a higher rate limit, you can pass your app's client ID and secret before the endpoint route.
|
||||
|
||||
```shell
|
||||
$ curl -u my_client_id:my_client_secret -I {% data variables.product.api_url_pre %}/user/repos
|
||||
|
@ -438,21 +425,21 @@ $ curl -u my_client_id:my_client_secret -I {% data variables.product.api_url_pre
|
|||
|
||||
{% note %}
|
||||
|
||||
**Remarque :** Ne partagez jamais votre secret client avec quiconque. Ne l’incluez pas dans le code du navigateur côté client. Utilisez la méthode indiquée ici uniquement pour les appels de serveur à serveur.
|
||||
**Note:** Never share your client secret with anyone or include it in client-side browser code. Use the method shown here only for server-to-server calls.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
### Respect de la limite de débit
|
||||
### Staying within the rate limit
|
||||
|
||||
Si vous dépassez votre limite de débit en utilisant une authentification de base ou OAuth, vous avez de grandes chances de résoudre le problème en mettant en cache les réponses de l’API et en utilisant des [demandes conditionnelles](#conditional-requests).
|
||||
If you exceed your rate limit using Basic Authentication or OAuth, you can likely fix the issue by caching API responses and using [conditional requests](#conditional-requests).
|
||||
|
||||
### Limites de débit secondaires
|
||||
### Secondary rate limits
|
||||
|
||||
Pour fournir un service de qualité sur {% data variables.product.product_name %}, des limites de débit supplémentaires peuvent s’appliquer à certaines actions en cas d’utilisation de l’API. Par exemple, le fait d’utiliser l’API pour créer rapidement du contenu, réaliser des interrogations agressives au lieu d’utiliser des webhooks, effectuer plusieurs demandes simultanées ou demander à plusieurs reprises des données coûteuses en calcul peut entraîner une limitation de débit secondaire.
|
||||
In order to provide quality service on {% data variables.product.product_name %}, additional rate limits may apply to some actions when using the API. For example, using the API to rapidly create content, poll aggressively instead of using webhooks, make multiple concurrent requests, or repeatedly request data that is computationally expensive may result in secondary rate limiting.
|
||||
|
||||
Les limites de débit secondaires ne sont pas destinées à interférer avec l’utilisation légitime de l’API. Vos limites normales de débit doivent constituer la seule limite que vous ciblez. Pour vous assurer d’adopter le bon comportement vis-à-vis de l’API, consultez nos [Recommandations de meilleures pratiques](/guides/best-practices-for-integrators/).
|
||||
Secondary rate limits are not intended to interfere with legitimate use of the API. Your normal rate limits should be the only limit you target. To ensure you're acting as a good API citizen, check out our [Best Practices guidelines](/guides/best-practices-for-integrators/).
|
||||
|
||||
Si votre application déclenche cette limite de débit, vous recevez une réponse informative :
|
||||
If your application triggers this rate limit, you'll receive an informative response:
|
||||
|
||||
```shell
|
||||
> HTTP/2 403
|
||||
|
@ -467,17 +454,19 @@ Si votre application déclenche cette limite de débit, vous recevez une répons
|
|||
|
||||
{% ifversion fpt or ghec %}
|
||||
|
||||
## Agent utilisateur requis
|
||||
## User agent required
|
||||
|
||||
Toutes les demandes d’API DOIVENT inclure un en-tête `User-Agent` valide. Les demandes sans en-tête `User-Agent` sont rejetées. Nous vous demandons d’utiliser votre nom d’utilisateur {% data variables.product.product_name %} ou le nom de votre application comme valeur d’en-tête `User-Agent`. Cela nous permet de vous contacter en cas de problème.
|
||||
All API requests MUST include a valid `User-Agent` header. Requests with no `User-Agent`
|
||||
header will be rejected. We request that you use your {% data variables.product.product_name %} username, or the name of your
|
||||
application, for the `User-Agent` header value. This allows us to contact you if there are problems.
|
||||
|
||||
Voici un exemple :
|
||||
Here's an example:
|
||||
|
||||
```shell
|
||||
User-Agent: Awesome-Octocat-App
|
||||
```
|
||||
|
||||
cURL envoie par défaut un en-tête `User-Agent` valide. Si vous fournissez un en-tête `User-Agent` non valide avec cURL (ou un autre client), vous recevez une réponse `403 Forbidden` :
|
||||
cURL sends a valid `User-Agent` header by default. If you provide an invalid `User-Agent` header via cURL (or via an alternative client), you will receive a `403 Forbidden` response:
|
||||
|
||||
```shell
|
||||
$ curl -IH 'User-Agent: ' {% data variables.product.api_url_pre %}/meta
|
||||
|
@ -492,15 +481,20 @@ $ curl -IH 'User-Agent: ' {% data variables.product.api_url_pre %}/meta
|
|||
|
||||
{% endif %}
|
||||
|
||||
## Demandes conditionnelles
|
||||
## Conditional requests
|
||||
|
||||
La plupart des réponses retournent un en-tête `ETag`. De nombreuses réponses renvoient également un en-tête `Last-Modified`. Vous pouvez utiliser les valeurs de ces en-têtes pour effectuer des demandes ultérieures à ces ressources à l’aide respectivement de l’en-tête `If-None-Match` et de l’en-tête `If-Modified-Since`. Si la ressource n’a pas changé, le serveur retourne `304 Not Modified`.
|
||||
Most responses return an `ETag` header. Many responses also return a `Last-Modified` header. You can use the values
|
||||
of these headers to make subsequent requests to those resources using the
|
||||
`If-None-Match` and `If-Modified-Since` headers, respectively. If the resource
|
||||
has not changed, the server will return a `304 Not Modified`.
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Remarque** : La création d’une demande conditionnelle et la réception d’une réponse 304 ne comptent pas par rapport à votre [limite de débit](#rate-limiting). Nous vous encourageons donc à l’utiliser chaque fois que cela est possible.
|
||||
**Note**: Making a conditional request and receiving a 304 response does not
|
||||
count against your [Rate Limit](#rate-limiting), so we encourage you to use it
|
||||
whenever possible.
|
||||
|
||||
{% endtip %}
|
||||
|
||||
|
@ -537,12 +531,16 @@ $ curl -I {% data variables.product.api_url_pre %}/user -H "If-Modified-Since: T
|
|||
> x-ratelimit-reset: 1372700873
|
||||
```
|
||||
|
||||
## Partage des ressources cross-origin
|
||||
## Cross origin resource sharing
|
||||
|
||||
L’API prend en charge le partage de ressources CORS (Cross-Origin Resource Sharing) pour les demandes AJAX de toute origine.
|
||||
Vous pouvez lire la [recommandation CORS W3C](http://www.w3.org/TR/cors/) ou [cette introduction](https://code.google.com/archive/p/html5security/wikis/CrossOriginRequestSecurity.wiki) du guide de sécurité HTML 5.
|
||||
The API supports Cross Origin Resource Sharing (CORS) for AJAX requests from
|
||||
any origin.
|
||||
You can read the [CORS W3C Recommendation](http://www.w3.org/TR/cors/), or
|
||||
[this intro](https://code.google.com/archive/p/html5security/wikis/CrossOriginRequestSecurity.wiki) from the
|
||||
HTML 5 Security Guide.
|
||||
|
||||
Voici un exemple de demande envoyée par un navigateur qui atteint `http://example.com` :
|
||||
Here's a sample request sent from a browser hitting
|
||||
`http://example.com`:
|
||||
|
||||
```shell
|
||||
$ curl -I {% data variables.product.api_url_pre %} -H "Origin: http://example.com"
|
||||
|
@ -551,7 +549,7 @@ Access-Control-Allow-Origin: *
|
|||
Access-Control-Expose-Headers: ETag, Link, X-GitHub-OTP, x-ratelimit-limit, x-ratelimit-remaining, x-ratelimit-reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval
|
||||
```
|
||||
|
||||
Voici à quoi ressemble la demande préliminaire CORS :
|
||||
This is what the CORS preflight request looks like:
|
||||
|
||||
```shell
|
||||
$ curl -I {% data variables.product.api_url_pre %} -H "Origin: http://example.com" -X OPTIONS
|
||||
|
@ -563,9 +561,13 @@ Access-Control-Expose-Headers: ETag, Link, X-GitHub-OTP, x-ratelimit-limit, x-ra
|
|||
Access-Control-Max-Age: 86400
|
||||
```
|
||||
|
||||
## Rappels JSON-P
|
||||
## JSON-P callbacks
|
||||
|
||||
Vous pouvez envoyer un paramètre `?callback` à n’importe quel appel GET pour que les résultats s’encapsulent dans une fonction JSON. Cette technique est généralement utilisée lorsque les navigateurs doivent incorporer du contenu {% data variables.product.product_name %} dans des pages web en contournant des problèmes interdomaines. La réponse inclut la même sortie de données que l’API classique, ainsi que les informations d’en-tête HTTP pertinentes.
|
||||
You can send a `?callback` parameter to any GET call to have the results
|
||||
wrapped in a JSON function. This is typically used when browsers want
|
||||
to embed {% data variables.product.product_name %} content in web pages by getting around cross domain
|
||||
issues. The response includes the same data output as the regular API,
|
||||
plus the relevant HTTP Header information.
|
||||
|
||||
```shell
|
||||
$ curl {% data variables.product.api_url_pre %}?callback=foo
|
||||
|
@ -586,7 +588,7 @@ $ curl {% data variables.product.api_url_pre %}?callback=foo
|
|||
> })
|
||||
```
|
||||
|
||||
Vous pouvez écrire un gestionnaire JavaScript pour traiter le rappel. Voici un exemple minimal que vous pouvez essayer :
|
||||
You can write a JavaScript handler to process the callback. Here's a minimal example you can try out:
|
||||
|
||||
<html>
|
||||
<head>
|
||||
|
@ -610,13 +612,15 @@ Vous pouvez écrire un gestionnaire JavaScript pour traiter le rappel. Voici un
|
|||
</body>
|
||||
</html>
|
||||
|
||||
Tous les en-têtes possèdent la même valeur de chaîne que les en-têtes HTTP, à une exception notable : Link. Les en-têtes Link, préanalysés automatiquement, se présentent sous la forme d’un tableau de tuples `[url, options]`.
|
||||
All of the headers are the same String value as the HTTP Headers with one
|
||||
notable exception: Link. Link headers are pre-parsed for you and come
|
||||
through as an array of `[url, options]` tuples.
|
||||
|
||||
Prenons l’exemple du lien suivant :
|
||||
A link that looks like this:
|
||||
|
||||
Link: <url1>; rel="next", <url2>; rel="foo"; bar="baz"
|
||||
|
||||
Il se présente ainsi dans la sortie de rappel :
|
||||
... will look like this in the Callback output:
|
||||
|
||||
```json
|
||||
{
|
||||
|
@ -638,39 +642,37 @@ Il se présente ainsi dans la sortie de rappel :
|
|||
}
|
||||
```
|
||||
|
||||
## Fuseaux horaires
|
||||
## Timezones
|
||||
|
||||
Certaines demandes qui créent de nouvelles données (par exemple une validation) vous permettent de fournir des informations de fuseau horaire lorsque vous spécifiez ou générez des horodatages. Nous appliquons les règles suivantes, par ordre de priorité, pour déterminer les informations de fuseau horaire de ces appels d’API.
|
||||
Some requests that create new data, such as creating a new commit, allow you to provide time zone information when specifying or generating timestamps. We apply the following rules, in order of priority, to determine timezone information for such API calls.
|
||||
|
||||
* [Indication explicite d’un horodatage ISO 8601 avec des informations de fuseau horaire](#explicitly-providing-an-iso-8601-timestamp-with-timezone-information)
|
||||
* [Utilisation de l’en-tête `Time-Zone`](#using-the-time-zone-header)
|
||||
* [Utilisation du dernier fuseau horaire connu pour l’utilisateur](#using-the-last-known-timezone-for-the-user)
|
||||
* [Application de la valeur par défaut UTC sans autres informations de fuseau horaire](#defaulting-to-utc-without-other-timezone-information)
|
||||
* [Explicitly providing an ISO 8601 timestamp with timezone information](#explicitly-providing-an-iso-8601-timestamp-with-timezone-information)
|
||||
* [Using the `Time-Zone` header](#using-the-time-zone-header)
|
||||
* [Using the last known timezone for the user](#using-the-last-known-timezone-for-the-user)
|
||||
* [Defaulting to UTC without other timezone information](#defaulting-to-utc-without-other-timezone-information)
|
||||
|
||||
Notez que ces règles s’appliquent uniquement aux données transmises à l’API, et non aux données retournées par celle-ci. Comme il est mentionné dans « [Schéma](#schema) », les horodatages retournés par l’API sont au format UTC ISO 8601.
|
||||
Note that these rules apply only to data passed to the API, not to data returned by the API. As mentioned in "[Schema](#schema)," timestamps returned by the API are in UTC time, ISO 8601 format.
|
||||
|
||||
### Indication explicite d’un horodatage ISO 8601 avec des informations de fuseau horaire
|
||||
### Explicitly providing an ISO 8601 timestamp with timezone information
|
||||
|
||||
Dans le cas des appels d’API qui autorisent la spécification d’un horodatage, nous utilisons cet horodatage précis. Prenons par exemple [l’API Validations](/rest/reference/git#commits).
|
||||
For API calls that allow for a timestamp to be specified, we use that exact timestamp. An example of this is the [Commits API](/rest/reference/git#commits).
|
||||
|
||||
Ces horodatages se présentent ainsi : `2014-02-27T15:05:06+01:00`. Pour savoir comment ces horodatages peuvent être spécifiés, consultez également [cet exemple](/rest/reference/git#example-input).
|
||||
These timestamps look something like `2014-02-27T15:05:06+01:00`. Also see [this example](/rest/reference/git#example-input) for how these timestamps can be specified.
|
||||
|
||||
### Utilisation de l’en-tête `Time-Zone`
|
||||
### Using the `Time-Zone` header
|
||||
|
||||
Il est possible de fournir un en-tête `Time-Zone` qui définit un fuseau horaire en fonction de la [liste des noms de la base de données Olson](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).
|
||||
It is possible to supply a `Time-Zone` header which defines a timezone according to the [list of names from the Olson database](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).
|
||||
|
||||
```shell
|
||||
$ curl -H "Time-Zone: Europe/Amsterdam" -X POST {% data variables.product.api_url_pre %}/repos/github/linguist/contents/new_file.md
|
||||
```
|
||||
|
||||
Cela signifie qu’un horodatage est généré pour le moment où l’appel d’API est effectué dans le fuseau horaire défini par cet en-tête. Par exemple, [l’API Contenus](/rest/reference/repos#contents) génère une validation Git pour chaque ajout ou modification et utilise l’heure actuelle comme horodatage. Cet en-tête détermine le fuseau horaire utilisé pour générer cet horodatage actuel.
|
||||
This means that we generate a timestamp for the moment your API call is made in the timezone this header defines. For example, the [Contents API](/rest/reference/repos#contents) generates a git commit for each addition or change and uses the current time as the timestamp. This header will determine the timezone used for generating that current timestamp.
|
||||
|
||||
### Utilisation du dernier fuseau horaire connu pour l’utilisateur
|
||||
### Using the last known timezone for the user
|
||||
|
||||
Si aucun en-tête `Time-Zone` n’est spécifié lorsque vous effectuez un appel authentifié à l’API, le fuseau horaire utilisé est le dernier fuseau connu de l’utilisateur authentifié. Il est mis à jour chaque fois que vous parcourez le site web {% data variables.product.product_name %}.
|
||||
If no `Time-Zone` header is specified and you make an authenticated call to the API, we use the last known timezone for the authenticated user. The last known timezone is updated whenever you browse the {% data variables.product.product_name %} website.
|
||||
|
||||
### Application de la valeur par défaut UTC sans autres informations de fuseau horaire
|
||||
### Defaulting to UTC without other timezone information
|
||||
|
||||
Si la procédure ci-dessus ne produit aucune information, c’est le fuseau horaire UTC qui est utilisé pour créer la validation Git.
|
||||
|
||||
[pagination-guide]: /guides/traversing-with-pagination
|
||||
If the steps above don't result in any information, we use UTC as the timezone to create the git commit.
|
||||
|
|
|
@ -0,0 +1,9 @@
|
|||
---
|
||||
ms.openlocfilehash: 31687bc8c34a11de5a36e5db2877d279740f0f8f
|
||||
ms.sourcegitcommit: 4f08a208a0d2e13dc109678750a962ea2f67e1ba
|
||||
ms.translationtype: HT
|
||||
ms.contentlocale: fr-FR
|
||||
ms.lasthandoff: 12/06/2022
|
||||
ms.locfileid: "148192056"
|
||||
---
|
||||
Vous pouvez utiliser n’importe quel contexte et n’importe quelle expression pris en charge pour créer un conditionnel. Pour plus d’informations sur les contextes pris en charge dans cette clé, consultez « [Disponibilité du contexte](/actions/learn-github-actions/contexts#context-availability) ».
|
|
@ -1,10 +1,18 @@
|
|||
You can use the `jobs.<job_id>.if` conditional to prevent a job from running unless a condition is met. {% data reusables.actions.if-supported-contexts %}
|
||||
---
|
||||
ms.openlocfilehash: eb897a445a5e5a90014097ba76a5ecb095aa0bef
|
||||
ms.sourcegitcommit: 4f08a208a0d2e13dc109678750a962ea2f67e1ba
|
||||
ms.translationtype: HT
|
||||
ms.contentlocale: fr-FR
|
||||
ms.lasthandoff: 12/06/2022
|
||||
ms.locfileid: "148192057"
|
||||
---
|
||||
Vous pouvez utiliser le `jobs.<job_id>.if` conditionnel pour empêcher l’exécution d’un travail, sauf si une condition est remplie. {% data reusables.actions.if-supported-contexts %}
|
||||
|
||||
{% data reusables.actions.expression-syntax-if %} For more information, see "[Expressions](/actions/learn-github-actions/expressions)."
|
||||
{% data reusables.actions.expression-syntax-if %} Pour plus d’informations, consultez « [Expressions](/actions/learn-github-actions/expressions) ».
|
||||
|
||||
### Example: Only run job for specific repository
|
||||
### Exemple : Exécuter un travail uniquement pour un dépôt spécifique
|
||||
|
||||
This example uses `if` to control when the `production-deploy` job can run. It will only run if the repository is named `octo-repo-prod` and is within the `octo-org` organization. Otherwise, the job will be marked as _skipped_.
|
||||
Cet exemple utilise `if` pour contrôler le moment où le travail `production-deploy` peut s’exécuter. Il s’exécute uniquement si le dépôt se nomme `octo-repo-prod`, et s’il se trouve dans l’organisation `octo-org`. Sinon, le travail est marqué comme étant _ignoré_.
|
||||
|
||||
```yaml{:copy}
|
||||
name: example-workflow
|
||||
|
|
|
@ -1,13 +0,0 @@
|
|||
{% ifversion not fpt or ghec %}
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note**: The following guide uses the REST API for {% data variables.product.prodname_dotcom_the_website %}.
|
||||
|
||||
- Use <code>{% data variables.product.api_url_pre %}</code> to access the API for {% data variables.product.product_name %}.
|
||||
|
||||
- The guide specifies usernames and repositories that may not exist on {% data variables.location.product_location %}. You may need to use different names to see similar output.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{% endif %}
|
|
@ -188,6 +188,7 @@ translations/fr-FR/content/organizations/restricting-access-to-your-organization
|
|||
translations/fr-FR/content/pages/getting-started-with-github-pages/adding-a-theme-to-your-github-pages-site-with-the-theme-chooser.md,file deleted because it no longer exists in main
|
||||
translations/fr-FR/content/pull-requests/collaborating-with-pull-requests/working-with-forks/configuring-a-remote-for-a-fork.md,file deleted because it no longer exists in main
|
||||
translations/fr-FR/content/pull-requests/collaborating-with-pull-requests/working-with-forks/merging-an-upstream-repository-into-your-fork.md,file deleted because it no longer exists in main
|
||||
translations/fr-FR/content/rest/guides/traversing-with-pagination.md,file deleted because it no longer exists in main
|
||||
translations/fr-FR/content/rest/reference/actions.md,file deleted because it no longer exists in main
|
||||
translations/fr-FR/content/rest/reference/activity.md,file deleted because it no longer exists in main
|
||||
translations/fr-FR/content/rest/reference/apps.md,file deleted because it no longer exists in main
|
||||
|
@ -443,7 +444,6 @@ translations/fr-FR/content/account-and-profile/setting-up-and-managing-your-pers
|
|||
translations/fr-FR/content/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-your-personal-account/index.md,broken liquid tags
|
||||
translations/fr-FR/content/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-your-personal-account/managing-multiple-accounts.md,broken liquid tags
|
||||
translations/fr-FR/content/actions/automating-builds-and-tests/about-continuous-integration.md,broken liquid tags
|
||||
translations/fr-FR/content/actions/creating-actions/creating-a-composite-action.md,broken liquid tags
|
||||
translations/fr-FR/content/actions/creating-actions/creating-a-docker-container-action.md,broken liquid tags
|
||||
translations/fr-FR/content/actions/creating-actions/creating-a-javascript-action.md,rendering error
|
||||
translations/fr-FR/content/actions/creating-actions/metadata-syntax-for-github-actions.md,rendering error
|
||||
|
@ -540,6 +540,7 @@ translations/fr-FR/content/admin/enterprise-management/caching-repositories/conf
|
|||
translations/fr-FR/content/admin/enterprise-management/caching-repositories/index.md,rendering error
|
||||
translations/fr-FR/content/admin/enterprise-management/configuring-clustering/cluster-network-configuration.md,broken liquid tags
|
||||
translations/fr-FR/content/admin/enterprise-management/configuring-clustering/configuring-high-availability-replication-for-a-cluster.md,broken liquid tags
|
||||
translations/fr-FR/content/admin/enterprise-management/configuring-high-availability/initiating-a-failover-to-your-replica-appliance.md,broken liquid tags
|
||||
translations/fr-FR/content/admin/enterprise-management/monitoring-your-appliance/accessing-the-monitor-dashboard.md,broken liquid tags
|
||||
translations/fr-FR/content/admin/enterprise-management/monitoring-your-appliance/configuring-collectd.md,broken liquid tags
|
||||
translations/fr-FR/content/admin/enterprise-management/monitoring-your-appliance/generating-a-health-check-for-your-enterprise.md,broken liquid tags
|
||||
|
@ -1022,12 +1023,12 @@ translations/fr-FR/content/rest/enterprise-admin/pre-receive-hooks.md,broken liq
|
|||
translations/fr-FR/content/rest/enterprise-admin/repo-pre-receive-hooks.md,broken liquid tags
|
||||
translations/fr-FR/content/rest/enterprise-admin/scim.md,rendering error
|
||||
translations/fr-FR/content/rest/enterprise-admin/users.md,broken liquid tags
|
||||
translations/fr-FR/content/rest/guides/traversing-with-pagination.md,rendering error
|
||||
translations/fr-FR/content/rest/guides/working-with-comments.md,broken liquid tags
|
||||
translations/fr-FR/content/rest/migrations/source-imports.md,broken liquid tags
|
||||
translations/fr-FR/content/rest/overview/api-previews.md,rendering error
|
||||
translations/fr-FR/content/rest/overview/other-authentication-methods.md,rendering error
|
||||
translations/fr-FR/content/rest/overview/permissions-required-for-github-apps.md,rendering error
|
||||
translations/fr-FR/content/rest/overview/resources-in-the-rest-api.md,broken liquid tags
|
||||
translations/fr-FR/content/rest/packages.md,broken liquid tags
|
||||
translations/fr-FR/content/rest/projects/projects.md,broken liquid tags
|
||||
translations/fr-FR/content/rest/quickstart.md,broken liquid tags
|
||||
|
@ -1083,7 +1084,6 @@ translations/fr-FR/data/reusables/actions/enterprise-postinstall-nextsteps.md,br
|
|||
translations/fr-FR/data/reusables/actions/github-connect-resolution.md,broken liquid tags
|
||||
translations/fr-FR/data/reusables/actions/hosted-runner-security.md,broken liquid tags
|
||||
translations/fr-FR/data/reusables/actions/jobs/section-defining-outputs-for-jobs.md,broken liquid tags
|
||||
translations/fr-FR/data/reusables/actions/jobs/section-using-conditions-to-control-job-execution.md,broken liquid tags
|
||||
translations/fr-FR/data/reusables/actions/more-resources-for-ghes.md,rendering error
|
||||
translations/fr-FR/data/reusables/actions/moving-a-runner-to-a-group.md,rendering error
|
||||
translations/fr-FR/data/reusables/actions/reusable-workflow-artifacts.md,rendering error
|
||||
|
@ -1251,7 +1251,6 @@ translations/fr-FR/data/reusables/repositories/settings-sidebar-actions-runners.
|
|||
translations/fr-FR/data/reusables/repositories/sidebar-notifications.md,rendering error
|
||||
translations/fr-FR/data/reusables/repositories/suggest-changes.md,broken liquid tags
|
||||
translations/fr-FR/data/reusables/repositories/you-can-fork.md,broken liquid tags
|
||||
translations/fr-FR/data/reusables/rest-api/dotcom-only-guide-note.md,rendering error
|
||||
translations/fr-FR/data/reusables/saml/about-authorized-credentials.md,broken liquid tags
|
||||
translations/fr-FR/data/reusables/saml/about-linked-identities.md,broken liquid tags
|
||||
translations/fr-FR/data/reusables/saml/about-saml-access-enterprise-account.md,broken liquid tags
|
||||
|
|
|
Загрузка…
Ссылка в новой задаче