> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Exécuter les vérifications de pull requests dans des bacs à sable
> Exécutez les tests d’un dépôt dans des bacs à sable CoreWeave depuis GitHub Actions, avec une revue IA consultative facultative.
Exécutez les tests de pull requests dans un sandbox CoreWeave neuf, tandis que GitHub Actions se charge de l’orchestration et des rapports. Ce tutoriel s’adresse aux développeurs qui utilisent déjà GitHub Actions. Le code et les dépendances du dépôt s’exécutent en dehors de l’exécuteur d’intégration continue (CI).
Vous allez exécuter un exemple en local, tester un dépôt public à un commit précis, puis installer un flux de travail qui publie les résultats des tests sur les pull requests. La [recette GitHub Actions](https://github.com/coreweave/cwsandbox-recipes/tree/main/recipes/github-actions) contient le script complet, le flux de travail, un projet d’exemple et les tests. Vous pouvez copier la recette dans un autre dépôt et l’exécuter de manière autonome.
L’orchestrateur, qu’il s’agisse de votre machine ou de l’exécuteur CI, conserve l’identifiant d’authentification CoreWeave et crée un sandbox sans serveur par run. Le sandbox récupère le code source public et exécute la commande de test. Une revue IA facultative envoie le diff et la sortie des tests à Anthropic depuis l’orchestrateur. La recette ne transmet aucune clé API au sandbox.
Prérequis
Avant de commencer, préparez les éléments suivants :
* Un jeton d’accès à l’API CoreWeave disposant de l’action de gestion des identités et des accès (IAM) `SANDBOX_USER`. Voir [Gérer les jetons d’accès à l’API](/security/authn-authz/manage-api-access-tokens).
* Un accès aux sandbox sans serveur et une capacité disponible de 1 CPU et 2 Gio de mémoire. Voir [Premiers pas](/fr/products/sandboxes/get-started).
* [Git](https://git-scm.com/downloads), [`uv`](https://docs.astral.sh/uv/getting-started/installation/) et Python 3.11 ou version ultérieure. Vous pouvez utiliser `uv` pour installer Python.
* Un dépôt GitHub public dans lequel vous pouvez ajouter un flux de travail et un secret Actions.
* Une [clé API Anthropic](https://console.anthropic.com/settings/keys) (facultatif) pour la revue par IA, à titre consultatif.
Chaque run demande 1 CPU et 2 Gio de mémoire pendant 15 minutes au maximum. Le script arrête la sandbox à la fin de son exécution. La revue par IA est également décomptée de votre utilisation de l’API Anthropic.
Cette recette utilise explicitement un jeton d’accès à l’API CoreWeave. Pour connaître les options d’authentification, voir [Choisir et obtenir des identifiants d’authentification](/fr/products/sandboxes/placement#choose-and-get-credentials).
Exécuter l’exemple
Utilisez l’exemple inclus pour vérifier l’authentification, l’exécution à distance et le nettoyage avant de connecter votre dépôt.
1. Clonez le dépôt de recettes et installez les dépendances verrouillées :
```bash theme={"system"}
git clone https://github.com/coreweave/cwsandbox-recipes.git
cd cwsandbox-recipes/recipes/github-actions
uv sync --locked
```
2. Définissez votre jeton CoreWeave. Remplacez `[API-ACCESS-TOKEN]` par la valeur secrète de votre jeton :
```bash theme={"system"}
export CWSANDBOX_API_KEY="[API-ACCESS-TOKEN]"
```
3. Exécutez l’exemple et examinez le résultat :
```bash theme={"system"}
uv run --locked python run.py
cat outputs/result.json
```
Le terminal doit afficher `Status: passed`. Le fichier de résultat contient `returncode: 0` et `stopped: true`. L’exemple teste une addition et vérifie que l’environnement de bac à sable ne contient pas les clés CoreWeave, GitHub ou Anthropic de l’orchestrateur.
4. Vérifiez le scénario d’échec :
```bash theme={"system"}
uv run --locked python run.py \
--command 'python -c "raise SystemExit(7)"' \
--output outputs/failure
```
Cette commande se termine volontairement avec le statut `1`. Le fichier de résultat contient `status: failed`, le `returncode: 7` du test et `stopped: true`.
Tester un commit de dépôt
Depuis le répertoire de la recette, récupérez un commit précis de MarkupSafe, installez les dépendances, puis exécutez `pytest` dans la sandbox :
```bash theme={"system"}
uv run --locked python run.py \
--repo pallets/markupsafe \
--head b2e4d9c7687be25695fffbe93a37622302b24fb1 \
--command 'pip install . pytest==8.4.2 && python -m pytest -q' \
--timeout 300 \
--output outputs/repository
```
Le résultat attendu est `Status: passed`. Pour votre projet, remplacez le dépôt, le hash de commit complet et la commande de test. Pour que la vérification échoue en cas d’échec de l’installation des dépendances, placez `&&` entre la commande d’installation et la commande de test.
La recette utilise `python:3.12-bookworm`. Si votre projet nécessite une autre chaîne d’outils, modifiez le paramètre `container_image` dans le fichier `run.py`.
La recette effectue elle-même le checkout du commit de tête. Elle ne teste pas le commit de fusion synthétique de GitHub. Le script d’orchestration s’exécute sur la machine locale ou sur l’exécuteur CI, tandis que le checkout du dépôt et la commande de test s’exécutent dans la sandbox.
Facultatif : ajouter une revue par IA
Dans l’environnement de l’orchestrateur, définissez la variable d’environnement `ANTHROPIC_API_KEY`, puis ajoutez `--base [BASE-COMMIT-SHA] --review` à la commande de votre dépôt. Remplacez `[BASE-COMMIT-SHA]` par le hash de commit complet (40 caractères) de la révision de base, situé dans le même dépôt. Le README de la recette fournit un exemple complet et exécutable.
Le script récupère les deux révisions et calcule `git diff BASE...HEAD`. Il envoie à Anthropic au maximum 24 000 caractères pour chacun des éléments suivants : le diff, la sortie standard et la sortie d’erreur standard. Le modèle n’a accès à aucun outil. Le script enregistre sa réponse sous forme de texte indicatif, destiné à être relu par un humain. Si la requête de revue échoue, le champ `review_error` consigne le type d’erreur, et le résultat du test reste inchangé.
Ajouter le flux de travail GitHub Actions
Réservez ce flux de travail aux contributeurs de confiance du dépôt. La définition du flux de travail provient de la réf. de fusion de la pull request. Une pull request issue du même dépôt peut donc modifier le flux de travail, la commande de test, la réf. d’extraction et l’utilisation des secrets. Même si vous extrayez les fichiers de la branche de base, la pull request peut toujours apporter ces modifications.
Conservez le déclencheur `pull_request`. Si vous le remplacez par `pull_request_target`, vous devez concevoir un modèle de sécurité distinct.
Pour exécuter ces vérifications sur les pull requests, installez la recette dans votre dépôt public :
1. À la racine de votre dépôt public, copiez les fichiers d’exécution et le flux de travail. Remplacez `[RECIPES-CHECKOUT]` par le chemin de votre clone des recettes :
```bash theme={"system"}
recipe_dir="[RECIPES-CHECKOUT]/recipes/github-actions"
mkdir -p ci/sandbox .github/workflows
cp "$recipe_dir/run.py" "$recipe_dir/pyproject.toml" \
"$recipe_dir/uv.lock" "$recipe_dir/.gitignore" ci/sandbox/
cp "$recipe_dir/workflow.yml" .github/workflows/sandbox-ci.yml
```
Laissez les répertoires `tests/` et `sample/` de la recette dans le clone des recettes afin que l’exécuteur de tests de votre projet ne les collecte pas. Les fichiers copiés prennent en charge le mode dépôt. Exécutez l’exemple inclus depuis le clone des recettes.
2. Examinez le [fichier `workflow.yml`](https://github.com/coreweave/cwsandbox-recipes/blob/main/recipes/github-actions/workflow.yml) copié dans `.github/workflows/sandbox-ci.yml`.
3. Définissez l’option `--command` du flux de travail sur la commande d’installation des dépendances et de test de votre projet.
4. Ajoutez un secret de dépôt Actions nommé `CWSANDBOX_API_KEY` contenant votre jeton CoreWeave. Voir [Utilisation de secrets dans GitHub Actions](https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets).
5. Fusionnez le flux de travail et les fichiers `ci/sandbox/` dans votre branche de base cible. Le flux de travail charge l’orchestration depuis le commit de base de la pull request. Ces fichiers doivent donc s’y trouver avant que vous ne testiez une pull request.
6. Ouvrez ou mettez à jour une pull request issue du même dépôt.
Le flux de travail **Sandbox CI** s’exécute lors des événements `opened`, `synchronize` et `reopened`. Le flux de travail fourni extrait le fichier `run.py` et ses fichiers de dépendances depuis le commit de base. Il transmet à la sandbox le hash du commit de tête de la pull request. Il demande l’autorisation `contents: read` et désactive la conservation des identifiants d’authentification utilisés pour l’extraction.
Le flux de travail fourni ignore les pull requests issues de forks, les pull requests Dependabot et les dépôts privés. GitHub ne transmet pas les secrets du dépôt aux flux de travail déclenchés par des pull requests issues de forks ou de Dependabot. Une tâche ignorée satisfait une vérification de statut requise : rendre cette vérification obligatoire ne garantit donc pas l’exécution des tests pour les pull requests ignorées. Voir [Gestion des vérifications ignorées mais requises](https://docs.github.com/en/pull-requests/how-tos/merge-and-close-pull-requests/troubleshooting-required-status-checks#handling-skipped-but-required-checks).
Pour activer la revue facultative par IA dans Actions, suivez les instructions de la recette afin d’ajouter le secret Anthropic à l’étape de test et d’activer `--review`.
Examiner les résultats
Pour lire la synthèse de la tâche, ouvrez la vérification **Sandbox CI**. Téléchargez l’artifact **`sandbox-ci-results`** pour obtenir les fichiers `result.json` et `summary.md`. Le flux de travail téléverse les résultats même lorsque les tests échouent et conserve les artifacts pendant 7 jours.
Le fichier de résultats contient le commit testé, l’ID de la sandbox, le code de retour des tests, la sortie capturée et le résultat du nettoyage. Pour la sortie standard comme pour la sortie d’erreur standard, le script conserve les 24 000 derniers caractères, afin que les messages d’échec situés en fin de sortie restent disponibles. Il échappe le texte renvoyé dans la synthèse et n’affiche pas directement la sortie des tests dans la console de l’exécuteur CI. En cas d’échec, une annotation d’erreur au texte fixe renvoie vers la synthèse de la tâche et l’artifact.
Une exécution de tests réussie se termine avec le code `0`. Les échecs de tests, les erreurs de configuration, les dépassements de délai d’expiration et les erreurs de nettoyage se terminent avec le code `1`. La revue par IA est purement indicative et ne modifie pas ce résultat. La réussite d’une suite de tests ne constitue pas une évaluation de la sécurité du code soumis.
L’option `--timeout` accepte une valeur comprise entre 1 et 300 secondes (120 secondes par défaut). La sandbox est par ailleurs soumise à une durée de vie maximale de 900 secondes.
La recette place la sortie des commandes en mémoire tampon avant de la tronquer ; réservez-la donc aux petits dépôts et aux suites de tests qui produisent peu de sortie. En cas de dépassement du délai d’expiration, le script enregistre `status: error` et `error: SandboxTimeoutError`, sans sortie partielle de la commande. Pour les délais d’expiration de configuration et les autres limites, consultez le README de la recette.
Nettoyage
Le script appelle `stop(missing_ok=True)` dans un bloc `finally`, que le run réussisse ou échoue. Si l’orchestrateur est arrêté avant le nettoyage, la durée de vie maximale borne l’exécution. La recette ne crée aucun instantané, volume ni exécuteur de sandbox.
Si le champ `cleanup_error` figure dans le résultat, supprimez la sandbox à l’aide de la commande de nettoyage de la recette, en utilisant l’ID de sandbox enregistré et le même identifiant d’authentification CoreWeave. Pour d’autres modèles, consultez [Modèles de nettoyage](/fr/products/sandboxes/client/guides/cleanup-patterns).
Conservez les fichiers de résultats dont vous avez besoin, puis supprimez le répertoire local `outputs/`. Lorsque vous ne souhaitez plus que les pull requests créent des bacs à sable, supprimez ou désactivez le flux de travail.