Restrict scheduled workflow to repository

[mkurz]

When a repository gets forked, scheduled workflows will also run for the fork. This is not desired usually (at least this is my opinion). I guess there are thousands fo forks already which run scheduled workflows, occupying virtual machines and resources for nothing. Also it can get annoying if a scheduled job keeps failing for forks and users that forked such a repo get spammed with notifications that the (scheduled) workflow (of their forked repo) failed.

What can done right now is to check for the repo name to make sure a job is nailed to that repo, like done here:

jobs:
  akka-cluster-metrics-sigar:
    name: Akka Cluster Metrics Test with Sigar
    runs-on: ubuntu-20.04
    if: github.repository == 'akka/akka' # Only run the JOB when called from the akka/akka repo
    steps:
      ...

However this is not a very good solution, since this condition has to be added to each job (besides that, it would be nice to not check for a repo name but if the repo is a fork or not, which is also not possible right now, see here and here).

So here is my suggestion how that should actually work:

on:
  schedule:
    - cron: "0 0 * * *"
    - repository: "akka/akka" # Only run the scheduled workflow if within that repo

or even more generic, checking for forks:

on:
  schedule:
    - cron: "0 0 * * *"
    - forks: false # Do not run on forked repos

(of course that could be named differently, like allow_forks or run_on_forks, etc.)

Or, even more generic 😉

on:
  schedule:
    - cron: "0 0 * * *"
    - if: github.repository == 'akka/akka' 
    # or (like mentioned above)
    - if: !github.event.repository.fork

What's better about these approches is IMHO that we don't have to care for each job to check for the repo (or fork) and just put the condition in one central place. Plus, it would be obvious that the jobs wouldn't even be tried to run, but instead the whole workflow would not even fire.

EDIT:
Somehow related: #12180, however that request is about to give users and orgs the possibilty to disallow (on a settings page) the execution of scheduled jobs. My request however gives the author of a workflow the power to define where a scheduled workflow is allowed to run.

Thanks for listening!

[zeitounator]

Has someone looked at this on github side? This seems like a very reasonable proposition that would probably help to reduce unwanted workflow runs over forks (which would probably save several thousands runs a day). Is there any chance we see this implemented?

Thanks.

[Spacexowboy]

stop

…

On Tue, Oct 25, 2022 at 8:29 AM Olivier Clavel ***@***.***> wrote: Has someone looked at this on github side? This seems like a very reasonable proposition that would probably help to reduce unwanted workflow runs over forks (which would probably save several thousands runs a day). Is there any chance we see this implemented? Thanks. — Reply to this email directly, view it on GitHub <#16109 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWBSWJ3MU4NMW37DQUARQ6TWE7HDHANCNFSM5VGBBMIQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[zeitounator]

@Spacexowboy Pressing the unsubscribe button in the upper left column on the screen on github interface for this discussion might be more efficient.

[noopurintel]

Do we have any solution to this request so far? Instead of skipping one/more jobs with if condition, need to skip the overall workflow.

[grzegorzkrukowski]

We need a solution for that as well.

@mkurz did you find any reasonablr workaround for this?

I am thinking of making my workflow „workflow_dispatch” only on my main repository and then creating a new repository that will just contain a cron job that will trigger the on in main repostory on cron schedule.

[mkurz]

The "workaround" we are using was not set up intentionally; it turns out because we use reusable workflows, we therefore have a central place to make sure a job only runs if it is not within a forked repository:
E.g. our reusable workflow cmd checks if a repo is a fork in each of its jobs: https://github.com/playframework/.github/blob/079e81cac5fa3ee593a805af6674719c4fe0c683/.github/workflows/cmd.yml#L74 (be aware of the location of these reusable workflows which is the .github repo within our org: https://github.com/playframework/.github/)
Now we use those reusable workflows in all our repos, e.g. here, we do not need to care about setting up this check everytime. It's done once in a central place. So if anyone forks our repos, the reusable workflows from our .github repo will still be called, making sure to skip the jobs.

Of course IMHO GitHub should still introduce a config on the workflow level, not just on the job level which we are using currently.

[grzegorzkrukowski]

Great, thanks for the quick answer!

For us, the problem is that even if we cancel the run for a single job - it still generates the notification for our contributors :(
So skipping a workflow is there, but it's not enough for us :(