provider-resources

Aperçu de la compétence provider-resources

provider-resources est une compétence de développement de provider Terraform destinée à implémenter des ressources et des sources de données avec le Terraform Plugin Framework. Elle est particulièrement adaptée aux ingénieurs backend qui construisent des endpoints de provider fondés sur des opérations CRUD, conçoivent le schéma et l’état, ou ajoutent des tests d’acceptation avec moins d’allers-retours qu’avec une requête générique.

Le vrai besoin n’est pas, en théorie, de « écrire du code Terraform ». Il s’agit plutôt de structurer une fonctionnalité de provider pour qu’elle respecte les conventions HashiCorp, qu’elle se mappe proprement à des API distantes et qu’elle soit testable avant son intégration. C’est ce qui rend la provider-resources skill la plus utile lorsque vous connaissez déjà la forme de l’API cible et avez besoin d’aide à l’implémentation, pas lorsque vous êtes encore en train de décider ce que le provider doit exposer.

Ce que provider-resources couvre

Cette compétence se concentre sur les patterns d’implémentation des ressources et des sources de données, l’organisation des fichiers, la structuration du schéma, la gestion de l’état et le workflow des tests d’acceptation. Elle convient particulièrement aux travaux de provider-resources for Backend Development, lorsque l’API backend fait office de source de vérité et que Terraform doit maintenir l’état en cohérence avec elle.

Quand cette compétence est le bon choix

Utilisez provider-resources lorsque vous avez besoin d’aide pour le CRUD d’une ressource, le comportement de l’import, les attributs computed et optional, la conception de schémas imbriqués ou la structure des packages dans un dépôt de provider. Elle est aussi utile si vous voulez une démarche d’implémentation cohérente pour un nouvel endpoint, plutôt que de reconstituer des patterns à partir de plusieurs exemples.

Ce qu’il faut vérifier avant l’installation

Cette compétence suppose un travail sur un provider Terraform et sur le Plugin Framework. Si vous avez besoin de modules, de publication dans le registry, ou d’un squelette de provider à partir de zéro, ce n’est pas le bon niveau de focus. Elle ne remplace pas non plus la connaissance de l’API propre au produit : vous devez toujours disposer du contrat de l’endpoint, des modes d’erreur et des règles d’identité.

Comment utiliser la compétence provider-resources

Installer provider-resources dans votre jeu de compétences

Utilisez le flux d’installation du repo pour ajouter la compétence, puis référencez-la dans le contexte d’une tâche de provider précise :

npx skills add hashicorp/agent-skills --skill provider-resources

Si votre environnement utilise un autre chargeur de compétences, gardez le même nom de compétence et pointez-le vers le chemin terraform/provider-development/skills/provider-resources.

Commencer par les bons fichiers source

Lisez d’abord SKILL.md, puis examinez les sections qui définissent la forme d’implémentation et les conventions. Dans ce dépôt, cela signifie qu’il faut prêter attention à la vue d’ensemble et aux নির্দেশications sur la structure des fichiers avant de lancer la génération de code. Si votre copie locale contient des modèles de provider supplémentaires ou des compétences voisines, comparez-les seulement après avoir compris le workflow de ressource propre à celle-ci.

Donner à la compétence un brief de tâche complet

L’usage de provider-resources est bien plus efficace si vous fournissez le type d’objet distant, les identifiants requis, le comportement CRUD et les règles particulières d’état. Une requête faible dit « construis une ressource ». Une requête plus solide dit :

• l’objet API et l’endpoint
• les champs required, optional, computed ou ForceNew
• comment détecter le drift
• comment les mises à jour sont appliquées
• si la lecture est éventuellement cohérente
• ce que les tests d’acceptation doivent démontrer

Ces informations permettent à la compétence de produire du code et des recommandations qui collent au backend, au lieu d’inventer des hypothèses.

Utiliser un workflow centré sur le dépôt

Pour obtenir les meilleurs résultats, demandez d’abord un plan qui mappe la ressource sur la structure existante du provider, puis implémentez une pièce à la fois : schéma, create/read/update/delete, importer et tests. Si le dépôt contient déjà des ressources similaires, indiquez-les explicitement afin que la compétence réutilise les patterns locaux plutôt que des exemples génériques.

FAQ de la compétence provider-resources

provider-resources sert-elle uniquement aux nouvelles ressources ?

Non. La compétence est tout aussi utile pour des refactorings, l’ajout d’une source de données à côté d’une ressource existante, ou la correction de problèmes d’état et de tests dans un provider déjà en place. Elle est particulièrement forte lorsque l’API existe déjà et que le travail consiste à l’exprimer proprement dans Terraform.

Faut-il déjà connaître le Plugin Framework ?

Pas nécessairement. La compétence peut aider un débutant à suivre la bonne structure, mais elle fonctionne mieux si vous pouvez décrire clairement l’API et le comportement du provider. Si vous ne pouvez pas expliquer l’identité, le cycle de vie ou la sémantique des mises à jour, rassemblez ces éléments d’abord, ou attendez-vous à une première version approximative.

En quoi est-ce différent d’une requête normale ?

Une requête normale produit souvent un code de provider plausible, mais sans conventions locales ni discipline de test. provider-resources est plus utile parce qu’elle pousse vers une structure native Terraform, un couplage ressource/documentation et une logique de tests d’acceptation, ce qui réduit les reprises pendant la revue.

Quand ne faut-il pas utiliser cette compétence ?

Ne l’utilisez pas pour des applications backend CRUD sans rapport, pour l’architecture Go générale, ni pour l’écriture de modules Terraform. Si votre tâche concerne surtout le packaging, l’automatisation des releases ou la documentation du registry, choisissez plutôt une compétence centrée sur ces sujets.

Comment améliorer la compétence provider-resources

Fournir des faits d’API, pas seulement des noms de fonctionnalités

Le moyen le plus rapide d’améliorer la qualité des sorties de provider-resources est de décrire précisément le contrat de l’objet : IDs, inputs de création, forme de la lecture, champs modifiables et sémantique de suppression. Si l’API présente des particularités comme une création asynchrone, des mises à jour partielles ou des noms générés par le serveur, dites-le dès le départ. Ces détails changent la conception du provider.

Indiquer le pattern local que vous voulez voir repris

Si le dépôt contient déjà un équivalent proche, nommez le fichier ou la ressource exacts. Cela aide la compétence à s’aligner sur les conventions existantes du provider au lieu d’inventer un nouveau style. C’est particulièrement important pour le nommage du schéma, les helpers de test et les transitions d’état.

Demander d’abord les parties les plus risquées

Les zones les plus susceptibles d’échouer sont généralement la gestion de l’import et de l’état, les champs computed et les tests d’acceptation. Demandez à la compétence de traiter ces points avant de peaufiner la documentation ou les fonctions utilitaires. Si la première réponse est proche mais incomplète, itérez à partir de la sortie du test en échec ou d’un diff du schéma, afin que le tour suivant corrige exactement l’écart.