This message was deleted.

Currently our process is: • PR created • PR pipeline triggers ◦ 'lock' is applied ◦ full apply of

branch

to a pre-existing cluster, based on

master

, basically testing the upgrade pathway ◦ verification of cluster state / tests etc ◦ PR reset pipeline is triggered • At this point, PR validation is successful or not on basis of this pipeline result • PR reset pipeline ◦ full apply of

master

▪︎ if this fails, delete PR cluster and re-apply master ◦ 'lock' is removed • Next PR can roll through The problem with this is that we have only defined one cluster to use for PRs, which means we can only validate one change at a time, which can be a bottleneck. Previously we spun up clusters on demand per PR, which had advantages, but a big disadvantage in the fact that applying infra, eg creating a cluster is a time-expensive operation, and resulted in slower PR feedback

If you're using kubernetes, permit me to ask if you're using GitOps?

No, not GitOps at the moment

I'm interested in this topic as well