Input Variable Separation in the READMEs

Abierto
  • ¿Algo no está bien?
#32 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
terraform
Área
documentation

Línea de trabajo

Comienza con las secciones Inputs generadas en los README de los módulos y con la plantilla a la que hace referencia el issue; después, inspecciona las herramientas relacionadas de build-harness. Identifica cómo se describen actualmente variables como context, additional_tag_map e id_length_limit y cómo podrían separarse los Inputs específicos de cada módulo, como s3_bucket_name. Se considera terminado cuando los README generados presentan estos grupos en tablas distintas y fáciles de encontrar.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Describe the Feature

First of all, apologies if this is not the correct repository in which to file this issue.

It'd be really nice if, in the READMEs of module repositories based on this template, the input variables that were actually from the module itself were documented in a separate table from the input variables related to Cloudposse's generalized system for generating resource names (e.g. involving terraform-label-null). Wading through a sea of generally-irrelevant properties like context, additional_tag_map, id_length_limit, label_key_case, etc., to find the properties you actually care about (which will vary by module but include things like s3_bucket_name on the aws-transfer-sftp module) is pretty frustrating.

Expected Behavior

It should be easy to find the properties you actually care about when configuring your infrastructure.

Use Case

I want to use Cloudposse's high-quality Terraform modules.

Describe Ideal Solution

A clean, easy to read table of input variables for each module that only shows the variables that actually impact the properties of the resources that the module provisions, with a separate table to document the input variables used to fine-tune minutiae of auto-generated resource names. Ideally, the template provided by this repository (and the associated build tooling in other repositories like build-harness) could have a straight-up list of properties to sequester in their own table. Alternatively, these properties could be flagged using some marker text in their descriptions, which the tooling could act on.

Alternatives Considered

I often just write my own ad-hoc modules rather than using Cloudposse modules. Which is stupid, they're useful, high-quality modules. But they're just so unpleasant to acquaint yourself with.

Additional Context

Below is a screenshot from the "Inputs" section of the readme from the cloudposse/terraform-aws-transfer-sftp repository. I've marked in green those inputs that concern actual, functional details of the infrastructure being provisioned, marked in red those inputs that concern Cloudposse's general scheme for constructing resource names and tags, and marked in blue those inputs that don't cleanly fall into either other group (e.g. the enabled input).
image

Lenguaje dominante
HCL
Estrellas
172
Forks
73
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de cloudposse/terraform-example-module

Todos los issues de cloudposse/terraform-example-module

Issues similares

Más issues de Documentation

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.