Trigger GHA release workflow on tags following test-* pattern

[beni0888]

Signed-off-by: Jesús Benito Calzada bjesus@vmware.com

Description of the change

We need a way of being able to test the new release workflow in GHA. So far, it's only triggered on new tags following the pattern v[0-9]+.[0-9]+.[0-9]+, so we cannot trigger it unless a new release tag is created. To allow testing without generating new release tags, we have added a new condition that triggers the workflow when new tags following the pattern tests-* are created.

Benefits

The release workflow can be triggered and tested without the need of creating new release tags.

Possible drawbacks

If we don't control the kind of tag that triggered the workflow, and deactivate the DEV_MODE for the kubeapps-main workflow, we could generate an actual release on the Bitnami side upon the creation of new test-* tags.

Applicable issues

• related to Migrate CI to Github actions #4436

Additional information

N/A

[netlify]

✅ Deploy Preview for kubeapps-dev canceled.

Built without sensitive environment variables

Name	Link
🔨 Latest commit	31fc8b3
🔍 Latest deploy log	https://app.netlify.com/sites/kubeapps-dev/deploys/636e232ed47f900009065ac2

[antgamdia]

Ok, it seems like a temporary thing we need to be able to test the CI step. +1 as I don't wanna block it when on PTO, but find below some comments and concerns:

• Can't we just trigger the workflow (manually) from the github UI instead?
• Creating a release when we should not seems to be a bit risky if we forget to add the DEV variable. What about using the github.ref variable to set the DEV variable if the tag contains test- or whatever?
• The name test- perhaps is not the most accurate, anyway, it is a temporary thing, so doesn't really matter.
• I'd add a comment # TODO(xxx): yyy saying it is a temporary thing that must be removed soon.

[beni0888]

• Can't we just trigger the workflow (manually) from the github UI instead?

That would be tricky and would imply a lot of changes...

• Creating a release when we should not seems to be a bit risky if we forget to add the DEV variable. What about using the github.ref variable to set the DEV variable if the tag contains test- or whatever?

Let me think about it 🙂

• The name test- perhaps is not the most accurate, anyway, it is a temporary thing, so doesn't really matter.
• I'd add a comment # TODO(xxx): yyy saying it is a temporary thing that must be removed soon.

Yeah, it looks like a good idea

[beni0888]

• Creating a release when we should not seems to be a bit risky if we forget to add the DEV variable. What about using the github.ref variable to set the DEV variable if the tag contains test- or whatever?

I've added the hack for this. Thanks @antgamdia!