Non-merged merge requests push container images on the upstream projects container registry
So in two scenarios I've seen container images being rebuilt and included in the 'upstream repo' container registry before the merge request was merged.
It happens when the detached merge request pipeline was running on the upstream project, even though the merge request was opened from a fork.
It happens when a merge request is run for a branch on the upstream repo itself. This is still a very common way of handling branches in GNOME.
This is quite annoying, for three reasons; one is that if there are two merge requests that happen to have the same tag, only one will actually build the image, the otherone will just see that it (the wrong one) already exist and bail.
Another annoyance is that one has to temporarly do
FDO_FORCE_REBUILD=1 if there was any changes, then wait for the build to continue, then push another update without the force-rebuild env var set.
The third annoyance is that the upstream container registry will contain "wip"-container images.
How could we solve this?
One idea would be to contain some semi random token in the container images when they are built, e.g. the hash of
HEAD of the merge request branch. This way, when merging, the pipeline could use the hash and do a simple "copy" when finally merging, instead of rebuilding once again.
Any other ideas?