Release-tagged container images are overwritten on each push to main
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 39/100
Línea de trabajo
Revisa .github/workflows/docker-publish.yml y prepline_general/api/version.py, empezando por el paso del workflow que etiqueta la versión y por cómo difieren los pushes a main de los releases. Elige e implementa un enfoque que evite que los pushes a main sobrescriban las imágenes etiquetadas con releases, conservando al mismo tiempo la etiqueta de versión prevista para los releases publicados.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
The Build And Push Dock Image action, which runs on each push to main, tags the images pushed with the latest release version.
For example, the commit fa55c3af0d4f38d371934d4a8b9d4b02bf068d17 (which was pushed after v0.1.1 was published) built and published a new container image tagged as 0.1.1, overriding the image originally published for the v0.1.1 release.
This can cause problems for people relying simply on the tag of the container image.
For people pinning the image digest this only causes some minor annoyances, e.g. because tools like renovate will try to upgrade the pinned digest even though the image tag hasn't changed.
A possible fix could be using a pseudo-version in the version file on main, and only setting the "real" version for the commit a release is published on.
Alternatively, the GitHub action responsible for publishing the image could only set the version tag when the action is run for a release.
Possible options for this include using an on-release event trigger, or manually running the workflow and adding a user input to control tagging of the final image
- Lenguaje dominante
- Python
- Estrellas
- 953
- Forks
- 192
- Merge medio
- 1 d 1 h
- PR fusionados (30 d)
- 5
Preparar el entorno
- Incluye un Dockerfile o un 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 Unstructured-IO/unstructured-api
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
-
Dependency DashboardAbierto
Dificultad 3/5 1-2 días Aptitud para principiantes 15/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 25/100
Todos los issues de Unstructured-IO/unstructured-api
Issues similares
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
ansys/pyansys-common-mcp#213 ·
Los mantenedores suelen responder en 3 días
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
freedomofpress/dangerzone#1594 ·
Los mantenedores suelen responder en 3 días
-
priority:P1 status:in-review type:bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
randomparity/kdive#3317 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
area:ci
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
mesonbuild/meson#16281 ·
Los mantenedores suelen responder en 1 día