CI: Run jobs on schedule each night to protect against regressions

[amotl]

About

This creates a stronger signal to be picked up by downstream monitoring components driven by cratedb-github-summary and possibly others.

References

• OCI build on linux/arm64 started failing on Jan 14 with tar: Cannot {mkdir,open}: Invalid argument #255

Actually looking at #255 I'm not sure if adding another CI trigger is the way to go. We already had commits to master that have CI failing.

What we probably should do instead is to update the job that updates the Dockerfile to check the gh status and fail based on it. That way it would also hook into the existing alerting we have for the Dockerfile updates which are part of the releases.

[amotl]

What we probably should do instead is to update the job that updates the Dockerfile to check the gh status and fail based on it. That way it would also hook into the existing alerting we have for the Dockerfile updates which are part of the releases.

That would certainly be better, right! Let me know if you still think this patch is valuable, otherwise please just close it.

[amotl]

@mfussenegger mentioned on this:

Shouldn't this also run on PR and push be restricted to master?

[amotl]

Possibly, yes. Fixed. Thanks!

[amotl]

Actually looking at #255 I'm not sure if adding another CI trigger is the way to go. We already had commits to master that have CI failing.

What we probably should do instead is to update the job that updates the Dockerfile to check the gh status and fail based on it.

I hear you, and I absolutely agree. I still refreshed this patch based on your suggestions, thanks! If you think it is still viable to use daily/nightly runs as an additional protection layer, you may want to review it once more and accept the patch?

Background: We are currently checking many of our nightly CI/GHA jobs across the board with a little reporting tool that converges its outcome into a nice feed located in Slack's #team-cratedb-ecosystem-daily channel, scanning every hour. It is of tremendous help to asynchronously review pieces that went south, additionally to any possible synchronous checks.

[mfussenegger]

Nuked GHA with #258 so this would need updating. But I still think this is mostly not needed. The Dockerfile is changed with commits in a different job that should verify the CI result.

Other than that, dependencies are locked. The Dockerfile is pinning to a specific CrateDB version so there isn't much that can start failing outside of environment changes - for which we don't need N > 1 notifications.