Add missing dependencies for CI steps

[antgamdia]

Description of the change

After sketching up some diagrams, I noticed our CI has some steps wich aren't defined in the requires section.

Example:

Benefits

Not a real benefit, actually, but the dependencies that semantically makes sense are now defined as part of the CI config.

Possible drawbacks

N/A

Applicable issues

N/A

Additional information

It seems to me that we have to do something with the GKE_1_XX_zzzzzz steps. The tests there were also flaky during the past release.

I'm thinking about having a named commit that makes CirlceCI trigger this workflow, something like "prerelease" or "prepare release". This way, we can safely execute the GKE test... without tagging a commit (an action that automatically triggers the bitnami pipeline)

[absoludity]

I'm thinking about having a named commit that makes CirlceCI trigger this workflow, something like "prerelease" or "prepare release". This way, we can safely execute the GKE test... without tagging a commit (an action that automatically triggers the bitnami pipeline)

If you mean that tagging a commit triggers the bitnami pipeline regardless of whether the tagged commit has passed CI, then yes, that needs to change. We should only be triggering the bitnami pipeline once the tagged commit's CI pipeline (including the GKE tests has succeeded).

Just building on your suggestion above, if the prerelease workflow (that we would trigger manually, just like we currently manually tag the commit) tagged the commit on success, that would then have the same level of automation (one manual interaction on our part)?

[antgamdia]

If you mean that tagging a commit triggers the bitnami pipeline regardless of whether the tagged commit has passed CI, then yes, that needs to change. We should only be triggering the bitnami pipeline once the tagged commit's CI pipeline (including the GKE tests has succeeded).

Yep, and it is something we can't control. The bitnami pipeline is monitoring published tags, not github releases

Just building on your suggestion above, if the prerelease workflow (that we would trigger manually, just like we currently manually tag the commit) tagged the commit on success, that would then have the same level of automation (one manual interaction on our part)?

Yes, that's the idea. However, it seems CircleCI does not filter using commit msgs (https://circleci.com/docs/2.0/configuration-reference/#filters), but instead just branch names.
Some ideas:

• A) create a prerelease commit, push it to the prerelases upstream branch; it will trigger the prerelease workflow in circleCi. Later on, if successful, tag this commit.
• B) Use a bash approach to get the commit mgs manually and decide, programmatically, whether each job should/n't be executed. If successful, create a new commit and tag it.

However, this discussion is interesting enough to be split apart into a separate issue. Doing right away. #3381