Skip to content

Adding deploy-bundle-dev

Alberto Pimpo requested to merge bundle-dev into master

While working at the Grafana update to v10, I noticed that the workflow we suggest in the Grafana README (but also in all the other helm operators) is the following:

  • upgrade the version as per instructions
  • push the upgrade to < operator-name >-catalog:staging (which automatically deploys on app-cat-stg)
  • test if this works (manually and with CI)
  • deploy to production

I think that this workflow is very different from our standard procedure because we deploy untested changes on staging!

I propose to start to follow this procedure instead:

  • upgrade the version as per instructions
  • push the upgrade to < operator-name >-catalog:< name-of-the-branch >
  • create a MR on okd4-install and changing the default tag to < name-of-the-branch > (like https://gitlab.cern.ch/paas-tools/okd4-install/-/merge_requests/1534/diffs)
  • run tests on CI and check if they're green
  • If the tests are green and the upgrade is ready, deploy staging first, and immediately after validating staging, deploy production

To implement this flow, we need to create the new job in this repo (which is imported by all the operators repo) and then the job implementation in each repo (this is how it looks like in grafana https://gitlab.cern.ch/db/grafana-operator/-/merge_requests/59/diffs#587d266bb27a4dc3022bbed44dfa19849df3044c_73_76).

I guess this was never implemented to keep the operator's repos maintainable from third parties (is this the case @alossent ?). If this is the case, do we really want that third parties push "untested" (at least, not tested with a CI) changes on our stg cluster? Creating a MR and running CI requires low permissions (Developer permissions should be enough), so it's something that we can grant to mantainers of our operators.

Edited by Alberto Pimpo

Merge request reports