Scheduled builds of non-default branches

[mkurz]

Right now it's just not possible to run scheduled builds for non-default branches.
I am not talking about checking out another branch from a workflow defined in the default branch:

      - name: Checkout
        uses: actions/checkout@v3
        with:
          ref: my_branch

Even if you check out the branch, you still run the "current" workflow of the default branch where that checkout step is defined.

There is a discussions going on and I think this comment describes very well why checkout alone won't help.

The problem for us is that we have a workflow defined in a non-default branch that runs on pull_request and push events, which is working fine, however we also want to run the same tests for that branch scheduled, each night as well. This way we can run the same tests + additional, more thorough, tests, which take much longer, each night (by conditionally checking if: github.event_name == 'schedule').

Right now the only, very dirty, workaround is to copy a workflow defintion file from a non-default branch to the default branch and use the workaround to check out non-default branch like shown in the snippet above.

Maintaining two exact same copies of the same workflow is very cumbersome as you can imagine and its very likely they become out of sync at some point.

I can imagine and understand that there are technical limitations of checking every branch in every repo for scheduled workflows, however if you give repo admins a setting page where they can define additional branches, besides the default branch, where GitHub should look for scheduled workflows that should be enough. Instead of a settings page you could also offer a new workflow syntax. E.g. something like .github/workflows/scheduled.yml:

on:
  schedule:
    cron:
      - 14 18 * * *
workflows:
- my_workflow.yml@my_branch

(Just an idea 😉)

Thanks!

[jsoref]

One approach would be to use nektos/act -- have the schedule check out the branch and then tell it which workflow(s) to run.

Alternatively, it's possible that you can do what you want with a reusable workflow:
https://docs.github.com/en/actions/using-workflows/reusing-workflows#creating-a-reusable-workflow

[jsoref]

I'd like a pony 🐴 . (I'll settle for a unicorn 🦄 I can ride w/o having to shelter 🐴 🏚️ .)

I also would hate for a repository to suddenly trigger scheduled tasks on a thousand branches when I fork it. I also don't look forward to scheduled tasks that error ❌ because when I fork them I delete their non default branches.

Please do me a favor and set your scheduled workflow to not run (unless some secret is set) that way on average forks won't trip on it.

[mkurz]

@jsoref Look here please: #16109

[mkurz]

I also don't look forward to even trigger the main branch's scheduled workflow for forks.

[mkurz]

Even better @jsoref: #12180

[GordonSmith]

Using a reusable workflow is not possible for us because the workflow in the non-default branch itself already calls multiple reusable workflows. And "Reusable workflows can't call other reusable workflows.": https://docs.github.com/en/actions/using-workflows/reusing-workflows#limitations

FYI These limitations have been improved to "4 levels of reusable workflows"

[skorobogatydmitry]

Same issue, a bit different use-case.
Environment protection rules doesn't allow to start jobs from the default branch. So, despite that I specify branch explicitly in the scheduled workflow, GH doesn't allow it to execute. Same happens with the reusable workflow, as the called inherits branch from the caller.

[Pr0methean]

I need this feature too: I'm trying to compare two GCs for a JVM program, Pr0methean/OcHd-KotlinBuild@db17068 (Shenandoah) and Pr0methean/OcHd-KotlinBuild@65871e5 (ZGC), and launching them at different times of day or days of the week could easily bias the results. The only alternative solution I can come up with involves willingly regressing mainline for several days while I learn which commit executes its CI/CD faster.

[jbrsb]

[mkurz]

Sorry, no solution so far. We just don't run scheduled jobs for non default branches now...

[haroldo-bonette]

also struggling to move a very simple pipeline from Jenkins to GHA...
we need to trigger on schedule jobs on predefined branches, we can achieve that with a reusable workflow and defining the ref on checkout, but if you define environments and env protection it wont work as the Default branch will propagate to the reusable workflow:
it would really be great if we could define branches on schedule trigger:

something like:

on:
  schedule:
    - cron: '*/5 * * * *'
      branches:
        - Dev
        - Int

[thetredev]

Same here. I have a separate branch for creating a container image which I would like to run on a schedule. The default branch then uses that container image to do other things. This syntax would solve all my issues!

[mkurz]

I also like this syntax, but I would let the user even define which yml file in which branch to use. Because the given example only defines the branches, but how to define which yml file from the branch to actually use? Most likely the one with the same file name, however with following syntax that is even better and more flexible IMHO:

on:
  schedule:
    - cron: '*/5 * * * *'
      workflows:
        - my_workflow.yml@some_branch
        - my_other_workflow.yml@some_other_branch

[thetredev]

GitHub is currently asking for feedback on Actions (just click on the Actions tab on any of your projects). I just gave them feedback about this topic. Hope it has an effect.

[VitaliMorgun]

Is there any solution so far to define branches on schedule trigger as we do it on push trigger for example?

[jsoref]

Write a workflow on the default branch with a schedule, and have it use workflow_call to call your workflow on the other branch

[mikeedwards-rs]

Just adding a +1 for this feature. Surprised it isn't already there.

[EwoutH]

Yes this would be very useful, especially if you have maintenance branches.

[luis-m-gonzalez]

I need this too

[snowdream]

I need this too

[bencat-sixense]

Same same :)

[rbankole]

plus 1 for this feature