Autogenerate documentation for new releases
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 38/100
Línea de trabajo
Comience revisando .github/workflows/update-install-sh.yml en carvel-release-scripts y el script release-docs.sh en carvel/site/hack. Rastree cómo se detecta una nueva versión y cómo el workflow identifica la herramienta publicada y distingue una nueva versión de una versión de mantenimiento. Se considera terminado cuando un workflow activado por un release crea la versión correcta de la documentación sin el proceso manual actual.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Describe the problem/challenge you have
Right now the process to generate documentation for a new release is done manually following the steps in https://hackmd.io/uVpvITUuR4Cbwzkzb7MEpQ?view#Generate-new-docs-version
This process could be automatically triggered to create a new release when a new version is created.
Describe the solution you'd like
The idea would be similar to what we are doing with the update of the install script in the action https://github.com/vmware-tanzu/carvel-release-scripts/blob/main/.github/workflows/update-install-sh.yml
Anything else you would like to add:
Important things that we should take into account:
- When creating the docs it is important to know if this is a new version on top of the latest release version or a maintenance release since the script https://github.com/vmware-tanzu/carvel/blob/develop/site/hack/release-docs.sh needs that information to correctly produce the documentation
- This new automation needs to know the tool that is being released
Vote on this request
This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.
👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"
We are also happy to receive and review Pull Requests if you want to help work on this issue.
- Lenguaje dominante
- Shell
- Estrellas
- 4
- Forks
- 5
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de carvel-dev/release-scripts
-
bug good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 35/100
carvel-dev/release-scripts#34 · 4 comentarios ·
-
enhancement
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
carvel-dev/release-scripts#31 · 1 reacción ·
-
enhancement good first issue
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
Todos los issues de carvel-dev/release-scripts
Issues similares
-
e2e-failure ready-to-code
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
redhat-developer/rhdh-plugin-export-overlays#4391 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
documentation good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
graygarbage/HermesKey#20 ·
-
check-unsafe: source read errors become successful zero countsPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abiertoreview-bot
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
midagedev/bloomery#151 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
needs-triage
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
mattpocock/skills#1269 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 2 días