Run GHA's Full Integration Pipeline on schedule

[beni0888]

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

Description of the change

Run the GitHub Action's Full Integration Pipeline on schedule. We usually run this pipeline manually only when we are going to release a new version of Kubeapps, and from time to time it turns out that it fails.

Benefits

With this change, we get a much shorter feedback loop, so we can act on the errors more proactively.

Possible drawbacks

An increase in cloud costs due to the fact of running the tests more frequently. Is that a problem?

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	de6bcd7
🔍 Latest deploy log	https://app.netlify.com/sites/kubeapps-dev/deploys/636b44b49efcb400083f1d32

[antgamdia]

Do you know which TZ GH actions are running on?

I assume this is just for testing on GKE, the step for building nightly ARM images is still pending, no?

Perhaps not now, and don't know if it is possible: what about comparing the commit with which the CI was run the last time against the current commit we wanna test; if they are the same, skip it. Otherwise, run the action.
With this, we could run the workflow every night while assuming we won't be testing the same twice.

[beni0888]

Do you know which TZ GH actions are running on?

@antgamdia I'm sorry but I'm afraid I don't understand your comment 😓 What TZ GHA means?

I assume this is just for testing on GKE, the step for building nightly ARM images is still pending, no?

Yeah, they're different things. This is for running the full integration (former prerelease) on schedule, so we get a shorter feedback loop of the integration state of the project, instead of just running this flow on demand before the release.

Perhaps not now, and don't know if it is possible: what about comparing the commit with which the CI was run the last time against the current commit we wanna test; if they are the same, skip it. Otherwise, run the action. With this, we could run the workflow every night while assuming we won't be testing the same twice.

mmm, I'm not sure if that's even possible... In case it was, I think it would increase the complexity of the pipeline just to avoid testing more than once on the same commit, for a workflow that is run three times per week. Do you think it would be worth it?

[antgamdia]

I'm sorry but I'm afraid I don't understand your comment 😓 What TZ GHA means?

Sorry, I should have been more clear. I just wanted to know in which timezone (TZ) the GitHub Actions (GHA) run. I was slightly concern about it as we have teammates around the globe, so in case of reaching a sort of concurrency limit (not sure if it applies also to GHA), we would be hindering the work of our colleagues if the TZ is not taken into account.

Yeah, they're different things. This is for running the full integration (former prerelease) on schedule, so we get a shorter feedback loop of the integration state of the project, instead of just running this flow on demand before the release.

Great, thanks for clarifying!

mmm, I'm not sure if that's even possible... In case it was, I think it would increase the complexity of the pipeline just to avoid testing more than once on the same commit, for a workflow that is run three times per week. Do you think it would be worth it?

Not sure, perhaps it is not worth it as you pointed out. At the end of the day, is not that critical (we don't need to be testing it continuously), so I'm more than ok with the current approach.

[beni0888]

Sorry, I should have been more clear. I just wanted to know in which timezone (TZ) the GitHub Actions (GHA) run. I was slightly concern about it as we have teammates around the globe, so in case of reaching a sort of concurrency limit (not sure if it applies also to GHA), we would be hindering the work of our colleagues if the TZ is not taken into account.

I'm not 100% sure, but I would say that GHA uses UTC time. Besides that, there wouldn't be any problem in running the pipeline at any time as there's no such concurrency limit. The only concurrency limitation as of today is that a new run of the workflow would cancel the one currently running, but only a new run of the very same workflow. I mean, running a workflow for a PR or a push to main wouldn't cancel the run of the Full Integration workflow and vice-versa.

[beni0888]

It seems that CI / local_e2e_tests job from CircleCI has failed to report its status, even though it's passed (https://app.circleci.com/pipelines/github/vmware-tanzu/kubeapps/9548/workflows/e597909b-9a4d-4db2-8499-c0450a86fe56), so I'm going to proceed with the merge bypassing branch protections.