Programmation en binôme dans les actions Terraform et GitHub avec ChatGPT | de Wenqi Glantz | décembre 2022

Rencontrez ChatGPT, votre nouveau programmeur de paires

Depuis sa sortie par OpenAI le 30 novembre 2022, ChatGPT (Generative Pre-trained Transformer) a fait sensation dans les industries du monde entier, en particulier dans la communauté des développeurs. Explorons ChatGPT dans les domaines spécifiques du développement de flux de travail Terraform et GitHub Actions dans cette histoire, même s’il peut écrire du code dans de nombreux autres langages.

Demandez à ChatGPT de coder, vous serez stupéfait du résultat qu’il produit. Voyons comment il écrit le code de configuration Terraform et les workflows GitHub Actions.

Bon programmeur

J’ai posé la question suivante à ChatGPT :

Pouvez-vous écrire du code terraform pour créer un nouveau référentiel github et configurer des règles de protection de branche ?

Sa réponse :

Bien sûr, voici un exemple de la façon dont vous pouvez utiliser Terraform pour créer un nouveau référentiel GitHub et configurer des règles de protection de branche.

Tout d’abord, vous devrez vous authentifier auprès de GitHub en utilisant le github fournisseur. Vous pouvez le faire en ajoutant un provider block à votre configuration Terraform et en spécifiant votre jeton d’accès GitHub :

provider "github" {
token = var.github_token
}

Ensuite, vous pouvez utiliser le github_repository ressource pour créer un nouveau référentiel. L’exemple suivant crée un référentiel avec le nom « my-repo » et la description « My repository » :

resource "github_repository" "repo" {
name        = "my-repo"
description = "My repository"
}

Pour configurer des règles de protection de branche pour le référentiel, vous pouvez utiliser le github_branch_protection Ressource. L’exemple suivant configure la protection de branche pour le master branche, nécessitant au moins une révision d’un réviseur désigné et au moins une révision d’approbation des propriétaires de code avant qu’une pull request puisse être fusionnée :

resource "github_branch_protection" "protection" {
repository = github_repository.repo.name
branch     = "master"
required_pull_request_reviews {
dismissal_restrictions {
users = ["user1", "user2"]
teams = ["team1", "team2"]
}
require_code_owner_reviews = true
}
}

Ceci n’est qu’un exemple de base, et vous pouvez personnaliser davantage les règles de protection de branche en spécifiant des options supplémentaires. Pour plus d’informations, vous pouvez vous référer à la documentation de l’API GitHub ou à la documentation de Terraform pour le github_branch_protection Ressource.

Impressionnant! Instructions étape par étape! J’étais émerveillé. J’aime particulièrement le fait qu’en plus de produire un exemple de code de base, ChatGPT nous indique comment personnaliser le code pour améliorer l’exemple.

Passant aux actions GitHub, j’ai posé la question suivante :

Pouvez-vous écrire un flux de travail d’actions github pour créer une image native GraalVM à l’aide de Buildpacks, et transmettre cette image à AWS ECR ?

Sa réponse :

Bien sûr, voici un exemple de flux de travail GitHub Actions qui crée une image native GraalVM à l’aide de Buildpacks et transmet l’image à AWS ECR :

name: Build and push GraalVM native image
on:
push:
branches: [ master ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Set up JDK 14
uses: actions/setup-java@v1
with:
java-version: 14
- name: Set up AWS CLI
uses: aws-actions/configure-aws-credentials@v1
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: us-east-1
- name: Build GraalVM native image
run: |
curl -fsSL  | tar -xzv
./pack build my-image --builder gcr.io/buildpacks/builder:v1 --buildpack graalvm-ce
- name: Push image to ECR
run: |
$(aws ecr get-login --no-include-email)
docker tag my-image:latest my-repository.dkr.ecr.us-east-1.amazonaws.com/my-image:latest
docker push my-repository.dkr.ecr.us-east-1.amazonaws.com/my-image:latest

Ce flux de travail écoute les poussées vers le master branche et exécute les étapes suivantes :

1. Il utilise le actions/checkout@v2 action pour extraire le code dans le référentiel.

2. Il configure JDK 14 en utilisant le actions/setup-java@v1 action.

3. Il configure l’AWS CLI à l’aide du aws-actions/configure-aws-credentials@v1 action, qui vous oblige à fournir votre ID de clé d’accès AWS et votre clé d’accès secrète en tant que secrets dans les paramètres du référentiel.

4. Il exécute une commande pour créer l’image native GraalVM à l’aide de Buildpacks. Cette commande installe le pack utilitaire et l’utilise pour construire une image avec le graalvm-ce pack de construction.

5. Il exécute une commande pour transmettre l’image à AWS ECR. Cette commande se connecte à ECR en utilisant le aws ecr get-login commande, marque l’image avec l’URI du référentiel ECR et envoie l’image dans le référentiel.

Vous devrez modifier cet exemple pour qu’il corresponde à votre cas d’utilisation spécifique. Par exemple, vous devrez peut-être spécifier une version JDK différente ou modifier le nom de l’image et du référentiel ECR. Vous pouvez également personnaliser davantage le flux de travail en ajoutant des étapes supplémentaires ou en utilisant différentes actions.

Wow, assez décent! Même s’il diffère un peu du workflow CI pour l’image native GraalVM pour une application Spring Boot 3 que j’ai développée dans mon histoire Going Native with Spring Boot 3 GA, je suis impressionné par ce que ChatGPT vient de proposer, un joli workflow barebone pour construire dessus, pas mal! Et l’explication étape par étape des détails de l’exemple de flux de travail est vraiment cool !

Excellent réviseur de code et dépanneur

J’ai demandé à ChatGPT de repérer tout problème dans cet extrait de code Terraform :

resource "aws_alb_listener" "https" {
load_balancer_arn = aws_lb.ecs_alb.id
port              = "443"
protocol          = "HTTPS"
ssl_policy        = "ELBSecurityPolicy-2016-08"
certificate_arn   = var.alb_https_certificate_arn
default_action {
target_group_arn = aws_alb_target_group.ecs_alb_target_group.arn
type             = "forward"
}
}

Sa réponse :

Il n’y a pas d’erreur de syntaxe dans l’extrait de code que vous avez fourni. Cependant, il y a quelques éléments à considérer :

Le load_balancer_arn la variable est définie sur id du aws_lb.ecs_alb Ressource. Cela fonctionnera si le ecs_alb ressource est un AWS Load Balancer (ALB) unique plutôt qu’une liste d’ALB.

Le port est définie sur la valeur fixe « 443 », qui est le port standard pour le trafic HTTPS. Il s’agit généralement d’une bonne pratique, mais il est important de s’assurer que le port n’est pas déjà utilisé par un autre service ou écouteur sur l’ALB.

Le ssl_policy est définie sur une valeur fixe de « ELBSecurityPolicy-2016-08 ». Cette stratégie peut ne pas convenir à tous les cas d’utilisation. Il est recommandé d’utiliser une politique plus récente et sécurisée, telle que « ELBSecurityPolicy-TLS-1-2-2017-01 ».

Le certificate_arn la variable est définie sur alb_https_certificate_arn variable d’entrée. Il est important de s’assurer que le certificat est valide et correctement configuré pour être utilisé avec l’ALB.

Le default_action block spécifie un groupe cible et un type de « forward ». Il est recommandé de spécifier également un path_pattern et priority pour l’action, afin de permettre un contrôle plus précis sur la manière dont le trafic est acheminé vers le groupe cible.

Dans l’ensemble, le code semble être correctement configuré pour créer un écouteur HTTPS pour un AWS ALB, mais il est important d’examiner et de tester attentivement la configuration pour s’assurer qu’elle répond aux exigences de votre cas d’utilisation.

Sa suggestion sur ssl_policy est exactement ce que je cherchais. Très beau! Je suis surtout impressionné par l’explication détaillée qu’il a proposée. Aucun examinateur de code humain ne pourrait jamais me donner un commentaire d’examen aussi détaillé. Belles compétences en documentation ChatGPT !

Mettons maintenant nos lunettes de critiques, recherchons les failles de ChatGPT.

Incohérence entre sa réponse et les extraits de code

Quand j’ai demandé à ChatGPT de suggérer comment utiliser la fonction Terraform templatefile pour importer la spécification OpenAPI afin de créer une passerelle API HTTP, j’ai remarqué que la réponse que j’ai obtenue contenait un extrait de code et une description incompatibles, voir la capture d’écran ci-dessous. À l’étape 1, il est clairement indiqué de définir templatefile fonction, mais le code appelle file fonction uniquement.

J’ai ensuite essayé de porter à son attention cette erreur, ChatGPT est assez humble pour faire cette erreur, mais la correction est toujours incorrecte, voir la capture d’écran ci-dessous, son code appelle toujours file fonction, non templatefile comme je l’ai demandé. Nous avons fait plusieurs allers-retours, il n’a pas compris comment corriger son code. Je souris. Vous n’allez pas prendre mon travail, pour l’instant !

Incohérence dans les réponses à la même question

J’ai demandé à ChatGPT comment écrire un flux de travail GitHub Actions pour créer une application Java avec maven et créer son image docker et la télécharger sur AWS ECR. Dans deux fenêtres de discussion différentes, avec la même question, j’ai obtenu deux réponses différentes, voir la capture d’écran ci-dessous, en particulier les étapes surlignées en rouge.

Chat #1 :

Chat n° 2 :

Les deux réponses étaient assez différentes en ce sens que :

• Les versions de Java diffèrent, le chat #1 configure Java v14 tandis que le chat #2 configure Java v8.
• Les commandes de construction Maven diffèrent, le chat #1 ne saute pas le test tandis que le chat #2 saute le test.
• Les actions d’authentification auprès d’AWS diffèrent, le chat #1 utilise aws/actions/login-to-aws tandis que le chat #2 utilise aws/actions/login.
• La logique de la balise d’image diffère, le chat #1 utilise git SHA comme balise d’image tandis que le chat #2 utilise le « dernier » par défaut comme balise d’image.

Il convient de noter que ce sont des différences à ne pas ignorer même s’il est facile pour un développeur d’apporter des modifications au code généré par le bot. Ne prenez donc pas un code généré pour acquis. Faites votre propre diligence raisonnable pour tester et vous assurer que le code fonctionne bien et qu’il est de qualité.

Action GitHub inexistante générée par ChatGPT

Comme nous l’avons noté ci-dessus, les deux chats ont utilisé deux actions différentes pour s’authentifier auprès d’AWS. Cependant, aucune de ces actions n’existe dans aws-actions dépôt ! C’est définitivement un drapeau rouge. J’ai poursuivi en demandant la bonne action car aucune de celles-ci n’existait dans GitHub, je suis entré dans une boucle avec ChatGPT demandant un lien fonctionnel vers l’une de ces actions, mais les liens fournis étaient tous des liens morts, voir nos conversations ci-dessous. J’ai réalisé que je parlais à un bot après tout, alors j’ai fini par abandonner. Ce scénario me fait me demander si la base de code que ChatGPT tire d’une manière ou d’une autre est obsolète, car la méthode recommandée par AWS pour s’authentifier auprès d’AWS consiste à utiliser action aws-actions/configure-aws-credentialspas ces deux actions proposées par ChatGPT.

Certaines bonnes pratiques ne sont pas suivies

Je remarque que le code généré par le bot ne suit parfois pas les meilleures pratiques. Par exemple, le workflow GraalVM mentionné ci-dessus appelle aws-actions/configure-aws-credentialsvoir extrait ci-dessous.

- name: Set up AWS CLI
uses: aws-actions/configure-aws-credentials@v1
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: us-east-1

L’action aws-actions/configure-aws-credentials Page GitHub indique clairement :

Nous recommandons d’utiliser Fournisseur OIDC de GitHub pour obtenir les informations d’identification de courte durée nécessaires à vos actions. En précisant role-to-assume sans fournir de aws-access-key-id ou un web-identity-token-file signalera à l’action que vous souhaitez utiliser le fournisseur OIDC.

De tous mes tests avec ChatGPT, je n’ai pas vu un seul cas où ChatGPT a produit du code à utiliser role-to-assume pour s’authentifier auprès d’AWS. Encore une fois, l’expérience d’un développeur ne peut pas être facilement remplacée par un bot !

En jouant, j’ai également rencontré l’erreur suivante à plusieurs reprises – bien que l’ouverture d’une nouvelle fenêtre de discussion ait généralement résolu l’erreur.

ChatGPT, avec son énorme potentiel, est révolutionnaire. L’IA est arrivée plus vite que prévu et a eu un impact sur notre vie professionnelle. Ce qu’il fait, ce qu’il peut faire, est tout simplement stupéfiant. Ce n’est qu’un début, comme nous l’avons observé ci-dessus, il y a certainement de la place pour que ChatGPT mûrisse. À mesure qu’il grandit, on ne peut qu’imaginer comment il pourrait évoluer. Explorons et invitons ChatGPT à être notre programmeur en binôme et à nous aider à augmenter notre productivité, en nous aidant à résoudre les problèmes quotidiens. Laissez ChatGPT nous aider à être plus productifs pendant que nous l’aidons à mûrir en le testant et en l’utilisant.

Alors que certains disent que ChatGPT va reprendre nos jobs de développeurs dans les années à venir, je suis optimiste, je crois que la capacité du cerveau humain dépasse de loin celle des bots. Même si nous perdons certains emplois au profit des robots, nos cerveaux sont entraînés à rechercher et à identifier des opportunités innovantes vers lesquelles effectuer la transition. Laissez les bots nous mettre au défi d’innover, de grandir.

Bon codage !