Amazon n' CodeCatalyst est plus ouvert aux nouveaux clients. Les clients existants peuvent continuer à utiliser le service normalement. Pour de plus amples informations, veuillez consulter [Comment effectuer une migration depuis CodeCatalyst](migration.md).
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Configuration des actions du flux de travail
Une *action* est le principal élément constitutif d'un flux de travail et définit une unité logique de travail, ou tâche, à exécuter lors de l'exécution d'un flux de travail. Généralement, un flux de travail inclut plusieurs actions qui s'exécutent de manière séquentielle ou en parallèle selon la façon dont vous les avez configurées.
**Topics**
+ [Types d'action](#workflows-actions-types)
+ [Ajouter une action à un flux de travail](workflows-add-action.md)
+ [Supprimer une action d'un flux de travail](workflows-delete-action.md)
+ [Développement d'une action personnalisée](workflows-custom-action.md)
+ [Regrouper les actions dans des groupes d'action](workflows-group-actions.md)
+ [Actions de séquençage](workflows-depends-on.md)
+ [Partage d'artefacts et de fichiers entre les actions](workflows-working-artifacts.md)
+ [Spécification de la version de l'action à utiliser](workflows-action-versions.md)
+ [Liste des versions d'action disponibles](workflows-action-versions-determine.md)
+ [Afficher le code source d'une action](workflows-view-source.md)
+ [Intégration aux GitHub actions](integrations-github-actions.md)
## Types d'action
Dans un CodeCatalyst flux de travail Amazon, vous pouvez utiliser les types d'actions suivants.
**Topics**
+ [CodeCatalyst actions](#workflows-actions-types-cc)
+ [CodeCatalyst Actions menées par les laboratoires](#workflows-actions-types-cc-labs)
+ [GitHub Actions](#workflows-actions-types-github)
+ [Actions tierces](#workflows-actions-types-3p)
### CodeCatalyst actions
Une *CodeCatalyst action* est une action créée, gérée et entièrement prise en charge par l'équipe de CodeCatalyst développement.
Il existe CodeCatalyst des actions pour créer, tester et déployer des applications, ainsi que pour effectuer diverses tâches, telles que l'appel d'une AWS Lambda fonction.
Les CodeCatalyst actions disponibles sont les suivantes :
+ **Build**
Cette action crée vos artefacts et exécute vos tests unitaires dans un conteneur Docker. Pour de plus amples informations, veuillez consulter [Ajouter l'action de construction](build-add-action.md).
+ **Test**
Cette action exécute des tests d'intégration et de système par rapport à votre application ou à vos artefacts. Pour de plus amples informations, veuillez consulter [Ajouter l'action de test](test-add-action.md).
+ **Publication d'Amazon S3**
Cette action copie les artefacts de votre application dans un compartiment Amazon S3. Pour de plus amples informations, veuillez consulter [Publication de fichiers sur Amazon S3 à l'aide d'un flux de travail](s3-pub-action.md).
+ **AWS CDK bootstrap**
Cette action fournit les ressources dont ils ont AWS CDK besoin pour déployer votre application CDK. Pour de plus amples informations, veuillez consulter [Démarrage d'une AWS CDK application à l'aide d'un flux de travail](cdk-boot-action.md).
+ **AWS CDK déployer**
Cette action synthétise et déploie une AWS Cloud Development Kit (AWS CDK) application. Pour de plus amples informations, veuillez consulter [Déploiement d'une AWS CDK application avec un flux de travail](cdk-dep-action.md).
+ **AWS Lambda invoquer**
Cette action appelle une AWS Lambda fonction. Pour de plus amples informations, veuillez consulter [Invocation d'une fonction Lambda à l'aide d'un flux de travail](lam-invoke-action.md).
+ **GitHub Actions**
Cette action vous permet *CodeCatalyst*d'exécuter des GitHub actions dans un CodeCatalyst flux de travail. Pour de plus amples informations, veuillez consulter [Invocation d'une fonction Lambda à l'aide d'un flux de travail](lam-invoke-action.md).
+ **Déployer CloudFormation une pile**
Cette action déploie des CloudFormation piles. Pour de plus amples informations, veuillez consulter [Déploiement d'une CloudFormation pile](deploy-action-cfn.md).
+ **Déploiement sur Amazon ECS**
Cette action enregistre une définition de tâche Amazon ECS et la déploie sur un service Amazon ECS. Pour de plus amples informations, veuillez consulter [Déploiement sur Amazon ECS à l'aide d'un flux de travail](deploy-action-ecs.md).
+ **Déploiement sur un cluster Kubernetes**
Cette action déploie une application sur un cluster Kubernetes. Pour de plus amples informations, veuillez consulter [Déploiement sur Amazon EKS à l'aide d'un flux de travail](deploy-action-eks.md).
+ **Afficher la définition de la tâche Amazon ECS**
Cette action insère un URI d'image de conteneur dans un fichier JSON de définition de tâche Amazon ECS, créant ainsi un nouveau fichier de définition de tâche. Pour de plus amples informations, veuillez consulter [Modification d'une définition de tâche Amazon ECS](render-ecs-action.md).
La documentation des CodeCatalyst actions est disponible dans ce guide et dans le fichier readme de chaque action.
Pour plus d'informations sur les CodeCatalyst actions disponibles et sur la façon d'en ajouter une à un flux de travail, consultez[Ajouter une action à un flux de travail](workflows-add-action.md).
### CodeCatalyst Actions menées par les laboratoires
Une *action CodeCatalyst Labs* est une action qui fait partie d'Amazon CodeCatalyst Labs, un terrain d'essai pour les applications expérimentales. CodeCatalyst Des actions de laboratoire ont été développées pour présenter les intégrations aux AWS services.
Les actions CodeCatalyst Labs suivantes sont disponibles :
+ **Déployer vers un AWS Amplify hébergement**
Cette action déploie une application sur Amplify Hosting.
+ **Déployer vers AWS App Runner**
Cette action déploie la dernière image d'un référentiel d'images source dans App Runner.
+ **Déploiement sur Amazon CloudFront et Amazon S3**
Cette action déploie une application vers Amazon S3 CloudFront et Amazon S3.
+ **Déployez avec AWS SAM**
Cette action déploie votre application sans serveur avec AWS Serverless Application Model ()AWS SAM.
+ **Invalider Amazon Cache CloudFront **
Cette action invalide un CloudFront cache pour un ensemble de chemins donné.
+ **Webhook sortant**
Cette action permet aux utilisateurs d'envoyer des messages dans un flux de travail à un serveur Web arbitraire à l'aide d'une requête HTTPS.
+ **Publier sur AWS CodeArtifact**
Cette action publie des packages dans un CodeArtifact référentiel.
+ **Publier sur Amazon SNS**
Cette action permet aux utilisateurs d'intégrer Amazon SNS en créant une rubrique, en publiant sur une rubrique ou en s'abonnant à une rubrique.
+ **Envoyer vers Amazon ECR**
Cette action crée et publie une image Docker dans un référentiel Amazon Elastic Container Registry (Amazon ECR).
+ **Scannez avec Amazon CodeGuru Security**
Cette action crée une archive zip d'un chemin de code configuré et utilise CodeGuru Security pour exécuter un scan de code.
+ **Édition communautaire Terraform**
Cette action exécute Terraform Community Edition `plan` et `apply` ses opérations.
La documentation des actions CodeCatalyst Labs est disponible dans le fichier readme de chaque action.
Pour plus d'informations sur l'ajout d'une action CodeCatalyst Labs à un flux de travail et l'affichage de son fichier readme, consultez[Ajouter une action à un flux de travail](workflows-add-action.md).
### GitHub Actions
Une *GitHub action* ressemble beaucoup à une [CodeCatalyst action](#workflows-actions-types-cc), sauf qu'elle a été développée pour être utilisée avec des GitHub flux de travail. Pour plus de détails sur GitHub les actions, consultez la documentation sur [GitHub les actions](https://docs.github.com/en/actions).
Vous pouvez utiliser GitHub des actions parallèlement à des CodeCatalyst actions natives dans un CodeCatalyst flux de travail.
Pour vous faciliter la tâche, la CodeCatalyst console donne accès à plusieurs GitHub actions populaires. Vous pouvez également utiliser n'importe quelle GitHub action répertoriée [GitHub sur le Marketplace](https://github.com/marketplace/actions) (sous réserve de quelques restrictions).
La documentation relative aux GitHub actions est disponible dans le fichier readme de chaque action.
Pour de plus amples informations, veuillez consulter [Intégration aux GitHub actions](integrations-github-actions.md).
### Actions tierces
Une *action tierce* est une action créée par un fournisseur tiers et mise à disposition dans la CodeCatalyst console. Les actions **Mend SCA et **SonarCloud Scan**, créées respectivement par Mend** et Sonar, sont des exemples d'actions tierces.
La documentation relative aux actions tierces est disponible dans le fichier readme de chaque action. Une documentation supplémentaire peut également être fournie par le fournisseur tiers.
Pour plus d'informations sur l'ajout d'une action tierce à un flux de travail et l'affichage de son fichier readme, consultez[Ajouter une action à un flux de travail](workflows-add-action.md).
# Ajouter une action à un flux de travail
Suivez les instructions ci-dessous pour ajouter une action à un flux de travail, puis le configurer.
**Pour ajouter et configurer une action**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. En haut à gauche, choisissez **\$1 Actions**. Le catalogue d'**actions** apparaît.
1. Dans la liste déroulante, effectuez l'une des opérations suivantes :
+ Choisissez **Amazon CodeCatalyst** pour afficher [CodeCatalyst](workflows-actions.md#workflows-actions-types-cc), [CodeCatalyst Labs](workflows-actions.md#workflows-actions-types-cc-labs) ou les actions de [tiers](workflows-actions.md#workflows-actions-types-3p).
+ CodeCatalyst **les actions ont une AWSétiquette secondaire.**
+ CodeCatalyst Les actions des laboratoires portent le label **by CodeCatalyst Labs**.
+ Les actions de tiers sont **associées** à un *vendor* sous-label, où *vendor* figure le nom du fournisseur tiers.
+ Choisissez **GitHub**d'afficher une [liste organisée d' GitHub actions](integrations-github-action-add-curated.md).
1. Dans le catalogue d'actions, recherchez une action, puis effectuez l'une des opérations suivantes :
+ Choisissez le signe plus (**\$1**) pour ajouter l'action à votre flux de travail.
+ Choisissez le nom de l'action pour afficher son fichier readme.
1. Configurez l'action. Choisissez **Visual** pour utiliser l'éditeur visuel ou **YAML** pour utiliser l'éditeur YAML. Pour obtenir des instructions détaillées, consultez les liens suivants.
Pour obtenir des instructions sur l'ajout d'[CodeCatalystactions](workflows-actions.md#workflows-actions-types-cc), voir :
+ [Ajouter l'action de construction](build-add-action.md)
+ [Ajouter l'action de test](test-add-action.md)
+ [Ajout de l'action « Déployer sur Amazon ECS »](deploy-action-ecs-adding.md)
+ [Ajout de l'action « Déployer vers le cluster Kubernetes »](deploy-action-eks-adding.md)
+ [Ajout de l'action « Déployer la CloudFormation pile »](deploy-action-cfn-adding.md)
+ [Ajouter l'action « AWS CDK déployer »](cdk-dep-action-add.md)
+ [Ajouter l'action « AWS CDK bootstrap »](cdk-boot-action-add.md)
+ [Ajout de l'action « Publication Amazon S3 »](s3-pub-action-add.md)
+ [Ajouter l'action « AWS Lambda invoquer »](lam-invoke-action-add.md)
+ [Ajout de l'action « Render la définition de tâche Amazon ECS »](render-ecs-action-add.md)
Pour obtenir des instructions sur l'ajout d'[actions CodeCatalyst Labs](workflows-actions.md#workflows-actions-types-cc-labs), voir :
+ L'action est readme. Vous pouvez trouver le fichier readme en choisissant le nom de l'action dans le catalogue d'actions.
Pour obtenir des instructions sur l'ajout d'[GitHub actions](workflows-actions.md#workflows-actions-types-github), voir :
+ [Intégration aux GitHub actions](integrations-github-actions.md)
Pour obtenir des instructions sur l'ajout d'[actions tierces](workflows-actions.md#workflows-actions-types-3p), voir :
+ L'action est readme. Vous pouvez trouver le fichier readme en choisissant le nom de l'action dans le catalogue d'actions.
1. (Facultatif) Choisissez **Valider** pour vous assurer que le code YAML est valide.
1. Choisissez **Valider** pour valider vos modifications.
# Supprimer une action d'un flux de travail
Suivez les instructions ci-dessous pour supprimer une action d'un flux de travail.
------
#### [ Visual ]
**Pour supprimer une action à l'aide de l'éditeur visuel**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **Visual**.
1. Dans le diagramme du flux de travail, dans l'action que vous souhaitez supprimer, cliquez sur l'icône représentant des points de suspension verticaux (![\[Ellipsis.\]](http://docs.aws.amazon.com/fr_fr/codecatalyst/latest/userguide/images/flows/elipsis.png)), puis sur **Supprimer**.
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
#### [ YAML ]
**Pour supprimer une action à l'aide de l'éditeur YAML**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **YAML.**
1. Recherchez la section du code YAML qui contient l'action que vous souhaitez supprimer.
Sélectionnez la section et appuyez sur la touche de suppression de votre clavier.
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
# Développement d'une action personnalisée
Vous pouvez développer une action personnalisée à utiliser dans vos flux de travail à l'aide du kit de développement CodeCatalyst d'actions (ADK). Vous pouvez ensuite publier l'action dans le catalogue d' CodeCatalyst actions afin que CodeCatalyst les autres utilisateurs puissent la consulter et l'utiliser dans leurs flux de travail.
**Pour développer, tester et publier une action (tâches de haut niveau)**
1. Installez les outils et packages nécessaires au développement d'une action.
1. Créez un CodeCatalyst référentiel pour stocker votre code d'action.
1. Initialisez l'action. Cela définit les fichiers source requis par l'action, y compris un fichier de définition d'action (`action.yml`) que vous pouvez mettre à jour avec votre propre code.
1. Démarrez le code d'action pour obtenir les outils et les bibliothèques nécessaires pour créer, tester et publier le projet d'action.
1. Créez l'action sur votre ordinateur local et transférez les modifications vers votre CodeCatalyst référentiel.
1. Testez l'action avec des tests unitaires en local et exécutez le flux de travail généré par ADK dans. CodeCatalyst
1. Publiez l'action dans le catalogue d' CodeCatalyst actions en cliquant sur le bouton **Publier** dans la CodeCatalyst console.
Pour connaître les étapes détaillées, consultez le [guide du développeur Amazon CodeCatalyst Action Development Kit](https://docs.aws.amazon.com/codecatalyst/latest/adk/what-is-action-development-kit.html).
# Regrouper les actions dans des groupes d'action
Un *groupe d'actions* contient une ou plusieurs actions. Le regroupement des actions dans des groupes d'actions vous aide à organiser votre flux de travail et vous permet également de configurer les dépendances entre les différents groupes.
**Note**
Vous ne pouvez pas imbriquer des groupes d'actions dans d'autres groupes d'actions ou d'autres actions.
**Topics**
+ [Définition d'un groupe d'action](#workflows-define-action-group)
+ [Exemple : définition de deux groupes d'action](workflows-group-actions-example.md)
## Définition d'un groupe d'action
Suivez les instructions ci-dessous pour définir un groupe CodeCatalyst d'actions.
------
#### [ Visual ]
*Non disponible Choisissez YAML pour afficher les instructions YAML.*
------
#### [ YAML ]
**Pour définir un groupe**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **YAML.**
1. Dans`Actions`, ajoutez un code similaire au suivant :
```
Actions:
action-group-name:
Actions:
action-1:
Identifier: aws/build@v1
Configuration:
...
action-2:
Identifier: aws/build@v1
Configuration:
...
```
Pour obtenir un autre exemple, consultez [Exemple : définition de deux groupes d'action](workflows-group-actions-example.md). Pour plus d'informations, consultez la description [Actions](workflow-reference.md#actions-reference) de la `action-group-name` propriété dans le[Définition du flux de travail YAML](workflow-reference.md).
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
# Exemple : définition de deux groupes d'action
L'exemple suivant montre comment définir deux groupes CodeCatalyst d'actions Amazon : `BuildAndTest` et`Deploy`. Le `BuildAndTest` groupe comprend deux actions (`Build`et`Test`), et le `Deploy` groupe comprend également deux actions (`DeployCloudFormationStack`et`DeployToECS`).
```
Actions:
BuildAndTest: # Action group 1
Actions:
Build:
Identifier: aws/build@v1
Configuration:
...
Test:
Identifier: aws/managed-test@v1
Configuration:
Deploy: #Action group 2
Actions:
DeployCloudFormationStack:
Identifier: aws/cfn-deploy@v1
Configuration:
...
DeployToECS:
Identifier: aws/ecs-deploy@v1
Configuration:
...
```
# Actions de séquençage
Par défaut, lorsque vous ajoutez des actions à un flux de travail, elles sont ajoutées côte à côte dans l'[éditeur visuel](workflow.md#workflow.editors). Cela signifie que les actions s'exécuteront en parallèle lorsque vous lancerez une exécution de flux de travail. Si vous souhaitez que les actions s'exécutent dans un ordre séquentiel (et apparaissent verticalement dans l'éditeur visuel), vous devez définir des dépendances entre elles. Par exemple, vous pouvez configurer une `Test` action pour qu'elle dépende de l'`Build`action afin que l'action de test soit exécutée après l'action de génération.
Vous pouvez configurer des dépendances entre les actions et les groupes d'actions. Vous pouvez également configurer one-to-many les dépendances afin qu'une action dépende de plusieurs autres pour démarrer. Consultez les directives ci-dessous pour vous [Configuration des dépendances entre les actions](workflows-depends-on-set-up.md) assurer que la configuration de vos dépendances est conforme à la syntaxe YAML du flux de travail.
**Topics**
+ [Exemples de configuration des dépendances entre les actions](workflows-depends-on-examples.md)
+ [Configuration des dépendances entre les actions](workflows-depends-on-set-up.md)
# Exemples de configuration des dépendances entre les actions
Les exemples suivants montrent comment configurer les dépendances entre les actions et les groupes dans le fichier de définition du flux de travail.
**Topics**
+ [Exemple : Configuration d'une dépendance simple](#workflows-depends-on-example-simple)
+ [Exemple : Configuration d'un groupe d'actions pour qu'il dépende d'une action](#workflows-depends-on-example-action-groups-actions)
+ [Exemple : Configuration d'un groupe d'actions pour qu'il dépende d'un autre groupe d'actions](#workflows-depends-on-example-two-action-groups)
+ [Exemple : Configuration d'un groupe d'actions pour qu'il dépende de plusieurs actions](#workflows-depends-on-example-advanced)
## Exemple : Configuration d'une dépendance simple
L'exemple suivant montre comment configurer une `Test` action pour qu'elle dépende de l'`Build`action utilisant la `DependsOn` propriété.
```
Actions:
Build:
Identifier: aws/build@v1
Configuration:
...
Test:
DependsOn:
- Build
Identifier: aws/managed-test@v1
Configuration:
...
```
## Exemple : Configuration d'un groupe d'actions pour qu'il dépende d'une action
L'exemple suivant montre comment configurer un groupe d'`DeployGroup`actions pour qu'il dépende de l'`FirstAction`action. Notez que l'action et le groupe d'actions sont au même niveau.
```
Actions:
FirstAction: #An action outside an action group
Identifier: aws/github-actions-runner@v1
Configuration:
...
DeployGroup: #An action group containing two actions
DependsOn:
- FirstAction
Actions:
DeployAction1:
...
DeployAction2:
...
```
## Exemple : Configuration d'un groupe d'actions pour qu'il dépende d'un autre groupe d'actions
L'exemple suivant montre comment configurer un groupe d'`DeployGroup`actions pour qu'il dépende du groupe `BuildAndTestGroup` d'actions. Notez que les groupes d'action sont au même niveau.
```
Actions:
BuildAndTestGroup: # Action group 1
Actions:
BuildAction:
...
TestAction:
...
DeployGroup: #Action group 2
DependsOn:
- BuildAndTestGroup
Actions:
DeployAction1:
...
DeployAction2:
...
```
## Exemple : Configuration d'un groupe d'actions pour qu'il dépende de plusieurs actions
L'exemple suivant montre comment configurer un groupe d'`DeployGroup`actions pour qu'il dépende de l'`SecondAction`action, de l'action et du groupe `BuildAndTestGroup` d'actions. `FirstAction` Notez que `DeployGroup` c'est au même niveau que `FirstAction``SecondAction`, et`BuildAndTestGroup`.
```
Actions:
FirstAction: #An action outside an action group
...
SecondAction: #Another action
...
BuildAndTestGroup: #Action group 1
Actions:
Build:
...
Test:
...
DeployGroup: #Action group 2
DependsOn:
- FirstAction
- SecondAction
- BuildAndTestGroup
Actions:
DeployAction1:
...
DeployAction2:
...
```
# Configuration des dépendances entre les actions
Utilisez les instructions suivantes pour configurer les dépendances entre les actions d'un flux de travail.
Lors de la configuration des dépendances, suivez les instructions suivantes :
+ Si une action se trouve au sein d'un groupe, elle ne peut dépendre que d'autres actions au sein du même groupe.
+ Les actions et les groupes d'actions peuvent dépendre d'autres actions et groupes d'actions *situés au même niveau* dans la hiérarchie YAML, mais *pas* à un niveau différent.
------
#### [ Visual ]
**Pour configurer les dépendances à l'aide de l'éditeur visuel**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **Visual**.
1. Dans le diagramme du flux de travail, choisissez l'action qui dépendra d'une autre action.
1. Sélectionnez l’onglet **Entrées**.
1. Dans **Depends on - facultatif**, procédez comme suit :
Spécifiez une action, un groupe d'actions ou une porte qui doit s'exécuter correctement pour que cette action soit exécutée.
Pour plus d'informations sur la fonctionnalité « dépend », consultez. [Actions de séquençage](workflows-depends-on.md)
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
#### [ YAML ]
**Pour configurer les dépendances à l'aide de l'éditeur YAML**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **YAML.**
1. Dans une action qui dépendra d'une autre, ajoutez un code similaire au suivant :
```
action-name:
DependsOn:
- action-1
```
Pour obtenir plus d’exemples, consultez [Exemples de configuration des dépendances entre les actions](workflows-depends-on-examples.md). Pour les directives générales, voir[Configuration des dépendances entre les actions](#workflows-depends-on-set-up). Pour plus d'informations, consultez la description de la `DependsOn` propriété dans le champ [Définition du flux de travail YAML](workflow-reference.md) correspondant à votre action.
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
# Partage d'artefacts et de fichiers entre les actions
Un *artefact* est le résultat d'une action de flux de travail et consiste généralement en un dossier ou une archive de fichiers. Les artefacts sont importants car ils vous permettent de partager des fichiers et des informations entre les actions.
Par exemple, vous pouvez avoir une action de génération qui *génère* un `sam-template.yml` fichier, mais vous souhaitez qu'une action de déploiement *l'utilise*. Dans ce scénario, vous utiliseriez un artefact pour permettre à l'action de génération de partager le `sam-template.yml` fichier avec l'action de déploiement. Le code pourrait ressembler à ceci :
```
Actions:
BuildAction:
Identifier: aws/build@v1
Steps:
- Run: sam package --output-template-file sam-template.yml
Outputs:
Artifacts:
- Name: MYARTIFACT
Files:
- sam-template.yml
DeployAction:
Identifier: aws/cfn-deploy@v1
Inputs:
Artifacts:
- MYARTIFACT
Configuration:
template: sam-template.yml
```
Dans le code précédent, l'action de construction (`BuildAction`) génère un `sam-template.yml` fichier, puis l'ajoute à un artefact de sortie appelé`MYARTIFACT`. Une action de déploiement ultérieure (`DeployAction`) est spécifiée `MYARTIFACT` en entrée, lui donnant accès au `sam-template.yml` fichier.
**Topics**
+ [Puis-je partager des artefacts sans les spécifier comme sorties et entrées ?](#workflows-working-artifacts-share)
+ [Puis-je partager des artefacts entre les flux de travail ?](#workflows-working-artifacts-share-wf)
+ [Exemples d'artefacts](workflows-working-artifacts-ex.md)
+ [Définition d'un artefact de sortie](workflows-working-artifacts-output.md)
+ [Définition d'un artefact d'entrée](workflows-working-artifacts-refer.md)
+ [Référencement de fichiers dans un artefact](workflows-working-artifacts-refer-files.md)
+ [Téléchargement d'artefacts](workflows-download-workflow-outputs.md)
## Puis-je partager des artefacts sans les spécifier comme sorties et entrées ?
Oui, vous pouvez partager des artefacts entre des actions sans les spécifier dans les `Inputs` sections `Outputs` et du code YAML de vos actions. Pour ce faire, vous devez activer le partage de calcul. Pour plus d'informations sur le partage de calcul et sur la manière de spécifier des artefacts lorsqu'il est activé, consultez[Partage du calcul entre les actions](compute-sharing.md).
**Note**
Bien que la fonctionnalité de partage de calcul vous permette de simplifier le code YAML de votre flux de travail en éliminant le besoin de `Inputs` sections `Outputs` et, cette fonctionnalité présente des limites que vous devez connaître avant de l'activer. Pour plus d'informations sur ces limitations, consultez[Considérations relatives au partage du calcul](compute-sharing.md#compare-compute-sharing).
## Puis-je partager des artefacts entre les flux de travail ?
Non, vous ne pouvez pas partager d'artefacts entre différents flux de travail ; toutefois, vous pouvez partager des artefacts entre des actions au sein d'un même flux de travail.
# Exemples d'artefacts
Les exemples suivants montrent comment générer, saisir et référencer des artefacts dans le fichier de définition du CodeCatalyst flux de travail Amazon.
**Topics**
+ [Exemple : sortie d'un artefact](#workflows-working-artifacts-ex-basic)
+ [Exemple : saisie d'un artefact généré par une autre action](#workflows-working-artifacts-ex-ref)
+ [Exemple : Référencement de fichiers dans plusieurs artefacts](#workflows-working-artifacts-ex-ref-file)
+ [Exemple : Référencement d'un fichier dans un seul artefact](#workflows-working-artifacts-ex-ref-file-one)
+ [Exemple : Référencer un fichier dans un artefact en présence d'un WorkflowSource](#workflows-working-artifacts-ex-ref-file-wf-source)
+ [Exemple : Référencement d'un fichier dans un artefact lorsqu'un groupe d'action est présent](#workflows-working-artifacts-ex-groups)
## Exemple : sortie d'un artefact
L'exemple suivant montre comment générer un artefact qui inclut deux fichiers .jar.
```
Actions:
Build:
Identifier: aws/build@v1
Outputs:
Artifacts:
- Name: ARTIFACT1
Files:
- build-output/file1.jar
- build-output/file2.jar
```
## Exemple : saisie d'un artefact généré par une autre action
L'exemple suivant vous montre comment générer un artefact appelé `ARTIFACT4` in et `BuildActionA` le saisir dans`BuildActionB`.
```
Actions:
BuildActionA:
Identifier: aws/build@v1
Outputs:
Artifacts:
- Name: ARTIFACT4
Files:
- build-output/file1.jar
- build-output/file2.jar
BuildActionB:
Identifier: aws/build@v1
Inputs:
Artifacts:
- ARTIFACT4
Configuration:
```
## Exemple : Référencement de fichiers dans plusieurs artefacts
L'exemple suivant montre comment générer deux artefacts nommés `ART5` et `ART6` dans`BuildActionC`, puis référencer deux fichiers nommés `file5.txt` (dans artefact`ART5`) et `file6.txt` (dans artefact`ART6`) dans `BuildActionD` (sous`Steps`).
**Note**
Pour plus d'informations sur le référencement de fichiers, consultez[Référencement de fichiers dans un artefact](workflows-working-artifacts-refer-files.md).
**Note**
Bien que l'exemple montre le `$CATALYST_SOURCE_DIR_ART5` préfixe utilisé, vous pouvez l'omettre. C'est parce que `ART5` c'est l'*entrée principale*. Pour en savoir plus sur l'entrée principale, voir[Référencement de fichiers dans un artefact](workflows-working-artifacts-refer-files.md).
```
Actions:
BuildActionC:
Identifier: aws/build@v1
Outputs:
Artifacts:
- Name: ART5
Files:
- build-output/file5.txt
- Name: ART6
Files:
- build-output/file6.txt
BuildActionD:
Identifier: aws/build@v1
Inputs:
Artifacts:
- ART5
- ART6
Configuration:
Steps:
- run: cd $CATALYST_SOURCE_DIR_ART5/build-output && cat file5.txt
- run: cd $CATALYST_SOURCE_DIR_ART6/build-output && cat file6.txt
```
## Exemple : Référencement d'un fichier dans un seul artefact
L'exemple suivant vous montre comment générer un artefact nommé `ART7` dans`BuildActionE`, puis référencer `file7.txt` (dans artefact`ART7`) dans `BuildActionF` (sous`Steps`).
Remarquez que la référence ne nécessite pas le `$CATALYST_SOURCE_DIR_` *artifact-name* préfixe devant le `build-output` répertoire comme c'était le cas dans[Exemple : Référencement de fichiers dans plusieurs artefacts](#workflows-working-artifacts-ex-ref-file). Cela est dû au fait qu'un seul élément est spécifié sous`Inputs`.
**Note**
Pour plus d'informations sur le référencement de fichiers, consultez[Référencement de fichiers dans un artefact](workflows-working-artifacts-refer-files.md).
```
Actions:
BuildActionE:
Identifier: aws/build@v1
Outputs:
Artifacts:
- Name: ART7
Files:
- build-output/file7.txt
BuildActionF:
Identifier: aws/build@v1
Inputs:
Artifacts:
- ART7
Configuration:
Steps:
- run: cd build-output && cat file7.txt
```
## Exemple : Référencer un fichier dans un artefact en présence d'un WorkflowSource
L'exemple suivant vous montre comment générer un artefact nommé `ART8` dans`BuildActionG`, puis référencer `file8.txt` (dans artefact`ART8`) dans `BuildActionH` (sous`Steps`).
Remarquez que la référence nécessite le `$CATALYST_SOURCE_DIR_` *artifact-name* préfixe, comme c'était le cas dans[Exemple : Référencement de fichiers dans plusieurs artefacts](#workflows-working-artifacts-ex-ref-file). Cela est dû au fait que plusieurs éléments sont spécifiés sous `Inputs` (une source et un artefact). Vous avez donc besoin du préfixe pour indiquer où rechercher le fichier.
**Note**
Pour plus d'informations sur le référencement de fichiers, consultez[Référencement de fichiers dans un artefact](workflows-working-artifacts-refer-files.md).
```
Actions:
BuildActionG:
Identifier: aws/build@v1
Outputs:
Artifacts:
- Name: ART8
Files:
- build-output/file8.txt
BuildActionH:
Identifier: aws/build@v1
Inputs:
Sources:
- WorkflowSource
Artifacts:
- ART8
Configuration:
Steps:
- run: cd $CATALYST_SOURCE_DIR_ART8/build-output && cat file8.txt
```
## Exemple : Référencement d'un fichier dans un artefact lorsqu'un groupe d'action est présent
L'exemple suivant vous montre comment générer un artefact nommé `ART9` dans `ActionGroup1``ActionI`, puis référencer `file9.txt` (dans artefact`ART9`) dans. `ActionJ`
Pour plus d'informations sur le référencement de fichiers, consultez[Référencement de fichiers dans un artefact](workflows-working-artifacts-refer-files.md).
```
Actions:
ActionGroup1:
Actions:
ActionI:
Identifier: aws/build@v1
Outputs:
Artifacts:
- Name: ART9
Files:
- build-output/file9.yml
ActionJ:
Identifier: aws/cfn-deploy@v1
Inputs:
Sources:
- WorkflowSource
Artifacts:
- ART9
Configuration:
template: /artifacts/ActionGroup1@ActionJ/ART9/build-output/file9.yml
```
# Définition d'un artefact de sortie
Suivez les instructions suivantes pour définir un artefact que vous souhaitez qu'une CodeCatalyst action Amazon génère. Cet artefact devient alors disponible pour d'autres actions.
**Note**
Toutes les actions ne prennent pas en charge les artefacts de sortie. Pour déterminer si votre action les prend en charge, parcourez les instructions de l'éditeur visuel qui suivent et vérifiez si l'action inclut un bouton **Artefacts de sortie** dans l'onglet **Sorties**. Dans l'affirmative, les artefacts de sortie sont pris en charge.
------
#### [ Visual ]
**Pour définir un artefact de sortie à l'aide de l'éditeur visuel**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer en fonction du référentiel source ou du nom de branche dans lequel le flux de travail est défini, ou filtrer en fonction du nom ou du statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **Visual**.
1. Dans le diagramme du flux de travail, choisissez l'action qui produira l'artefact.
1. Choisissez l'onglet **Outputs**.
1. Sous **Artefacts**, choisissez **Ajouter un artefact**.
1. Choisissez **Ajouter un artefact**, puis entrez les informations dans les champs, comme suit.
**Nom de l'artefact de construction**
Spécifiez le nom d'un artefact généré par l'action. Les noms d'artifact doivent être uniques dans un flux de travail et sont limités aux caractères alphanumériques (a-z, A-Z, 0-9) et aux traits de soulignement (\$1). Les espaces, les tirets (-) et les autres caractères spéciaux ne sont pas autorisés. Vous ne pouvez pas utiliser de guillemets pour activer les espaces, les tirets et autres caractères spéciaux dans les noms d'artefacts en sortie.
Pour plus d'informations sur les artefacts, y compris des exemples, consultez[Partage d'artefacts et de fichiers entre les actions](workflows-working-artifacts.md).
**Fichiers produits par build**
Spécifiez les fichiers CodeCatalyst inclus dans l'artefact généré par l'action. Ces fichiers sont générés par l'action du flux de travail lorsqu'elle s'exécute et sont également disponibles dans votre référentiel source. Les chemins de fichiers peuvent résider dans un référentiel source ou dans un artefact issu d'une action précédente, et sont relatifs au référentiel source ou à la racine de l'artefact. Vous pouvez utiliser des modèles globulaires pour définir des chemins. Exemples :
+ Pour spécifier un seul fichier situé à la racine de votre emplacement de compilation ou de l'emplacement de votre référentiel source, utilisez`my-file.jar`.
+ Pour spécifier un seul fichier dans un sous-répertoire, utilisez `directory/my-file.jar` ou`directory/subdirectory/my-file.jar`.
+ Pour spécifier tous les fichiers, utilisez`"**/*"`. Le modèle `**` glob indique qu'il doit correspondre à un nombre quelconque de sous-répertoires.
+ Pour spécifier tous les fichiers et répertoires d'un répertoire nommé`directory`, utilisez`"directory/**/*"`. Le modèle `**` glob indique qu'il doit correspondre à un nombre quelconque de sous-répertoires.
+ Pour spécifier tous les fichiers d'un répertoire nommé`directory`, mais aucun de ses sous-répertoires, utilisez`"directory/*"`.
**Note**
Si le chemin de votre fichier comporte un ou plusieurs astérisques (`*`) ou autres caractères spéciaux, mettez-le entre guillemets (). `""` Pour plus d'informations sur les caractères spéciaux, consultez[Consignes et conventions de syntaxe](workflow-reference.md#workflow.terms.syntax.conv).
Pour plus d'informations sur les artefacts, y compris des exemples, consultez[Partage d'artefacts et de fichiers entre les actions](workflows-working-artifacts.md).
**Note**
Vous devrez peut-être ajouter un préfixe au chemin du fichier pour indiquer dans quel artefact ou dans quelle source le trouver. Pour plus d’informations, consultez [Référencement des fichiers du référentiel source](workflows-sources-reference-files.md) et [Référencement de fichiers dans un artefact](workflows-working-artifacts-refer-files.md).
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
#### [ YAML ]
**Pour définir un artefact de sortie à l'aide de l'éditeur YAML**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer en fonction du référentiel source ou du nom de branche dans lequel le flux de travail est défini, ou filtrer en fonction du nom ou du statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **YAML.**
1. Dans une action de flux de travail, ajoutez un code similaire au suivant :
```
action-name:
Outputs:
Artifacts:
- Name: artifact-name
Files:
- file-path-1
- file-path-2
```
Pour obtenir plus d’exemples, consultez [Exemples d'artefacts](workflows-working-artifacts-ex.md). Pour plus d'informations, consultez le [Définition du flux de travail YAML](workflow-reference.md) correspondant à votre action.
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
# Définition d'un artefact d'entrée
Si vous souhaitez utiliser un artefact généré par une autre CodeCatalyst action Amazon, vous devez le spécifier comme entrée pour l'action en cours. Vous pouvez peut-être spécifier plusieurs artefacts en entrée, cela dépend de l'action. Pour plus d'informations, consultez le [Définition du flux de travail YAML](workflow-reference.md) correspondant à votre action.
**Note**
Vous ne pouvez pas faire référence à des artefacts provenant d'autres flux de travail.
Suivez les instructions ci-dessous pour spécifier un artefact issu d'une autre action en tant qu'entrée de l'action en cours.
**Prérequis**
Avant de commencer, assurez-vous d'avoir généré l'artefact issu de l'autre action. Pour de plus amples informations, veuillez consulter [Définition d'un artefact de sortie](workflows-working-artifacts-output.md). La sortie de l'artefact le rend disponible pour d'autres actions.
------
#### [ Visual ]
**Pour spécifier un artefact en tant qu'entrée d'une action (éditeur visuel)**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **Visual**.
1. Dans le diagramme du flux de travail, choisissez l'action dans laquelle vous souhaitez spécifier un artefact en entrée.
1. Choisissez **Entrées**.
1. Dans **Artefacts - optional**, procédez comme suit :
Spécifiez les artefacts des actions précédentes que vous souhaitez fournir en entrée pour cette action. Ces artefacts doivent déjà être définis en tant qu'artefacts de sortie dans les actions précédentes.
Si vous ne spécifiez aucun artefact d'entrée, vous devez spécifier au moins un référentiel source sous`action-name/Inputs/Sources`.
Pour plus d'informations sur les artefacts, y compris des exemples, consultez[Partage d'artefacts et de fichiers entre les actions](workflows-working-artifacts.md).
**Note**
Si la liste déroulante **Artéfacts - optionnelle** n'est pas disponible (éditeur visuel), ou si vous recevez des erreurs lors de la validation de votre YAML (éditeur YAML), c'est peut-être parce que l'action ne prend en charge qu'une seule entrée. Dans ce cas, essayez de supprimer l'entrée source.
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
#### [ YAML ]
**Pour spécifier un artefact en entrée d'une action (éditeur YAML)**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **YAML.**
1. Dans l'action dans laquelle vous souhaitez spécifier l'artefact en entrée, ajoutez un code similaire au suivant :
```
action-name:
Inputs:
Artifacts:
- artifact-name
```
Pour obtenir plus d’exemples, consultez [Exemples d'artefacts](workflows-working-artifacts-ex.md).
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
# Référencement de fichiers dans un artefact
Si un fichier se trouve dans un artefact et que vous devez y faire référence dans l'une des actions de votre CodeCatalyst flux de travail Amazon, suivez la procédure suivante.
**Note**
Consultez également [Référencement des fichiers du référentiel source](workflows-sources-reference-files.md).
------
#### [ Visual ]
*Non disponible. Choisissez YAML pour afficher les instructions YAML.*
------
#### [ YAML ]
**Pour référencer des fichiers dans un artefact (éditeur YAML)**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **YAML.**
1. Dans l'action dans laquelle vous souhaitez référencer un fichier, ajoutez un code similaire au suivant :
```
Actions:
My-action:
Inputs:
Sources:
- WorkflowSource
Artifacts:
- artifact-name
Configuration:
template: artifact-path/path/to/file.yml
```
Dans le code précédent, remplacez :
+ *artifact-name*avec le nom de l'artefact.
+ *artifact-path*avec une valeur du tableau suivant.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/codecatalyst/latest/userguide/workflows-working-artifacts-refer-files.html)
Pour obtenir des exemples, consultez [Exemples d'artefacts](workflows-working-artifacts-ex.md).
**Note**
Vous pouvez omettre le *artifact-path* et simplement spécifier le chemin du fichier relatif au répertoire racine de l'artefact si :
L'action dans laquelle vous incluez la référence n'inclut qu'un seul élément en dessous `Inputs` (par exemple, elle inclut un artefact d'entrée et aucune source).
Le fichier que vous souhaitez référencer se trouve dans l'entrée principale. L'*entrée principale* est soit le`WorkflowSource`, soit le premier artefact d'entrée répertorié, s'il n'y en a pas`WorkflowSource`.
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Commit**, entrez un message de validation, puis choisissez **Commit** à nouveau.
------
# Téléchargement d'artefacts
Vous pouvez télécharger et inspecter les artefacts générés par les actions de votre CodeCatalyst flux de travail Amazon à des fins de résolution des problèmes. Il existe deux types d'artefacts que vous pouvez télécharger :
+ **Artefacts de source** : artefact contenant un instantané du contenu du référentiel source tel qu'il existait au début de l'exécution.
+ **Artefacts de flux** de travail : artéfact défini dans la `Outputs` propriété du fichier de configuration de votre flux de travail.
**Pour télécharger les artefacts produits par le flux de travail**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer en fonction du référentiel source ou du nom de branche dans lequel le flux de travail est défini, ou filtrer en fonction du nom ou du statut du flux de travail.
1. Sous le nom du flux de travail, choisissez **Runs**.
1. Dans **Historique** des exécutions, dans la colonne **Run ID**, sélectionnez une exécution. Par exemple, `Run-95a4d`.
1. Sous le nom de la course, sélectionnez **Artifacts**.
1. À côté d'un artefact, choisissez **Télécharger**. Un fichier d'archive est téléchargé. Son nom de fichier est composé de sept caractères aléatoires.
1. Extrayez l'archive à l'aide de l'utilitaire d'extraction d'archives de votre choix.
# Spécification de la version de l'action à utiliser
Par défaut, lorsque vous ajoutez une action à un flux de travail, Amazon CodeCatalyst ajoute la version complète au fichier de définition du flux de travail au format suivant :
`vmajor.minor.patch`
Par exemple :
```
My-Build-Action:
Identifier: aws/build@v1.0.0
```
Vous pouvez raccourcir la version complète de la `Identifier` propriété afin que le flux de travail utilise toujours la dernière version mineure ou corrective de l'action.
Par exemple, si vous spécifiez :
```
My-CloudFormation-Action:
Identifier: aws/cfn-deploy@v1.0
```
... et la dernière version du correctif est`1.0.4`, alors l'action utilisera`1.0.4`. Si une version ultérieure est publiée, disons`1.0.5`, alors l'action utilisera`1.0.5`. Si une version mineure est publiée, par exemple`1.1.0`, l'action continuera à être utilisée`1.0.5`.
Pour obtenir des instructions détaillées sur la spécification des versions, consultez l'une des rubriques suivantes.
Suivez les instructions ci-dessous pour indiquer la version d'une action que vous souhaitez utiliser dans votre flux de travail. Vous pouvez spécifier la dernière version majeure ou mineure, ou une version de correctif spécifique.
Nous vous recommandons d'utiliser la dernière version mineure ou corrective d'une action.
------
#### [ Visual ]
*Non disponible. Choisissez YAML pour afficher les instructions YAML.*
------
#### [ YAML ]
**Pour configurer un flux de travail afin d'utiliser la dernière version d'une action ou une version de correctif spécifique**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **YAML.**
1. Recherchez l'action dont vous souhaitez modifier la version.
1. Recherchez la `Identifier` propriété de l'action et définissez la version sur l'une des valeurs suivantes :
+ action-identifier @v *major* — Utilisez cette syntaxe pour que le flux de travail utilise une version majeure spécifique et que les dernières versions mineures et patchs soient sélectionnées automatiquement.
+ identificateur d'action @v. *major* *minor*— Utilisez cette syntaxe pour que le flux de travail utilise une version mineure spécifique et que la dernière version du correctif soit sélectionnée automatiquement.
+ identificateur d'action @v. *major* *minor*. *patch* — Utilisez cette syntaxe pour que le flux de travail utilise une version de correctif spécifique.
**Note**
Si vous ne savez pas quelles versions sont disponibles, consultez[Liste des versions d'action disponibles](workflows-action-versions-determine.md).
**Note**
Vous ne pouvez pas omettre la version majeure.
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
# Liste des versions d'action disponibles
Suivez les instructions suivantes pour déterminer les versions d'une action que vous pouvez utiliser dans un flux de travail.
------
#### [ Visual ]
**Pour déterminer quelles versions d'action sont disponibles**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. Recherchez l'action dont vous souhaitez consulter les versions :
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de n'importe quel flux de travail ou créez-en un. Pour plus d'informations sur la création d'un flux de travail, consultez[Création d'un flux de travail](workflows-create-workflow.md).
1. Choisissez **Modifier**.
1. En haut à gauche, choisissez **\$1 Actions** pour ouvrir le catalogue d'actions.
1. Dans la liste déroulante, choisissez **Amazon CodeCatalyst** pour afficher CodeCatalyst, CodeCatalyst Labs et actions tierces, ou choisissez **GitHub**d'afficher des GitHub actions sélectionnées.
1. Recherchez une action, puis choisissez son nom. Ne choisissez pas le signe plus (**\$1**).
Les détails de l'action apparaissent.
1. Dans la boîte de dialogue des détails de l'action, en haut à droite, choisissez la liste déroulante **Versions** pour afficher la liste des versions disponibles de l'action.
------
#### [ YAML ]
*Non disponible Choisissez « visuel » pour afficher les instructions de l'éditeur visuel.*
------
# Afficher le code source d'une action
Vous pouvez consulter le code source d'une action pour vous assurer qu'elle ne contient pas de code risqué, de failles de sécurité ou d'autres défauts.
Suivez les instructions ci-dessous pour afficher le code source d'une action [CodeCatalyst](workflows-actions.md#workflows-actions-types-cc), d'une action de [CodeCatalyst Labs](workflows-actions.md#workflows-actions-types-cc-labs) ou d'une action [tierce](workflows-actions.md#workflows-actions-types-3p).
**Note**
Pour consulter le code source d'une [GitHubaction](workflows-actions.md#workflows-actions-types-github), rendez-vous sur la page de l'action dans le [GitHub Marketplace](https://github.com/marketplace/actions). La page inclut un lien vers le référentiel de l'action, où vous pouvez trouver le code source de l'action.
**Note**
Vous ne pouvez pas afficher le code source des CodeCatalyst actions suivantes : [build](build-workflow-actions.md), [test](test-workflow-actions.md), [GitHub Actions](integrations-github-action-add.md).
**Note**
AWS ne soutient ni ne garantit le code d'action des GitHub actions ou des actions de tiers.
**Pour afficher le code source d'une action**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. Recherchez l'action dont vous souhaitez afficher le code :
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de n'importe quel flux de travail ou créez-en un. Pour plus d'informations sur la création d'un flux de travail, consultez[Création d'un flux de travail](workflows-create-workflow.md).
1. Choisissez **Modifier**.
1. En haut à gauche, choisissez **\$1 Actions** pour ouvrir le catalogue d'actions.
1. Dans la liste déroulante, sélectionnez **Amazon CodeCatalyst** pour afficher CodeCatalyst, CodeCatalyst Labs et actions tierces.
1. Recherchez une action, puis choisissez son nom. Ne choisissez pas le signe plus (**\$1**).
Les détails de l'action apparaissent.
1. Dans la boîte de dialogue des détails de l'action, en bas de la page, sélectionnez **Télécharger**.
Une page s'affiche, indiquant le compartiment Amazon S3 dans lequel réside le code source de l'action. Pour plus d'informations sur Amazon S3, consultez [Qu'est-ce qu'Amazon S3 ?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) dans le *guide de l'utilisateur d'Amazon Simple Storage Service*.
1. Inspectez le code pour vous assurer qu'il répond à vos attentes en matière de qualité et de sécurité.
# Intégration aux GitHub actions
Une *GitHub action* ressemble beaucoup à une [CodeCatalyst action](workflows-actions.md#workflows-actions-types-cc), sauf qu'elle a été développée pour être utilisée avec des GitHub flux de travail. Pour plus de détails sur GitHub les actions, consultez la documentation sur [GitHub les actions](https://docs.github.com/en/actions).
Vous pouvez utiliser GitHub des actions parallèlement à des CodeCatalyst actions natives dans un CodeCatalyst flux de travail.
Il existe deux manières d'ajouter une GitHub action à un CodeCatalyst flux de travail :
+ Vous pouvez sélectionner l' GitHub action dans une liste organisée dans la CodeCatalyst console. Plusieurs GitHub actions populaires sont disponibles. Pour de plus amples informations, veuillez consulter [Ajouter une action organisée GitHub](integrations-github-action-add-curated.md).
+ Si l' GitHub action que vous souhaitez utiliser n'est pas disponible dans la CodeCatalyst console, vous pouvez l'ajouter à l'aide d'une action **GitHub Actions**.
Une action ***GitHub Actions*** est une *CodeCatalyst action* qui enveloppe une GitHub action et la rend compatible avec les CodeCatalyst flux de travail.
Voici un exemple d'action **GitHub Actions** encapsulant l'action [Super-Linter :](https://github.com/marketplace/actions/super-linter) GitHub
```
Actions:
GitHubAction:
Identifier: aws/github-actions-runner@v1
Configuration:
Steps:
- name: Lint Code Base
uses: github/super-linter@v4
env:
VALIDATE_ALL_CODEBASE: "true"
DEFAULT_BRANCH: main
```
Dans le code précédent, l'action CodeCatalyst **GitHub Actions** (identifiée par`aws/github-actions-runner@v1`) enveloppe l'action Super-Linter (identifiée par`github/super-linter@v4`), la faisant fonctionner dans un flux de travail. CodeCatalyst
Pour de plus amples informations, veuillez consulter [Ajouter l'GitHub action « Actions »](integrations-github-action-add.md).
Toutes les GitHub actions, qu'elles soient organisées ou non, doivent être intégrées à une action **GitHub Actions** (`aws/github-actions-runner@v1`), comme indiqué dans l'exemple précédent. Le wrapper est nécessaire au bon fonctionnement de l'action.
**Topics**
+ [En quoi les GitHub actions diffèrent-elles des CodeCatalyst actions ?](#integrations-github-actions-how-different)
+ [Les GitHub actions peuvent-elles interagir avec d'autres CodeCatalyst actions du flux de travail ?](#integrations-github-actions-interactions.title)
+ [Quelles GitHub actions puis-je utiliser ?](#integrations-github-actions-supported)
+ [Limites des GitHub actions dans CodeCatalyst](#integrations-github-actions-limitations)
+ [Comment ajouter une GitHub action (étapes de haut niveau) ?](#integrations-github-actions-how-to)
+ [L' GitHub action s'exécute-t-elle GitHub ?](#integrations-github-actions-where-it-runs)
+ [Puis-je également utiliser des GitHub flux de travail ?](#integrations-github-actions-workflows-support.title)
+ [Image d'exécution utilisée par l'GitHub action « Actions »](#integrations-github-actions-runtime)
+ [Tutoriel : code Lint à l'aide d'une action GitHub](integrations-github-action-tutorial.md)
+ [Ajouter l'GitHub action « Actions »](integrations-github-action-add.md)
+ [Ajouter une action organisée GitHub](integrations-github-action-add-curated.md)
+ [Exportation des paramètres GitHub de sortie](integrations-github-action-export.md)
+ [Référencement des paramètres GitHub de sortie](integrations-github-action-referencing.md)
+ [GitHub Action « Actions » YAML](github-action-ref.md)
## En quoi les GitHub actions diffèrent-elles des CodeCatalyst actions ?
GitHub Les actions utilisées dans un CodeCatalyst flux de travail n'ont pas le même niveau d'accès, d'intégration AWS et de CodeCatalyst fonctionnalités (telles que [les environnements](deploy-environments.md) et [les problèmes](issues.md)) que CodeCatalyst les actions.
## Les GitHub actions peuvent-elles interagir avec d'autres CodeCatalyst actions du flux de travail ?
Oui. Par exemple, GitHub les actions peuvent utiliser des variables produites par d'autres CodeCatalyst actions comme entrée, et peuvent également partager des paramètres de sortie et des artefacts avec CodeCatalyst des actions. Pour plus d’informations, consultez [Exportation des paramètres GitHub de sortie](integrations-github-action-export.md) et [Référencement des paramètres GitHub de sortie](integrations-github-action-referencing.md).
## Quelles GitHub actions puis-je utiliser ?
Vous pouvez utiliser n'importe quelle GitHub action disponible via la CodeCatalyst console et n'importe quelle GitHub action disponible [GitHubsur le Marketplace](https://github.com/marketplace/actions). Si vous décidez d'utiliser une GitHub Action depuis le Marketplace, gardez à l'esprit les [limites](#integrations-github-actions-limitations) suivantes.
## Limites des GitHub actions dans CodeCatalyst
+ GitHub Les actions ne peuvent pas être utilisées avec le type de [calcul CodeCatalyst Lambda](workflows-working-compute.md#compute.types).
+ GitHub Les actions s'exécutent sur l'image Docker de l'environnement d'exécution de [novembre 2022](build-images.md#build.previous-image), qui inclut des outils plus anciens. Pour plus d'informations sur l'image et l'outillage, consultez[Spécification des images de l'environnement d'exécution](build-images.md).
+ GitHub Les actions qui s'appuient en interne sur le [`github`contexte](https://docs.github.com/en/actions/learn-github-actions/contexts#github-context) ou qui font référence à GitHub des ressources spécifiques ne fonctionneront pas. CodeCatalyst Par exemple, les actions suivantes ne fonctionneront pas dans CodeCatalyst :
+ Actions visant à ajouter, modifier ou mettre à jour GitHub des ressources. Les exemples incluent les actions qui mettent à jour les pull requests ou créent des problèmes dans GitHub.
+ Presque toutes les actions répertoriées dans [https://github.com/actions](https://github.com/actions).
+ GitHub Les actions qui sont des [actions de conteneur Docker](https://docs.github.com/en/actions/creating-actions/about-custom-actions#docker-container-actions) fonctionneront, mais elles doivent être exécutées par l'utilisateur Docker par défaut (root). N'exécutez pas l'action en tant qu'utilisateur 1001. (Au moment de la rédaction de cet article, l'utilisateur 1001 travaille dans GitHub, mais pas dans CodeCatalyst.) Pour plus d'informations, consultez la rubrique [UTILISATEUR](https://docs.github.com/en/actions/creating-actions/dockerfile-support-for-github-actions#user) dans le [support Dockerfile pour les GitHub actions](https://docs.github.com/en/actions/creating-actions/dockerfile-support-for-github-actions).
Pour obtenir la liste des GitHub actions disponibles via la CodeCatalyst console, consultez[Ajouter une action organisée GitHub](integrations-github-action-add-curated.md).
## Comment ajouter une GitHub action (étapes de haut niveau) ?
Les étapes de haut niveau pour ajouter une GitHub action à un CodeCatalyst flux de travail sont les suivantes :
1. Dans votre CodeCatalyst projet, vous **créez un flux de travail**. Le flux de travail vous permet de définir comment créer, tester et déployer votre application. Pour de plus amples informations, veuillez consulter [Commencer à utiliser les flux de travail](workflows-getting-started.md).
1. Dans le flux de travail, vous **ajoutez une GitHub action organisée** ou vous **ajoutez l'action GitHub Actions**.
1. Vous devez effectuer l'une des opérations suivantes :
+ Si vous avez choisi d'ajouter une action organisée, configurez-la. Pour de plus amples informations, veuillez consulter [Ajouter une action organisée GitHub](integrations-github-action-add-curated.md).
+ Si vous avez choisi d'ajouter une action non organisée, dans l'action **GitHubActions**, vous **collez le code YAML de l' GitHub action**. Vous trouverez ce code sur la page détaillée de l' GitHubaction que vous avez choisie [GitHubsur le Marketplace](https://github.com/marketplace/actions). Vous devrez probablement modifier légèrement le code pour qu'il fonctionne CodeCatalyst. Pour de plus amples informations, veuillez consulter [Ajouter l'GitHub action « Actions »](integrations-github-action-add.md).
1. (Facultatif) Dans le flux de travail, **vous ajoutez d'autres actions**, telles que les actions de création et de test. Pour de plus amples informations, veuillez consulter [Créez, testez et déployez avec des flux de travailCréez, testez et déployez avec des flux de travail](workflow.md).
1. Vous **démarrez le flux de travail** manuellement ou automatiquement via un déclencheur. Le flux de travail exécute l' GitHub action et toutes les autres actions du flux de travail. Pour de plus amples informations, veuillez consulter [Démarrage manuel de l’exécution d’un flux de travail](workflows-manually-start.md).
Pour les étapes détaillées, voir :
+ [Ajouter une action organisée GitHub](integrations-github-action-add-curated.md).
+ [Ajouter l'GitHub action « Actions »](integrations-github-action-add.md).
## L' GitHub action s'exécute-t-elle GitHub ?
Non. L' GitHub action s'exécute en utilisant CodeCatalyst l'[image CodeCatalyst de l'environnement d'exécution](workflows-working-compute.md).
## Puis-je également utiliser des GitHub flux de travail ?
Non.
## Image d'exécution utilisée par l'GitHub action « Actions »
L'action CodeCatalyst **GitHub Actions** s'exécute sur une [image de novembre 2022](build-images.md#build.previous-image). Pour de plus amples informations, veuillez consulter [Images actives](build-images.md#build-curated-images).
# Tutoriel : code Lint à l'aide d'une action GitHub
Dans ce didacticiel, vous allez ajouter l'[ GitHub action Super-Linter à un flux](https://github.com/marketplace/actions/super-linter) de travail Amazon CodeCatalyst . L'action Super-Linter inspecte le code, détecte les zones dans lesquelles le code contient des erreurs, des problèmes de formatage et des constructions suspectes, puis affiche les résultats sur la console). CodeCatalyst Après avoir ajouté le linter à votre flux de travail, vous exécutez le flux de travail pour lint un exemple d'application Node.js ()`app.js`. Vous corrigez ensuite les problèmes signalés et réexécutez le flux de travail pour voir si les correctifs ont fonctionné.
**Astuce**
[Envisagez d'utiliser Super-Linter pour colorer des fichiers YAML, tels que des modèles.CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html)
**Topics**
+ [Conditions préalables](#integrations-github-action-tutorial-prereqs)
+ [Étape 1 : Création d'un référentiel source](#integrations-github-action-tutorial-create-source-repo)
+ [Étape 2 : Ajouter un fichier app.js](#integrations-github-action-tutorial-add-appjs)
+ [Étape 3 : créer un flux de travail qui exécute l'action Super-Linter](#integrations-github-action-tutorial-create-workflow)
+ [Étape 4 : Résoudre les problèmes détectés par le Super-Linter](#integrations-github-action-tutorial-fix-probs)
+ [Nettoyage](#integrations-github-action-tutorial-cleanup)
## Conditions préalables
Avant de commencer, vous aurez besoin des éléments suivants :
+ Un CodeCatalyst **espace** connecté Compte AWS. Pour de plus amples informations, veuillez consulter [Création d’un espace](spaces-create.md).
+ Un projet vide dans votre CodeCatalyst espace appelé`codecatalyst-linter-project`. Choisissez l'option **Partir de zéro** pour créer ce projet.
```
```
Pour de plus amples informations, veuillez consulter [Création d'un projet vide dans Amazon CodeCatalyst](projects-create.md#projects-create-empty).
## Étape 1 : Création d'un référentiel source
Au cours de cette étape, vous créez un référentiel source dans CodeCatalyst. Vous allez utiliser ce référentiel pour stocker l'exemple de fichier source de l'application`app.js`, dans le cadre de ce didacticiel.
Pour plus d'informations sur les référentiels sources, consultez[Création d'un référentiel source](source-repositories-create.md).
**Pour créer un référentiel de sources**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Accédez à votre projet,`codecatalyst-linter-project`.
1. Dans le volet de navigation, choisissez **Code**, puis sélectionnez **Référentiels sources**.
1. Choisissez **Ajouter un référentiel**, puis sélectionnez **Créer un référentiel**.
1. Dans **Nom du référentiel**, entrez :
```
codecatalyst-linter-source-repository
```
1. Choisissez **Créer**.
## Étape 2 : Ajouter un fichier app.js
Au cours de cette étape, vous ajoutez un `app.js` fichier à votre référentiel source. Le `app.js` contient un code de fonction contenant quelques erreurs que le linter trouvera.
**Pour ajouter le fichier app.js**
1. Dans la CodeCatalyst console, choisissez votre projet,`codecatalyst-linter-project`.
1. Dans le volet de navigation, choisissez **Code**, puis sélectionnez **Référentiels sources**.
1. Dans la liste des référentiels sources, choisissez votre référentiel,`codecatalyst-linter-source-repository`.
1. Dans **Fichiers**, choisissez **Créer un fichier**.
1. Dans la zone de texte, entrez le code suivant :
```
// const axios = require('axios')
// const url = 'http://checkip.amazonaws.com/';
let response;
/**
*
* Event doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html#api-gateway-simple-proxy-for-lambda-input-format
* @param {Object} event - API Gateway Lambda Proxy Input Format
*
* Context doc: https://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-context.html
* @param {Object} context
*
* Return doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html
* @returns {Object} object - API Gateway Lambda Proxy Output Format
*
*/
exports.lambdaHandler = async (event, context) => {
try {
// const ret = await axios(url);
response = {
statusCode: 200,
'body': JSON.stringify({
message: 'hello world'
// location: ret.data.trim()
})
}
} catch (err) {
console.log(err)
return err
}
return response
}
```
1. Dans **Nom du fichier**, entrez`app.js`. Conservez les autres options par défaut.
1. Choisissez **Commit (Valider)**.
Vous venez de créer un fichier appelé`app.js`.
## Étape 3 : créer un flux de travail qui exécute l'action Super-Linter
Au cours de cette étape, vous créez un flux de travail qui exécute l'action Super-Linter lorsque vous envoyez du code vers votre référentiel source. Le flux de travail comprend les éléments de base suivants, que vous définissez dans un fichier YAML :
+ **Un déclencheur** : ce déclencheur lance automatiquement l'exécution du flux de travail lorsque vous apportez une modification à votre référentiel source. Pour plus d'informations sur les déclencheurs, consultez [Démarrage d'un flux de travail exécuté automatiquement à l'aide de déclencheurs](workflows-add-trigger.md).
+ **Une action « GitHub Actions » — Lorsqu'**elle est déclenchée, l'action **GitHub Actions** exécute l'action Super-Linter, qui à son tour inspecte tous les fichiers de votre référentiel source. Si le linter détecte un problème, l'action du flux de travail échoue.
**Pour créer un flux de travail qui exécute l'action Super-Linter**
1. Dans la CodeCatalyst console, choisissez votre projet,`codecatalyst-linter-project`.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez **Créer un flux de travail**.
1. Pour **Référentiel source**, choisissez`codecatalyst-linter-source-repository`.
1. Pour **Branch**, choisissez`main`.
1. Choisissez **Créer**.
1. Supprimez l'exemple de code YAML.
1. Ajoutez le code YAML suivant :
```
Name: codecatalyst-linter-workflow
SchemaVersion: "1.0"
Triggers:
- Type: PUSH
Branches:
- main
Actions:
SuperLinterAction:
Identifier: aws/github-actions-runner@v1
Configuration:
Steps:
github-action-code
```
Dans le code précédent, remplacez-le *github-action-code* par le code d'action Super-Linter, comme indiqué dans les étapes suivantes de cette procédure.
1. Accédez à la [page Super-Linter sur le](https://github.com/marketplace/actions/super-linter) Marketplace. GitHub
1. Sous `steps:` (minuscules), recherchez le code et collez-le dans le CodeCatalyst flux de travail situé sous `Steps:` (majuscules).
Ajustez le code GitHub d'action pour qu'il soit conforme aux CodeCatalyst normes, comme indiqué dans le code suivant.
Votre CodeCatalyst flux de travail ressemble désormais à ceci :
```
Name: codecatalyst-linter-workflow
SchemaVersion: "1.0"
Triggers:
- Type: PUSH
Branches:
- main
Actions:
SuperLinterAction:
Identifier: aws/github-actions-runner@v1
Configuration:
Steps:
- name: Lint Code Base
uses: github/super-linter@v4
env:
VALIDATE_ALL_CODEBASE: "true"
DEFAULT_BRANCH: main
```
1. (Facultatif) Choisissez **Valider** pour vous assurer que le code YAML est valide avant de valider.
1. Choisissez **Valider**, entrez un **message de validation**, sélectionnez votre `codecatalyst-linter-source-repository` **référentiel**, puis choisissez à nouveau **Valider**.
Vous venez de créer un flux de travail. L'exécution d'un flux de travail démarre automatiquement en raison du déclencheur défini en haut du flux de travail.
**Pour consulter le flux de travail en cours d'exécution**
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le flux de travail que vous venez de créer :`codecatalyst-linter-workflow`.
1. Dans le diagramme du flux de travail, choisissez **SuperLinterAction**.
1. Attendez que l'action échoue. Cet échec est attendu car le linter a détecté des problèmes dans le code.
1. Laissez la CodeCatalyst console ouverte et accédez à[Étape 4 : Résoudre les problèmes détectés par le Super-Linter](#integrations-github-action-tutorial-fix-probs).
## Étape 4 : Résoudre les problèmes détectés par le Super-Linter
Le Super-Linter devrait avoir détecté des problèmes dans le `app.js` code, ainsi que dans le `README.md` fichier inclus dans votre dépôt source.
**Pour résoudre les problèmes détectés par le linter**
1. Dans la CodeCatalyst console, choisissez l'onglet **Logs**, puis **Lint Code Base**.
Les journaux générés par l'action Super-Linter sont affichés.
1. Dans les journaux de Super-Linter, faites défiler l'écran vers le bas jusqu'à la ligne 90, où vous trouverez le début des problèmes. Ils ressemblent à ce qui suit :
```
/github/workspace/hello-world/app.js:3:13: Extra semicolon.
/github/workspace/hello-world/app.js:9:92: Trailing spaces not allowed.
/github/workspace/hello-world/app.js:21:7: Unnecessarily quoted property 'body' found.
/github/workspace/hello-world/app.js:31:1: Expected indentation of 2 spaces but found 4.
/github/workspace/hello-world/app.js:32:2: Newline required at end of file but not found.
```
1. Corrigez `app.js` et `README.md` dans votre référentiel source et validez vos modifications.
**Astuce**
Pour corriger le problème`README.md`, ajoutez-le `markdown` au bloc de code, comme ceci :
```
```markdown
Setup examples:
...
```
```
Vos modifications démarrent un autre flux de travail exécuté automatiquement. Attendez que le flux de travail soit terminé. Si vous avez résolu tous les problèmes, le flux de travail devrait réussir.
## Nettoyage
Nettoyez CodeCatalyst pour supprimer les traces de ce didacticiel dans votre environnement.
**Pour nettoyer CodeCatalyst**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Supprimer`codecatalyst-linter-source-repository`.
1. Supprimer`codecatalyst-linter-workflow`.
Dans ce didacticiel, vous avez appris à ajouter l' GitHub action Super-Linter à un CodeCatalyst flux de travail afin de créer du code.
# Ajouter l'GitHub action « Actions »
Une action ***GitHub Actions*** est une *CodeCatalyst action* qui enveloppe une GitHub action et la rend compatible avec les CodeCatalyst flux de travail.
Pour de plus amples informations, veuillez consulter [Intégration aux GitHub actions](integrations-github-actions.md).
Pour ajouter l'action **GitHub Actions** à un flux de travail, procédez comme suit.
**Astuce**
Pour consulter un didacticiel expliquant comment utiliser l'action **GitHub Actions**, voir[Tutoriel : code Lint à l'aide d'une action GitHub](integrations-github-action-tutorial.md).
------
#### [ Visual ]
**Pour ajouter l'GitHub action « Actions » à l'aide de l'éditeur visuel**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **Visual**.
1. En haut à gauche, choisissez **\$1 Actions** pour ouvrir le catalogue d'actions.
1. Dans la liste déroulante, sélectionnez **GitHub**.
1. Recherchez l'action **GitHub Actions**, puis effectuez l'une des opérations suivantes :
+ Choisissez le signe plus (**\$1**) pour ajouter l'action au diagramme de flux de travail et ouvrir son volet de configuration.
Or
+ Choisissez **GitHub Actions**. La boîte de dialogue des détails de l'action apparaît. Dans cette boîte de dialogue :
+ (Facultatif) Choisissez **Afficher la source** pour [afficher le code source de l'action](workflows-view-source.md#workflows-view-source.title).
+ Choisissez **Ajouter au flux de travail** pour ajouter l'action au diagramme du flux de travail et ouvrir son volet de configuration.
1. Dans les onglets **Entrées** et **Configuration**, complétez les champs selon vos besoins. Pour une description de chaque champ, consultez le[GitHub Action « Actions » YAML](github-action-ref.md). Cette référence fournit des informations détaillées sur chaque champ (et la valeur de propriété YAML correspondante) tel qu'il apparaît dans les éditeurs YAML et visuels.
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
#### [ YAML ]
**Pour ajouter l'GitHub action « Actions » à l'aide de l'éditeur YAML**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **YAML.**
1. En haut à gauche, choisissez **\$1 Actions** pour ouvrir le catalogue d'actions.
1. Dans la liste déroulante, sélectionnez **GitHub**.
1. Recherchez l'action **GitHub Actions**, puis effectuez l'une des opérations suivantes :
+ Choisissez le signe plus (**\$1**) pour ajouter l'action au diagramme de flux de travail et ouvrir son volet de configuration.
Or
+ Choisissez **GitHub Actions**. La boîte de dialogue des détails de l'action apparaît. Dans cette boîte de dialogue :
+ (Facultatif) Choisissez **Afficher la source** pour [afficher le code source de l'action](workflows-view-source.md#workflows-view-source.title).
+ Choisissez **Ajouter au flux de travail** pour ajouter l'action au diagramme du flux de travail et ouvrir son volet de configuration.
1. Modifiez les propriétés du code YAML en fonction de vos besoins. Une explication de chaque propriété disponible est fournie dans le[GitHub Action « Actions » YAML](github-action-ref.md).
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
## Définition de GitHub l'action « Actions »
L'action **GitHub Actions** est définie comme un ensemble de propriétés YAML dans votre fichier de définition de flux de travail. Pour plus d'informations sur ces propriétés, consultez [GitHub Action « Actions » YAML](github-action-ref.md) le[Définition du flux de travail YAML](workflow-reference.md).
# Ajouter une action organisée GitHub
Une * GitHub action organisée* est une GitHub action mise à disposition dans la CodeCatalyst console et sert d'exemple d'utilisation d'une GitHub action dans un CodeCatalyst flux de travail.
Les GitHub actions sélectionnées sont regroupées dans l'[action **GitHub Actions**](integrations-github-action-add.md) créée par CodeCatalyst l'auteur, identifiée par l'identifiant. `aws/github-actions-runner@v1` Par exemple, voici à quoi ressemble l' GitHub action sélectionnée, [TruffleHog OSS](https://github.com/marketplace/actions/trufflehog-oss) :
```
Actions:
TruffleHogOSS_e8:
Identifier: aws/github-actions-runner@v1
Inputs:
Sources:
- WorkflowSource # This specifies that the action requires this Workflow as a source
Configuration:
Steps:
- uses: trufflesecurity/trufflehog@v3.16.0
with:
path: ' ' # Required; description: Repository path
base: ' ' # Required; description: Start scanning from here (usually main branch).
head: ' ' # Optional; description: Scan commits until here (usually dev branch).
extra_args: ' ' # Optional; description: Extra args to be passed to the trufflehog cli.
```
Dans le code précédent, l'action CodeCatalyst **GitHub Actions** (identifiée par`aws/github-actions-runner@v1`) englobe l'action TruffleHog OSS (identifiée par`trufflesecurity/trufflehog@v3.16.0`), la faisant fonctionner dans un CodeCatalyst flux de travail.
Pour configurer cette action, vous devez remplacer les chaînes vides ci-dessous `with:` par vos propres valeurs. Par exemple :
```
Actions:
TruffleHogOSS_e8:
Identifier: aws/github-actions-runner@v1
Inputs:
Sources:
- WorkflowSource # This specifies that the action requires this Workflow as a source
Configuration:
Steps:
- uses: trufflesecurity/trufflehog@v3.16.0
with:
path: ./
base: main # Required; description: Start scanning from here (usually main branch).
head: HEAD # Optional; description: Scan commits until here (usually dev branch).
extra_args: '‐‐debug ‐‐only-verified' # Optional; description: Extra args to be passed to the trufflehog cli.
```
Pour ajouter une GitHub action sélectionnée à un flux de travail, procédez comme suit. Pour des informations générales sur l'utilisation GitHub des actions dans un CodeCatalyst flux de travail, consultez[Intégration aux GitHub actions](integrations-github-actions.md).
**Note**
Si votre GitHub action ne figure pas dans la liste des actions sélectionnées, vous pouvez toujours l'ajouter à votre flux de travail à l'aide de l'action **GitHub Actions**. Pour de plus amples informations, veuillez consulter [Ajouter l'GitHub action « Actions »](integrations-github-action-add.md).
------
#### [ Visual ]
**Pour ajouter une GitHub action organisée à l'aide de l'éditeur visuel**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **Visual**.
1. En haut à gauche, choisissez **\$1 Actions** pour ouvrir le catalogue d'actions.
1. Dans la liste déroulante, sélectionnez **GitHub**.
1. Parcourez ou recherchez une GitHub action, puis effectuez l'une des opérations suivantes :
+ Choisissez le signe plus (**\$1**) pour ajouter l'action au diagramme de flux de travail et ouvrir son volet de configuration.
Or
+ Choisissez le nom de l' GitHub action. La boîte de dialogue des détails de l'action apparaît. Dans cette boîte de dialogue :
+ (Facultatif) Choisissez **Afficher la source** pour [afficher le code source de l'action](workflows-view-source.md#workflows-view-source.title).
+ Choisissez **Ajouter au flux de travail** pour ajouter l'action au diagramme du flux de travail et ouvrir son volet de configuration.
1. Dans les onglets **Entrées**, **Configuration** et **Sorties**, complétez les champs selon vos besoins. Pour une description de chaque champ, consultez le[GitHub Action « Actions » YAML](github-action-ref.md). Cette référence fournit des informations détaillées sur chaque champ (et la valeur de propriété YAML correspondante) disponible pour l'action **GitHubActions**, tel qu'il apparaît dans les éditeurs YAML et visuels.
Pour plus d'informations sur les options de configuration disponibles pour l' GitHubaction sélectionnée, consultez sa documentation.
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
#### [ YAML ]
**Pour ajouter une GitHub action organisée à l'aide de l'éditeur YAML**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **YAML.**
1. En haut à gauche, choisissez **\$1 Actions** pour ouvrir le catalogue d'actions.
1. Dans la liste déroulante, sélectionnez **GitHub**.
1. Parcourez ou recherchez une GitHub action, puis effectuez l'une des opérations suivantes :
+ Choisissez le signe plus (**\$1**) pour ajouter l'action au diagramme de flux de travail et ouvrir son volet de configuration.
Or
+ Choisissez le nom de l' GitHub action. La boîte de dialogue des détails de l'action apparaît. Dans cette boîte de dialogue :
+ (Facultatif) Choisissez **Afficher la source** pour [afficher le code source de l'action](workflows-view-source.md#workflows-view-source.title).
+ Choisissez **Ajouter au flux de travail** pour ajouter l'action au diagramme du flux de travail et ouvrir son volet de configuration.
1. Modifiez les propriétés du code YAML en fonction de vos besoins. Une explication de chaque propriété disponible pour l'action **GitHub Actions** est fournie dans le[GitHub Action « Actions » YAML](github-action-ref.md).
Pour plus d'informations sur les options de configuration disponibles pour l' GitHubaction sélectionnée, consultez sa documentation.
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
# Exportation des paramètres GitHub de sortie
Vous pouvez utiliser des [paramètres GitHub de sortie](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter) dans vos CodeCatalyst flux de travail.
**Note**
Un autre mot pour le *paramètre de sortie* est *variable*. Comme le terme *paramètre de sortie* est GitHub utilisé dans sa documentation, nous utiliserons également ce terme.
Suivez les instructions ci-dessous pour exporter un paramètre de GitHub sortie depuis une GitHub action afin qu'il puisse être utilisé par d'autres actions de CodeCatalyst flux de travail.
**Pour exporter un paramètre GitHub de sortie**
1. Ouvrez un flux de travail et choisissez **Modifier**. Pour de plus amples informations, veuillez consulter [Création d'un flux de travail](workflows-create-workflow.md).
1. Dans l'action **GitHub Actions** qui génère le paramètre de sortie que vous souhaitez exporter, ajoutez une `Outputs` section avec une `Variables` propriété sous-jacente qui ressemble à ceci :
```
Actions:
MyGitHubAction:
Identifier: aws/github-actions-runner@v1
Outputs:
Variables:
- 'step-id_output-name'
```
Remplacer :
+ *step-id*avec la valeur de la `id:` propriété dans la `steps` section de l' GitHub action.
+ *output-name*avec le nom du paramètre GitHub de sortie.
**exemple**
L'exemple suivant montre comment exporter un paramètre GitHub de sortie appelé`SELECTEDCOLOR`.
```
Actions:
MyGitHubAction:
Identifier: aws/github-actions-runner@v1
Outputs:
Variables:
- 'random-color-generator_SELECTEDCOLOR'
Configuration:
Steps:
- name: Set selected color
run: echo "SELECTEDCOLOR=green" >> $GITHUB_OUTPUT
id: random-color-generator
```
# Référencement des paramètres GitHub de sortie
Suivez les instructions ci-dessous pour référencer un paramètre GitHub de sortie.
**Pour référencer un paramètre GitHub de sortie**
1. Suivez les étapes de [Exportation des paramètres GitHub de sortie](integrations-github-action-export.md).
Le paramètre GitHub de sortie peut désormais être utilisé dans d'autres actions.
1. Notez la `Variables` valeur du paramètre de sortie. Il inclut un trait de soulignement (\$1).
1. Reportez-vous au paramètre de sortie à l'aide de la syntaxe suivante :
```
${action-name.output-name}
```
Remplacez :
+ *action-name*avec le nom de l' CodeCatalyst**GitHub action** qui produit le paramètre de sortie (n'utilisez pas le `name` ou de l' GitHub action`id`).
+ *output-name*avec la `Variables` valeur du paramètre de sortie que vous avez indiquée précédemment.
**Exemple**
```
BuildActionB:
Identifier: aws/build@v1
Configuration:
Steps:
- Run: echo ${MyGitHubAction.random-color-generator_SELECTEDCOLOR}
```
**Exemple avec contexte**
L'exemple suivant montre comment définir une `SELECTEDCOLOR` variable dans`GitHubActionA`, la sortir, puis y faire référence dans`BuildActionB`.
```
Actions:
GitHubActionA:
Identifier: aws/github-actions-runner@v1
Configuration:
Steps:
- name: Set selected color
run: echo "SELECTEDCOLOR=green" >> $GITHUB_OUTPUT
id: random-color-generator
Outputs:
Variables:
- 'random-color-generator_SELECTEDCOLOR'
BuildActionB:
Identifier: aws/build@v1
Configuration:
Steps:
- Run: echo ${GitHubActionA.random-color-generator_SELECTEDCOLOR}
```
# GitHub Action « Actions » YAML
Voici la définition YAML de l'action **GitHubActions**.
Cette définition d'action existe sous la forme d'une section au sein d'un fichier de définition de flux de travail plus large. Pour plus d’informations sur ce fichier, consultez [Définition du flux de travail YAML](workflow-reference.md).
Choisissez une propriété YAML dans le code suivant pour en voir la description.
**Note**
La plupart des propriétés YAML suivantes ont des éléments d'interface utilisateur correspondants dans l'éditeur visuel. Pour rechercher un élément de l'interface utilisateur, utilisez **Ctrl\$1F**. L'élément sera répertorié avec sa propriété YAML associée.
```
# The workflow definition starts here.
# See Propriétés de haut niveau for details.
Name: MyWorkflow
SchemaVersion: 1.0
Actions:
# The action definition starts here.
action-name:
Identifier: aws/github-actions-runner@v1
DependsOn:
- dependent-action-name-1
Compute:
Fleet: fleet-name
Timeout: timeout-minutes
Environment:
Name: environment-name
Connections:
- Name: account-connection-name
Role: iam-role-name
Inputs:
Sources:
- source-name-1
- source-name-2
Artifacts:
- artifact-name
Variables:
- Name: variable-name-1
Value: variable-value-1
- Name: variable-name-2
Value: variable-value-2
Outputs:
Artifacts:
- Name: output-artifact-1
Files:
- github-output/artifact-1.jar
- "github-output/build*"
- Name: output-artifact-2
Files:
- github-output/artifact-2.1.jar
- github-output/artifact-2.2.jar
Variables:
- variable-name-1
- variable-name-2
AutoDiscoverReports:
Enabled: true | false
ReportNamePrefix: AutoDiscovered
IncludePaths:
- "**/*"
ExcludePaths:
- node_modules/cdk/junit.xml
SuccessCriteria:
PassRate: percent
LineCoverage: percent
BranchCoverage: percent
Vulnerabilities:
Severity: CRITICAL|HIGH|MEDIUM|LOW|INFORMATIONAL
Number: whole-number
Reports:
report-name-1:
Format: format
IncludePaths:
- "*.xml"
ExcludePaths:
- report2.xml
- report3.xml
SuccessCriteria:
PassRate: percent
LineCoverage: percent
BranchCoverage: percent
Vulnerabilities:
Severity: CRITICAL|HIGH|MEDIUM|LOW|INFORMATIONAL
Number: whole-number
Configuration
Steps:
- github-actions-code
```
## nom-action
(Obligatoire)
Spécifiez le nom de l'action. Tous les noms d'action doivent être uniques dans le flux de travail. Les noms d'action sont limités aux caractères alphanumériques (a-z, A-Z, 0-9), aux tirets (-) et aux traits de soulignement (\$1). Les espaces ne sont pas autorisés. Vous ne pouvez pas utiliser de guillemets pour activer les caractères spéciaux et les espaces dans les noms d'action.
Interface utilisateur correspondante : onglet Configuration/ *action-name*
## Identifier
(*action-name*/**Identifier**)
Identifie l'action. Ne modifiez pas cette propriété, sauf si vous souhaitez modifier la version. Pour de plus amples informations, veuillez consulter [Spécification de la version de l'action à utiliser](workflows-action-versions.md).
À utiliser `aws/github-actions-runner@v1` pour **GitHubles actions** Actions.
Interface utilisateur correspondante : diagramme de flux de travail/*action-name*/**aws/ @v1 label github-actions-runner**
## DependsOn
(*action-name*/**DependsOn**)
(Facultatif)
Spécifiez une action, un groupe d'actions ou une porte qui doit s'exécuter correctement pour que cette action soit exécutée.
Pour plus d'informations sur la fonctionnalité « dépend », consultez. [Actions de séquençage](workflows-depends-on.md)
Interface utilisateur correspondante : onglet **Entrées/dépend de - facultatif**
## Compute
(*action-name*/**Compute**)
(Facultatif)
Le moteur informatique utilisé pour exécuter les actions de votre flux de travail. Vous pouvez spécifier le calcul au niveau du flux de travail ou au niveau de l'action, mais pas les deux. Lorsqu'elle est spécifiée au niveau du flux de travail, la configuration de calcul s'applique à toutes les actions définies dans le flux de travail. Au niveau du flux de travail, vous pouvez également exécuter plusieurs actions sur la même instance. Pour de plus amples informations, veuillez consulter [Partage du calcul entre les actions](compute-sharing.md).
Interface utilisateur correspondante : *aucune*
## Fleet
(*action-name*/Compute/**Fleet**)
(Facultatif)
Spécifiez la machine ou le parc qui exécutera votre flux de travail ou vos actions de flux de travail. Dans le cas des flottes à la demande, lorsqu'une action démarre, le flux de travail fournit les ressources dont il a besoin et les machines sont détruites à la fin de l'action. Exemples de flottes à la demande :`Linux.x86-64.Large`,`Linux.x86-64.XLarge`. Pour plus d'informations sur les flottes à la demande, consultez[Propriétés de la flotte à la demande](workflows-working-compute.md#compute.on-demand).
Avec les flottes provisionnées, vous configurez un ensemble de machines dédiées pour exécuter les actions de votre flux de travail. Ces machines restent inactives, prêtes à exécuter des actions immédiatement. Pour plus d'informations sur les flottes provisionnées, consultez. [Propriétés de la flotte de véhicules provisionnée](workflows-working-compute.md#compute.provisioned-fleets)
S'il `Fleet` est omis, la valeur par défaut est`Linux.x86-64.Large`.
Interface utilisateur correspondante : onglet **Configuration/parc de calcul - facultatif**
## Timeout
(*action-name*/**Timeout**)
(Facultatif)
Spécifiez la durée en minutes (éditeur YAML) ou en heures et minutes (éditeur visuel) pendant laquelle l'action peut être exécutée avant la CodeCatalyst fin de l'action. Le minimum est de 5 minutes et le maximum est décrit dans[Quotas pour les flux de travail dans CodeCatalyst](workflows-quotas.md). Le délai d'expiration par défaut est le même que le délai d'expiration maximal.
Interface utilisateur correspondante : onglet **Configuration/Délai d'expiration - facultatif**
## Environment
(*action-name*/**Environment**)
(Facultatif)
Spécifiez l' CodeCatalyst environnement à utiliser avec l'action. L'action se connecte au Compte AWS VPC Amazon facultatif spécifié dans l'environnement choisi. L'action utilise le rôle IAM par défaut spécifié dans l'environnement pour se connecter au Compte AWS, et utilise le rôle IAM spécifié dans la [connexion Amazon VPC](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html) pour se connecter à Amazon VPC.
**Note**
Si le rôle IAM par défaut ne dispose pas des autorisations requises par l'action, vous pouvez configurer l'action pour utiliser un autre rôle. Pour de plus amples informations, veuillez consulter [Modifier le rôle IAM d'une action](deploy-environments-switch-role.md).
Pour plus d'informations sur les environnements, reportez-vous [Déploiement dans Comptes AWS et VPCs](deploy-environments.md) aux sections et[Création d'un environnement](deploy-environments-creating-environment.md).
**Interface utilisateur correspondante : onglet Configuration/Environnement**
## Name
(*action-name*/Environment/**Name**)
(Obligatoire s'[Environment](#github.environment)il est inclus)
Spécifiez le nom de l'environnement existant que vous souhaitez associer à l'action.
**Interface utilisateur correspondante : onglet Configuration/Environnement**
## Connections
(*action-name*/Environment/**Connections**)
(Facultatif)
Spécifiez la connexion au compte à associer à l'action. Vous pouvez spécifier un maximum d'une connexion à un compte sous`Environment`.
Si vous ne spécifiez pas de connexion au compte :
+ L'action utilise la Compte AWS connexion et le rôle IAM par défaut spécifiés dans l'environnement de la CodeCatalyst console. Pour plus d'informations sur l'ajout d'une connexion à un compte et d'un rôle IAM par défaut dans l'environnement, consultez[Création d'un environnement](deploy-environments-creating-environment.md).
+ Le rôle IAM par défaut doit inclure les politiques et les autorisations requises par l'action. Pour déterminer quelles sont ces politiques et autorisations, consultez la description de la propriété **Role** dans la documentation de définition YAML de l'action.
Pour plus d'informations sur les connexions aux comptes, consultez[Permettre l'accès aux AWS ressources avec Connected Comptes AWS](ipa-connect-account.md). Pour plus d'informations sur l'ajout d'une connexion de compte à un environnement, consultez[Création d'un environnement](deploy-environments-creating-environment.md).
Interface utilisateur correspondante : la configuration tab/Environment/What est prête *my-environment* ? **/menu à trois points/ Changer de rôle**
## Name
(*action-name*/Environment/Connections/**Name**)
(Obligatoire s'[Connections](#github.environment.connections)il est inclus)
Spécifiez le nom de la connexion au compte.
Interface utilisateur correspondante : la configuration tab/Environment/What est prête *my-environment* ? **/menu à trois points/ Changer de rôle**
## Role
(*action-name*/Environment/Connections/**Role**)
(Obligatoire s'[Connections](#github.environment.connections)il est inclus)
Spécifiez le nom du rôle IAM que cette action utilise pour accéder et opérer dans des AWS services tels qu'Amazon S3 et Amazon ECR. Assurez-vous que ce rôle est ajouté à votre Compte AWS connexion dans votre espace. Pour ajouter un rôle IAM à une connexion à un compte, consultez[Ajout de rôles IAM à des connexions de compte](ipa-connect-account-addroles.md).
Si vous ne spécifiez aucun rôle IAM, l'action utilise le rôle IAM par défaut répertorié dans l'[environnement](deploy-environments.md) de la console. CodeCatalyst Si vous utilisez le rôle par défaut dans l'environnement, assurez-vous qu'il est conforme aux politiques suivantes.
**Note**
Vous pouvez utiliser le `CodeCatalystWorkflowDevelopmentRole-spaceName` rôle avec cette action. Pour plus d’informations sur ce rôle, consultez [Création du **CodeCatalystWorkflowDevelopmentRole-*spaceName***rôle pour votre compte et votre espace](ipa-iam-roles.md#ipa-iam-roles-service-create). Sachez que le `CodeCatalystWorkflowDevelopmentRole-spaceName` rôle dispose d'autorisations d'accès complètes, ce qui peut présenter un risque de sécurité. Nous vous recommandons de n'utiliser ce rôle que dans les didacticiels et les scénarios où la sécurité est moins préoccupante.
**Avertissement**
Limitez les autorisations à celles requises par l'**GitHub action** Action. L'utilisation d'un rôle doté d'autorisations plus étendues peut présenter un risque de sécurité.
Interface utilisateur correspondante : la configuration tab/Environment/What est prête *my-environment* ? **/menu à trois points/ Changer de rôle**
## Inputs
(*action-name*/**Inputs**)
(Facultatif)
La `Inputs` section définit les données dont une action a besoin lors de l'exécution d'un flux de travail.
**Note**
Un maximum de quatre entrées (une source et trois artefacts) sont autorisées par action **GitHub Actions**. Les variables ne sont pas prises en compte dans ce total.
Si vous devez faire référence à des fichiers résidant dans différentes entrées (par exemple, une source et un artefact), l'entrée source est l'entrée principale et l'artefact est l'entrée secondaire. Les références aux fichiers dans les entrées secondaires utilisent un préfixe spécial pour les distinguer du fichier principal. Pour en savoir plus, consultez [Exemple : Référencement de fichiers dans plusieurs artefacts](workflows-working-artifacts-ex.md#workflows-working-artifacts-ex-ref-file).
Interface utilisateur correspondante : onglet **Entrées**
## Sources
(*action-name*/Inputs/**Sources**)
(Facultatif)
Spécifiez les étiquettes qui représentent les référentiels sources qui seront nécessaires à l'action. Actuellement, la seule étiquette prise en charge est`WorkflowSource`, qui représente le référentiel source dans lequel votre fichier de définition de flux de travail est stocké.
Si vous omettez une source, vous devez spécifier au moins un artefact d'entrée sous. `action-name/Inputs/Artifacts`
Pour plus d'informations sur les sources, consultez [Connecter les référentiels sources aux flux de travail](workflows-sources.md).
Interface utilisateur correspondante : onglet **Entrées/Sources - facultatif**
## Artifacts - input
(*action-name*/Inputs/**Artifacts**)
(Facultatif)
Spécifiez les artefacts des actions précédentes que vous souhaitez fournir en entrée pour cette action. Ces artefacts doivent déjà être définis en tant qu'artefacts de sortie dans les actions précédentes.
Si vous ne spécifiez aucun artefact d'entrée, vous devez spécifier au moins un référentiel source sous`action-name/Inputs/Sources`.
Pour plus d'informations sur les artefacts, y compris des exemples, consultez[Partage d'artefacts et de fichiers entre les actions](workflows-working-artifacts.md).
**Note**
Si la liste déroulante **Artéfacts - optionnelle** n'est pas disponible (éditeur visuel), ou si vous recevez des erreurs lors de la validation de votre YAML (éditeur YAML), c'est peut-être parce que l'action ne prend en charge qu'une seule entrée. Dans ce cas, essayez de supprimer l'entrée source.
Interface utilisateur correspondante : onglet **Entrées/Artefacts - facultatif**
## Variables - input
(*action-name*/Inputs/**Variables**)
(Facultatif)
Spécifiez une séquence de name/value paires qui définit les variables d'entrée que vous souhaitez mettre à la disposition de l'action. Les noms de variables sont limités aux caractères alphanumériques (a-z, A-Z, 0-9), aux tirets (-) et aux traits de soulignement (\$1). Les espaces ne sont pas autorisés. Vous ne pouvez pas utiliser de guillemets pour activer les caractères spéciaux et les espaces dans les noms de variables.
Pour plus d'informations sur les variables, y compris des exemples, consultez[Utilisation de variables dans les flux de travail](workflows-working-with-variables.md).
Interface utilisateur correspondante : onglet **Entrées/Variables - facultatif**
## Outputs
(*action-name*/**Outputs**)
(Facultatif)
Définit les données produites par l'action lors de l'exécution d'un flux de travail.
Interface utilisateur correspondante : onglet **Sorties**
## Artifacts - output
(*action-name*/Outputs/**Artifacts**)
(Facultatif)
Spécifiez le nom d'un artefact généré par l'action. Les noms d'artifact doivent être uniques dans un flux de travail et sont limités aux caractères alphanumériques (a-z, A-Z, 0-9) et aux traits de soulignement (\$1). Les espaces, les tirets (-) et les autres caractères spéciaux ne sont pas autorisés. Vous ne pouvez pas utiliser de guillemets pour activer les espaces, les tirets et autres caractères spéciaux dans les noms d'artefacts en sortie.
Pour plus d'informations sur les artefacts, y compris des exemples, consultez[Partage d'artefacts et de fichiers entre les actions](workflows-working-artifacts.md).
**Interface utilisateur correspondante : onglet Sorties/Artefacts**
## Name
(*action-name*/Outputs/Artifacts/**Name**)
(Obligatoire s'[Artifacts - output](#github.outputs.artifacts)il est inclus)
Spécifiez le nom d'un artefact généré par l'action. Les noms d'artifact doivent être uniques dans un flux de travail et sont limités aux caractères alphanumériques (a-z, A-Z, 0-9) et aux traits de soulignement (\$1). Les espaces, les tirets (-) et les autres caractères spéciaux ne sont pas autorisés. Vous ne pouvez pas utiliser de guillemets pour activer les espaces, les tirets et autres caractères spéciaux dans les noms d'artefacts en sortie.
Pour plus d'informations sur les artefacts, y compris des exemples, consultez[Partage d'artefacts et de fichiers entre les actions](workflows-working-artifacts.md).
**Interface utilisateur correspondante : affiche le nom de l'tab/Artifacts/Addartefact/de l'artefact de construction**
## Files
(*action-name*/Outputs/Artifacts/**Files**)
(Obligatoire s'[Artifacts - output](#github.outputs.artifacts)il est inclus)
Spécifiez les fichiers CodeCatalyst inclus dans l'artefact généré par l'action. Ces fichiers sont générés par l'action du flux de travail lorsqu'elle s'exécute et sont également disponibles dans votre référentiel source. Les chemins de fichiers peuvent résider dans un référentiel source ou dans un artefact issu d'une action précédente, et sont relatifs au référentiel source ou à la racine de l'artefact. Vous pouvez utiliser des modèles globulaires pour définir des chemins. Exemples :
+ Pour spécifier un seul fichier situé à la racine de l'emplacement de votre build ou de votre référentiel source, utilisez`my-file.jar`.
+ Pour spécifier un seul fichier dans un sous-répertoire, utilisez `directory/my-file.jar` ou`directory/subdirectory/my-file.jar`.
+ Pour spécifier tous les fichiers, utilisez`"**/*"`. Le modèle `**` glob indique qu'il doit correspondre à un nombre quelconque de sous-répertoires.
+ Pour spécifier tous les fichiers et répertoires d'un répertoire nommé`directory`, utilisez`"directory/**/*"`. Le modèle `**` glob indique qu'il doit correspondre à un nombre quelconque de sous-répertoires.
+ Pour spécifier tous les fichiers d'un répertoire nommé`directory`, mais aucun de ses sous-répertoires, utilisez`"directory/*"`.
**Note**
Si le chemin de votre fichier comporte un ou plusieurs astérisques (`*`) ou autres caractères spéciaux, mettez-le entre guillemets (). `""` Pour plus d'informations sur les caractères spéciaux, consultez[Consignes et conventions de syntaxe](workflow-reference.md#workflow.terms.syntax.conv).
Pour plus d'informations sur les artefacts, y compris des exemples, consultez[Partage d'artefacts et de fichiers entre les actions](workflows-working-artifacts.md).
**Note**
Vous devrez peut-être ajouter un préfixe au chemin du fichier pour indiquer dans quel artefact ou dans quelle source le trouver. Pour plus d’informations, consultez [Référencement des fichiers du référentiel source](workflows-sources-reference-files.md) et [Référencement de fichiers dans un artefact](workflows-working-artifacts-refer-files.md).
Interface utilisateur correspondante : produit des tab/Artifacts/Add **artéfacts/fichiers** produits par build
## Variables - output
(*action-name*/Outputs/**Variables**)
(Facultatif)
Spécifiez les variables que vous souhaitez que l'action exporte afin qu'elles puissent être utilisées par les actions suivantes.
Pour plus d'informations sur les variables, y compris des exemples, consultez[Utilisation de variables dans les flux de travail](workflows-working-with-variables.md).
**Interface utilisateur correspondante : onglet Sorties/Variables/Ajouter une variable**
## nom-variable-1
(*action-name*/Outputs/Variables**nom-variable 1**)
(Facultatif)
Spécifiez le nom de la variable que vous souhaitez que l'action exporte. Cette variable doit déjà être définie dans la `Steps` section `Inputs` ou de la même action.
Pour plus d'informations sur les variables, y compris des exemples, consultez[Utilisation de variables dans les flux de travail](workflows-working-with-variables.md).
**Interface utilisateur correspondante : tab/Variables/Add variable/nom de sortie**
## AutoDiscoverReports
(*action-name*/Outputs/**AutoDiscoverReports**)
(Facultatif)
Définit la configuration de la fonctionnalité de découverte automatique.
Lorsque vous activez la découverte automatique, les CodeCatalyst recherches `Inputs` sont toutes transmises à l'action ainsi que tous les fichiers générés par l'action elle-même, à la recherche de rapports de test, de couverture de code et d'analyse de la composition logicielle (SCA). Pour chaque rapport trouvé, le CodeCatalyst transforme en CodeCatalyst rapport. Un *CodeCatalyst rapport* est un rapport entièrement intégré au CodeCatalyst service et qui peut être consulté et manipulé via la CodeCatalyst console.
**Note**
Par défaut, la fonction de découverte automatique inspecte tous les fichiers. Vous pouvez limiter les fichiers inspectés à l'aide des [ExcludePaths](#github.reports.excludepaths) propriétés [IncludePaths](#github.reports.includepaths) or.
Interface utilisateur correspondante : *aucune*
## Enabled
(*action-name*/Outputs/AutoDiscoverReports/**Enabled**)
(Facultatif)
Activez ou désactivez la fonction de découverte automatique.
Les valeurs valides sont `true` ou `false`.
S'il `Enabled` est omis, la valeur par défaut est`true`.
**Interface utilisateur correspondante : onglet Sorties/Rapports/Découverte automatique des rapports**
## ReportNamePrefix
(*action-name*/Outputs/AutoDiscoverReports/**ReportNamePrefix**)
(Obligatoire s'[AutoDiscoverReports](#github.outputs.autodiscover)il est inclus et activé)
Spécifiez un préfixe qui CodeCatalyst précède tous les rapports trouvés afin de nommer les rapports associés. CodeCatalyst Par exemple, si vous spécifiez le préfixe de`AutoDiscovered`, et que vous CodeCatalyst découvrez automatiquement deux rapports de test`TestSuiteTwo.xml`, `TestSuiteOne.xml` et, les CodeCatalyst rapports associés seront nommés `AutoDiscoveredTestSuiteOne` et. `AutoDiscoveredTestSuiteTwo`
Interface utilisateur correspondante : les sorties tab/Reports/Automatically découvrent les rapports/le préfixe **du rapport**
## IncludePaths
(*action-name*/Outputs/AutoDiscoverReports/**IncludePaths**)
Or
(*action-name*/Outputs/Reports/*report-name-1*/**IncludePaths**)
(Obligatoire s'[AutoDiscoverReports](#github.outputs.autodiscover)il est inclus et activé, ou s'il [Reports](#github.configuration.reports) est inclus)
Spécifiez les fichiers et les chemins de fichiers CodeCatalyst inclus lors de la recherche de rapports bruts. Par exemple, si vous le spécifiez`"/test/report/*"`, CodeCatalyst recherche l'intégralité de [l'image de construction](build-images.md) utilisée par l'action à la recherche du `/test/report/*` répertoire. Lorsqu'il trouve ce répertoire, CodeCatalyst il recherche des rapports dans ce répertoire.
**Note**
Si le chemin de votre fichier comporte un ou plusieurs astérisques (`*`) ou autres caractères spéciaux, mettez-le entre guillemets (). `""` Pour plus d'informations sur les caractères spéciaux, consultez[Consignes et conventions de syntaxe](workflow-reference.md#workflow.terms.syntax.conv).
Si cette propriété est omise, la valeur par défaut est`"**/*"`, ce qui signifie que la recherche inclut tous les fichiers, quel que soit leur chemin.
**Note**
Pour les rapports configurés manuellement, `IncludePaths` il doit s'agir d'un modèle global correspondant à un seul fichier.
Interface utilisateur correspondante :
+ **Affiche les tab/Reports/Automatically discover reports/'Include/exclude chemins «/Inclure les chemins »**
+ **Les sorties tab/Reports/Manually configurent les rapports/ *report-name-1* /'Include/Exclure les chemins'/Inclure les chemins**
## ExcludePaths
(*action-name*/Outputs/AutoDiscoverReports/**ExcludePaths**)
Or
(*action-name*/Outputs/Reports/*report-name-1*/**ExcludePaths**)
(Facultatif)
Spécifiez les fichiers et les chemins de fichiers à CodeCatalyst exclure lors de la recherche de rapports bruts. Par exemple, si vous le spécifiez`"/test/my-reports/**/*"`, ne CodeCatalyst recherchera pas de fichiers dans le `/test/my-reports/` répertoire. Pour ignorer tous les fichiers d'un répertoire, utilisez le modèle `**/*` glob.
**Note**
Si le chemin de votre fichier comporte un ou plusieurs astérisques (`*`) ou autres caractères spéciaux, mettez-le entre guillemets (). `""` Pour plus d'informations sur les caractères spéciaux, consultez[Consignes et conventions de syntaxe](workflow-reference.md#workflow.terms.syntax.conv).
Interface utilisateur correspondante :
+ **Affiche les tab/Reports/Automatically discover reports/'Include/exclude chemins «/Exclure les chemins »**
+ **Les sorties tab/Reports/Manually configurent les rapports/ *report-name-1* /'Include/Exclure les chemins'/Exclure les chemins**
## SuccessCriteria
(*action-name*/Outputs/AutoDiscoverReports/**SuccessCriteria**)
Or
(*action-name*/Outputs/Reports/*report-name-1*/**SuccessCriteria**)
(Facultatif)
Spécifiez les critères de réussite pour les rapports de test, de couverture du code, d'analyse de la composition logicielle (SCA) et d'analyse statique (SA).
Pour de plus amples informations, veuillez consulter [Configuration des critères de réussite pour les rapports](test-config-action.md#test.success-criteria).
Interface utilisateur correspondante :
+ Résultats, tab/Reports/Automatically découverte des rapports/critères de **réussite**
+ Les sorties tab/Reports/Manually configurent les rapports/*report-name-1*/Critères de **réussite**
## PassRate
(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**PassRate**)
Or
(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**PassRate**)
(Facultatif)
Spécifiez le pourcentage de tests dans un rapport de test qui doivent être réussis pour que le CodeCatalyst rapport associé soit marqué comme réussi. Les valeurs valides incluent les nombres décimaux. Par exemple `50`, `60.5`. Les critères relatifs au taux de réussite ne sont appliqués qu'aux rapports de test. Pour plus d'informations sur les rapports de test, consultez[Rapports d'essais](test-workflow-actions.md#test-reports).
Interface utilisateur correspondante :
+ tab/Reports/Automatically discover reports/Success**Critères de sorties/taux de réussite**
+ **Les sorties tab/Reports/Manually configurent les rapports/ *report-name-1* /Critères de succès/ Taux de réussite**
## LineCoverage
(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**LineCoverage**)
Or
(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**LineCoverage**)
(Facultatif)
Spécifiez le pourcentage de lignes d'un rapport de couverture de code qui doivent être couvertes pour que le CodeCatalyst rapport associé soit marqué comme transmis. Les valeurs valides incluent les nombres décimaux. Par exemple `50`, `60.5`. Les critères de couverture de ligne sont appliqués uniquement aux rapports de couverture de code. Pour plus d'informations sur les rapports de couverture du code, consultez[Rapports de couverture du code](test-workflow-actions.md#test-code-coverage-reports).
Interface utilisateur correspondante :
+ tab/Reports/Automatically discover reports/Success**Critères de sorties/couverture de ligne**
+ **Les sorties tab/Reports/Manually configurent les rapports/ *report-name-1* /Critères de succès/ Couverture des lignes**
## BranchCoverage
(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**BranchCoverage**)
Or
(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**BranchCoverage**)
(Facultatif)
Spécifiez le pourcentage de branches dans un rapport de couverture de code qui doivent être couvertes pour que le CodeCatalyst rapport associé soit marqué comme transmis. Les valeurs valides incluent les nombres décimaux. Par exemple `50`, `60.5`. Les critères de couverture des succursales sont appliqués uniquement aux rapports de couverture par code. Pour plus d'informations sur les rapports de couverture du code, consultez[Rapports de couverture du code](test-workflow-actions.md#test-code-coverage-reports).
Interface utilisateur correspondante :
+ tab/Reports/Automatically discover reports/Success**Critères de sorties/couverture des branches**
+ **Les sorties tab/Reports/Manually configurent les rapports/ *report-name-1* /Critères de succès/ Couverture des branches**
## Vulnerabilities
(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**Vulnerabilities**)
Or
(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**Vulnerabilities**)
(Facultatif)
Spécifiez le nombre maximum et la gravité des vulnérabilités autorisées dans le rapport SCA pour que le CodeCatalyst rapport associé soit marqué comme transmis. Pour définir les vulnérabilités, vous devez spécifier :
+ La gravité minimale des vulnérabilités que vous souhaitez inclure dans le décompte. Les valeurs valides, de la plus sévère à la moins sévère, sont les suivantes : `CRITICAL``HIGH`,`MEDIUM`,`LOW`,,`INFORMATIONAL`.
Par exemple, si vous le souhaitez`HIGH`, `HIGH` les `CRITICAL` vulnérabilités seront comptabilisées.
+ Le nombre maximum de vulnérabilités de la gravité spécifiée que vous souhaitez autoriser. Le dépassement de ce nombre entraîne le marquage CodeCatalyst du rapport comme ayant échoué. Les valeurs valides sont des nombres entiers.
Les critères de vulnérabilité ne sont appliqués qu'aux rapports SCA. Pour plus d'informations sur les rapports SCA, consultez[Rapports d'analyse de la composition des logiciels](test-workflow-actions.md#test-sca-reports).
Pour spécifier la sévérité minimale, utilisez la `Severity` propriété. Pour spécifier le nombre maximum de vulnérabilités, utilisez la `Number` propriété.
Pour plus d'informations sur les rapports SCA, consultez[Types de rapports sur la qualité](test-workflow-actions.md#test-reporting).
Interface utilisateur correspondante :
+ tab/Reports/Automatically discover reports/Success**Critères de sorties/vulnérabilités**
+ **Les sorties tab/Reports/Manually configurent les rapports/ *report-name-1* /Critères de succès/ Vulnérabilités**
## Reports
(*action-name*/Outputs/**Reports** )
(Facultatif)
Section qui spécifie la configuration des rapports de test.
**Interface utilisateur correspondante : onglet Sorties/Rapports**
## nom-du-rapport-1
(*action-name*/Outputs/Reports/**nom-de-rapport-1**)
(Obligatoire s'[Reports](#github.configuration.reports)il est inclus)
Le nom que vous souhaitez donner au CodeCatalyst rapport qui sera généré à partir de vos rapports bruts.
Interface utilisateur correspondante : les sorties tab/Reports/Manually configurent les rapports/nom **du rapport**
## Format
(*action-name*/Outputs/Reports/*report-name-1*/**Format**)
(Obligatoire s'[Reports](#github.configuration.reports)il est inclus)
Spécifiez le format de fichier que vous utilisez pour vos rapports. Les valeurs possibles sont les suivantes.
+ Pour les rapports de test :
+ Pour Cucumber JSON, spécifiez **Cucumber** (éditeur visuel) ou `CUCUMBERJSON` (éditeur YAML).
+ Pour le JUnit XML, spécifiez **JUnit**(éditeur visuel) ou `JUNITXML` (éditeur YAML).
+ Pour le NUnit XML, spécifiez **NUnit**(éditeur visuel) ou `NUNITXML` (éditeur YAML).
+ Pour NUnit 3 XML, spécifiez **NUnit3**(éditeur visuel) ou `NUNIT3XML` (éditeur YAML).
+ Pour Visual Studio TRX, spécifiez **Visual Studio TRX** (éditeur visuel) ou `VISUALSTUDIOTRX` (éditeur YAML).
+ Pour TestNG XML, spécifiez **TestNG** (éditeur visuel) ou `TESTNGXML` (éditeur YAML).
+ Pour les rapports sur la couverture du code :
+ Pour Clover XML, spécifiez **Clover** (éditeur visuel) ou `CLOVERXML` (éditeur YAML).
+ Pour Cobertura XML, spécifiez **Cobertura** (éditeur visuel) ou `COBERTURAXML` (éditeur YAML).
+ Pour le JaCoCo XML, spécifiez **JaCoCo**(éditeur visuel) ou `JACOCOXML` (éditeur YAML).
+ Pour le SimpleCov JSON généré par [simplecov](https://github.com/simplecov-ruby/simplecov), et non par [simplecov-json](https://github.com/vicentllongo/simplecov-json), spécifiez **Simplecov (éditeur visuel) ou (éditeur YAML**). `SIMPLECOV`
+ Pour les rapports d'analyse de composition logicielle (SCA) :
+ Pour SARIF, spécifiez **SARIF** (éditeur visuel) ou `SARIFSCA` (éditeur YAML).
Interface utilisateur correspondante : tab/Reports/Manually configure reports/Add Rapport de *report-name-1* sortie// **Type de rapport et format de** **rapport**
## Configuration
(*action-name*/**Configuration**)
(Obligatoire) Section dans laquelle vous pouvez définir les propriétés de configuration de l'action.
Interface utilisateur correspondante : onglet **Configuration**
## Steps
(*action-name*/Configuration/**Steps**)
(Obligatoire)
Spécifiez votre code GitHub d'action tel qu'il apparaît sur la page de détails de l'action dans [GitHub Marketplace](https://github.com/marketplace). Ajoutez le code en suivant les instructions suivantes :
1. Collez le code de la `steps:` section GitHub Action dans la `Steps:` section du CodeCatalyst flux de travail. Le code commence par un tiret (-) et ressemble à ce qui suit.
GitHub code à coller :
```
- name: Lint Code Base
uses: github/super-linter@v4
env:
VALIDATE_ALL_CODEBASE: false
DEFAULT_BRANCH: master
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
```
1. Passez en revue le code que vous venez de coller et modifiez-le si nécessaire afin qu'il soit conforme aux CodeCatalyst normes. Par exemple, avec le bloc de code précédent, vous pouvez supprimer le code en *red italics* gras et l'ajouter en **gras**.
CodeCatalyst flux de travail yaml :
```
Steps:
- name: Lint Code Base
uses: github/super-linter@v4
env:
VALIDATE_ALL_CODEBASE: false
DEFAULT_BRANCH: mastermain
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
```
1. Pour le code supplémentaire inclus dans l' GitHub action mais qui n'existe pas dans la `steps:` section, ajoutez-le au CodeCatalyst flux de travail à l'aide d'un code CodeCatalyst équivalent. Vous pouvez les consulter [Définition du flux de travail YAML](workflow-reference.md) pour avoir un aperçu de la manière dont vous pourriez porter votre GitHub code CodeCatalyst. Les étapes de migration détaillées ne sont pas abordées dans ce guide.
Voici un exemple de la manière de spécifier des chemins de fichiers dans une action **GitHub Actions** :
```
Steps:
- name: Lint Code Base
uses: github/super-linter@v4
...
- run: cd /sources/WorkflowSource/MyFolder/ && cat file.txt
- run: cd /artifacts/MyGitHubAction/MyArtifact/MyFolder/ && cat file2.txt
```
Pour plus d'informations sur la spécification des chemins de fichiers, reportez-vous [Référencement des fichiers du référentiel source](workflows-sources-reference-files.md) aux sections et[Référencement de fichiers dans un artefact](workflows-working-artifacts-refer-files.md).
Interface utilisateur correspondante : onglet **GitHub Configuration/Actions YAML**