You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Operator tests were moved from Jenkins to GitHub action, but the change was done "as it is" (or almost), meaning that we kept the bad things of the Jenkins set-up, and ended up introducing the not optimal things from GitHub actions.
We don't need o build the operator / payloads on every execution of the matrix, as we could easily build it once, store it on ghcr.io, and even help folks debugging things locally to grab that image to use.
Also, we should NOT stop all the executions in case there's one failure, mainly considering the amount of debug information we're providing the users. When the cancellation happens, users are not even aware whether this is a legitimate failure or whether we're in flakiness-land.
The text was updated successfully, but these errors were encountered:
Is it safe to bulldoze the pushes to quay that are happening on merge (so I can push to ghcr), or are those used in many places throughout the project already?
As discussed on slack, the extra information to note is that the operator image on quay are for things that have already been merged, so are 'stable'. The enhancement suggested here is that when running things that are 'in flight' e.g. PRs, we cache the images in ghcr (or we could pull them from quay if they haven't been updated), but these are the same, or for the same purpose as the quay.io operator images
The Operator tests were moved from Jenkins to GitHub action, but the change was done "as it is" (or almost), meaning that we kept the bad things of the Jenkins set-up, and ended up introducing the not optimal things from GitHub actions.
We don't need o build the operator / payloads on every execution of the matrix, as we could easily build it once, store it on ghcr.io, and even help folks debugging things locally to grab that image to use.
Also, we should NOT stop all the executions in case there's one failure, mainly considering the amount of debug information we're providing the users. When the cancellation happens, users are not even aware whether this is a legitimate failure or whether we're in flakiness-land.
The text was updated successfully, but these errors were encountered: