CI/CD: deploys run a pinned image promoted to :staging / :canary / :production (template #164)
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 45/100
- Tipo de issue
- Documentación
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- docker, github-actions, helm, kubernetes
- Área
- ci-cd, devops, documentation
Línea de trabajo
The payload names no doc file except production.yml, the workflow it says builds nothing. Find the CI/CD docs that describe image tags, build pushes and deploys, then compare them with the behaviour listed in the issue. Done when the docs state the build tag and digest, the track tags, the IfNotPresent pull policy, the rollback paths and the packages: write requirement, and no page still says pods run :main with Always.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
From components-web-app e5b2a29 (#164). Where the CI/CD docs describe images and tags:
- Builds push only the branch tag (
php:main,app:main) and record the pushed digest. - A deploy copies that exact build to its track's tag (
:staging,:canary,:production) through the registry API, and runs<tag>@<digest>withimagePullPolicy: IfNotPresent. Review apps stay on their branch tag, pinned by digest. - Why: pods used to run
:mainwithAlways. A restart, eviction or scale-up, or the nightly orphan scan (which migrates on start), could then run an undeployed build against the live database. - Rollback: re-run an older pipeline's deploy job, or use
helm rollback. Both restore the exact digest. - GitHub: the deploy jobs need
packages: write.production.ymlbuilds nothing, so it pins:main's digest at deploy time. - The registry keeps a fixed set of tags (
main,staging,canary,production, plus review branches). There are no tags per commit.
- Lenguaje dominante
- Vue
- Estrellas
- 0
- Forks
- 0
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
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 components-web-app/docs
-
documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
components-web-app/docs#234 ·
-
Document opening the add page data form with defaults (?parentPage, ?parentPageData, ?template)Abiertodocumentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
components-web-app/docs#230 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
components-web-app/docs#228 · 1 comentario ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
components-web-app/docs#227 ·
-
Dificultad 3/5 Medio día Aptitud para principiantes 55/100
components-web-app/docs#233 ·
Todos los issues de components-web-app/docs
Issues similares
-
release
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
complexity::1-low effort::1-hours priority::1-must
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
jumpingrivers/audit.workbench#37 ·
Los mantenedores suelen responder en 1 día
-
bug needs:triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
upbound/official-providers-ci#276 ·
-
accessibility
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
CivicTechTO/civictech.ca#192 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día