Release-tagged container images are overwritten on each push to main
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 39/100
Direzione di ricerca
Esamina .github/workflows/docker-publish.yml e prepline_general/api/version.py, iniziando dal passaggio del workflow che assegna il tag alla versione e da come i push su main differiscono dalle release. Scegli e implementa un approccio che impedisca ai push su main di sovrascrivere le immagini con tag di release, preservando al contempo il tag di versione previsto per le release pubblicate.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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
- Lingua principale
- Python
- Stelle
- 955
- Fork
- 192
- Merge medio
- 22h 3m
- PR unite (30g)
- 6
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di Unstructured-IO/unstructured-api
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
-
Dependency DashboardAperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 15/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 25/100
Tutte le issue di Unstructured-IO/unstructured-api
Issue simili
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
GoogleCloudPlatform/gce-rescue#195 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 83/100
I maintainer di solito rispondono entro 1 giorno
-
intake mcp-intake needs-ac needs-human-review priority:medium
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
Ikalus1988/MisakaNet#3848 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 75/100
521xueweihan/HelloGitHub#4105 ·
-
bug size:XS
Difficoltà 2/5 1-3 ore Idoneità per principianti 83/100
I maintainer di solito rispondono entro 1 giorno