Documentation du Fournisseur Terraform

Respecter Ce Flux de Travail

Mappez les changements de code aux cibles de documentation exactes : index du fournisseur, ressources, sources de données, ressources éphémères, ressources listées, fonctions, actions ou guides.
Décidez si le contenu doit provenir des descriptions de schéma, de templates ou des deux.

Ajoutez des descriptions précises destinées aux utilisateurs aux champs de schéma afin que la documentation générée reste alignée avec le comportement.
Conservez une formulation spécifique à l'objectif de l'argument, aux contraintes, aux valeurs par défaut et au comportement calculé.

Créez uniquement des fichiers qui mappent aux objets du fournisseur implémentés.
Utilisez les chemins de template recommandés par HashiCorp :
- docs/index.md.tmpl
- docs/data-sources/<name>.md.tmpl
- docs/resources/<name>.md.tmpl
- docs/ephemeral-resources/<name>.md.tmpl
- docs/list-resources/<name>.md.tmpl
- docs/functions/<name>.md.tmpl
- docs/actions/<name>.md.tmpl (tfplugindocs génère la documentation des actions avec Terraform v1.14.0+)
- docs/guides/<name>.md.tmpl
Gardez les templates axés sur la vue d'ensemble et les exemples ; fiez-vous aux sections générées pour les détails champ par champ.
Conservez les exemples HCL dans le répertoire examples/ — un exemple par fichier, intégré aux templates avec tffile — plutôt que directement dans les templates (voir Example File Conventions dans references/hashicorp-provider-docs.md). Les exemples ne doivent pas contenir de blocs terraform, provider ou output.
Pour les pages d'action, suivez la structure dans references/hashicorp-provider-docs.md (section Action Pages) : les exemples doivent montrer à la fois le bloc action et le câblage du cycle de vie action_trigger, et les actions n'ont pas de section d'attribut/sortie.

Préférez les valeurs par défaut du repository quand elles sont configurées :
```
go generate ./...
```

Sinon, exécutez le générateur directement :

go run github.com/hashicorp/terraform-plugin-docs/cmd/tfplugindocs generate --provider-name <provider_name>

Vérifiez que les fichiers dans docs/ correspondent à l'implémentation actuelle du fournisseur.
Vérifiez que les exemples sont du HCL valide et reflètent les noms d'argument/attribut actuels.
Vérifiez que la sémantique requis/optionnel/calculé dans la documentation correspond au comportement du schéma.

Utilisez des tags de version sémantique préfixés par v (par exemple v1.2.3).
Créez des tags de publication à partir de la branche par défaut.
Conservez terraform-registry-manifest.json à la racine du repository.
Attendez-vous à ce que la documentation soit versionnée dans le Registry et basculable avec le sélecteur de version.

Utilisez le processus de prévisualisation HashiCorp pour inspecter la documentation rendue avant la publication quand le risque d'inexactitude est élevé.
Si la documentation est manquante dans le Registry, vérifiez le format du tag, la branche source du tag, la présence du fichier manifest et le statut de publication du fournisseur.

Gardez la documentation comportementalement exacte ; ne décrivez jamais d'arguments ou d'attributs non supportés.
Gardez les exemples minimalistes, réalistes et exécutables.
Gardez la terminologie et le nommage cohérents across le fournisseur, les ressources et les sources de données.
Évitez de dupliquer les blocs d'argument/attribut générés dans les templates manuels.
Liez les changements de documentation à la même PR que les changements de schéma/API quand c'est possible.

Consultez references/hashicorp-provider-docs.md pour les règles appuyées par source et les liens officiels.
Chargez uniquement les sections nécessaires pour le changement actuel afin de garder le contexte léger.