Made cron actions to only run on upstream

ariel-anieli commented 2 days ago

Proposed Changes

cron actions keep failing on my local repo
from the GitHub debug, it seems they are missing tokens passed as secrets.

# git grep 'cron:'
.github/workflows/check-build-system-equivalence-release-branches.yaml:  - cron: '0 2 * * *'
.github/workflows/gazelle-scheduled.yaml:  - cron: '0 4 * * *'
.github/workflows/test-windows.yaml:  - cron: '0 2 * * *'

# bazel run gazelle (main)
Input 'token' not supplied. Unable to continue.

# check-v3_13_x / bazel build package-generic-unix.tar.xz
couldn't find remote ref refs/heads/v3.13.x

Types of Changes

What types of changes does your code introduce to this project? Put an x in the boxes that apply

[ ] Bug fix (non-breaking change which fixes issue #NNNN)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause an observable behavior change in existing systems)
[ ] Documentation improvements (corrections, new content, etc)
[ ] Cosmetic change (whitespace, formatting, etc)
[x] Build system and/or CI

Checklist

[x] I have read the CONTRIBUTING.md document
[x] I have signed the CA (see https://cla.pivotal.io/sign/rabbitmq)
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] All tests pass locally with my changes
[ ] If relevant, I have added necessary documentation to https://github.com/rabbitmq/rabbitmq-website
[ ] If relevant, I have added this change to the first version(s) in release-notes that I expect to introduce it

Further Comments

I am looking forward your feedback.

michaelklishin commented 2 days ago

Yes, external contributions and forks won't have access to the infrastructure-related secrets that are necessary to store Bazel cache files.

michaelklishin commented 2 days ago

Thank you. There's nothing wrong with this PR per se but without finding a solution where secrets would be available to external PRs, I don't think this will generally change much for CI status for everything contributed externally to the org.

What to do with Bazel cache in the short term remains to be seen. Longer term we will likely speed up the test suites to the extent possible and go back to Make, not because Bazel does not do its job well — it absolutely does — but because of certain infrastructure changes our team is forced to adopt by year's end.

ariel-anieli commented 1 day ago

From your answer I understood:

CI/CD changes are to be done on the org infrastructure, by year's end.
These changes would make secrets available to the outside world.

:slightly_smiling_face: I am looking forward these changes; it's annoying to receive mail notifications about failing tests.

lukebakken commented 1 day ago

@ariel-anieli you should maintain your own branch, based on main, in which you have made these modifications. Or, modify your fork to run a different workflow file.

ariel-anieli commented 1 day ago

Thanks for the hints, @lukebakken; much appreciated.

rabbitmq / rabbitmq-server