Consider digest pinning for more build stability #67
Labels
No Label
automation
bug
community organising
democracy
design
documentation
duplicate
enhancement
finance
funding
help wanted
invalid
publishing
question
security
wontfix
No Milestone
No project
No Assignees
2 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: coop-cloud/organising#67
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
We could be doing something like this in the
compose.yml
files:node:14.15.1@sha256:d938c1761e3afbae9242848ffbb95b9cc1cb0a24d889f8bd955204d347a7266e
where you pin directly to a digest that you expect. This would stop whacky stuff happening later on if upstream decides to cheekily overwrite the tag.Down for this.
Do we know what exactly would happen if we did this, in those situations "if upstream decides to cheekily overwrite the tag"?
Would the deploy just fail (and would we want to / be able to show a more helpful error than Docker?), or will it still grab the old tagged image from Docker Hub?
I think it would just error out with "I can't find that tag with that hash" and then yeah, as you say, I think we'd need to provide some explanation after that. We could of coures have a
--force
logic here to override. This seems a bit tricky to manage to set up, we'd probably have to publish our own test image and then overwrite it? For now, we could just do the pinning and figure out the rest later.