GitHub Actions nightly build triggered on forks

[rgommers]

It turns out nightly builds have been running on my fork for 5 months, so since commit eb37171 probably. I only recently started noticing, because I happened to have the most recent commit on master being one that was failing. I suspect nightly builds are running on all forks.

I'm not yet very familiar with GitHub Actions, but it looks like we're missing something important here. Any ideas @andyfaff, @tylerjereddy?

[tylerjereddy]

Hmm, I do see these kinds of notifications sometimes for my fork too I think. I always get confused because we were using the "nightly build of Python 3.9 for CI" but GitHub actions also allows tests to run "nightly," which is two different uses of "nightly" of course.

[rlucas7]

I was seeing those notifications on my fork as well, when I asked about it on scipy-dev Andy suggested:
https://github.community/t/stop-github-actions-running-on-a-fork/17965/2
which I setup on my fork and I haven't seen the nightly builds on my fork email since.
Admittedly the emails are infrequent but that was almost 2 months ago.

[andyfaff]

I suspect nightly builds are running on all forks.

At the moment the Github Actions run on all public forks of public repos. I think GH is going to change that in the near future so that doesn't happen. However, it's a cool thing as it allows you to try out changes on your own fork before making an official PR. This kind of thing is also possible with travisCI, where the scipy defined CI matrix also runs on my fork. In that case the individual user has to opt in.

I always get confused because we were using the "nightly build of Python 3.9 for CI" but GitHub actions also allows tests to run "nightly," which is two different uses of "nightly" of course.

GH Actions does have the ability to run in a cron fashion. Our use of nightly is confusing, Tyler is correct in his explanation. In our context we're testing against the nightly builds of Python, rather than running a CI test nightly. The CI run using GH Actions is triggered on a particular scipy fork when a commit is made to it. There are in fact two CI scripts on GH Actions, one that tests Nightly builds of Python (bleedingedge.yml) and one that tests on macOS 3.6/3.7/3.8 (testing.yml). The top of those scripts configure which events trigger the scripts, e.g. push to master, pull request, etc.
CI runs are not happening on all scipy forks every night, but only when forked repos have changes made to them.

As Lucas points out it's possible to disable the CI run on your own fork. I'm not sure if it's possible to do that globally, but I like using that CI run to try out experimental changes before making a PR. I don't know if it's possible to disable email notifications.

[andyfaff]

Sorry, I didn't remember correctly, what I said was totally incorrect. The "nightly build" runs every night against the nightly build of python 3.9,

scipy/.github/workflows/bleedingedge.yml

Line 10 in 02563b2

- cron: '0 0 * * *'

.
How did we want to change this? It was designed to work as a canary in the mine against 3.9 breakage. I'll have a think about options.
(Inadvertent close coz on phone. I won't be able to make changes before the weekend)

[rgommers]

It seems like we are missing this conditional in the workflows:

if: github.repository == ‘scipy/scipy’

The default should be to not run anything on forks, that is super wasteful for no good reason.

[andyfaff]

is super wasteful for no good reason

Agree. Perhaps the schedule line isn't needed at all.