Scheduled builds of non-default branch

Is there a way to run scheduled builds for a non-default branch (i.e. not the master branch)?

6 Likes

Hi @phil-opp,

Thanks for being here! GitHub action Workflows don’t need to be in the default branch in order to run. For a list of available events, see “Events that trigger workflows.”

@andreagriffiths11 The workflow doesn’t have to the on the default branch but it will always run on the default branch. I interpret the question as how do you run it on a non default branch (i.e if I have the workflow on the branch release/2.3 how do I make it run on that branch?

4 Likes

I’m not entirely clear on what it is that you’re trying to accomplish - could you explain a bit more?  I ask because there’s no real tie to a workflow and source code - although a workflow can check out source code, there’s no requirement or strict tie between a branch and a workflow.

So if you’re trying to manipulate some code in another branch on a schedule, you can check a workflow into the default branch, and then have it check out the branch that you want to manipulate.  For example:

on:
  schedule:
  - cron: 14 18 * * *

jobs:
  hi:
    name: Hi
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
      with:
        ref: other
    - run: echo I've checked out the `other` branch

If you can clarify what you’re trying to accomplish, that would be helpful for us to find a solution.

What I want to accomplish is to have nighly builds of multiple branches. Setting up a simple schedule would only run the workflow on the default branch. I can, as you say, specify which branch to check out but it’s very cumbersome if each branch has to change what is built. It would also lead to merge conflicts every time a branch is merged back into master.

Consider two branches with completely unrelated history. For example, a master branch that contain the code and a website branch that contains the project website. Since the branches have completely different content, they also have different workflows. For example, the workflow for the master branch could compile and test the project, while the workflow for the website branch could download a static site generator and build the website.

Let’s say we want to update the website daily, for example for updating the listed the star/fork count of the GitHub repository. Or for showing a list of pull requests that were merged on the day before. To do that, we want to schedule the corresponding workflow daily. However, a schedule key in the website branch has no effect currently.

While checking out the website branch from the master workflow is possible, it would require copying the website workflow into the master workflow. Now we have to keep the two copies of the workflow in sync, which means that we have to update the master branch regularly, e.g. when we update the used version of the static site generator.

One solution to this problem could be to define additional “top-level branches”, which are never intented to be merged into master. For these branches, schedules could work like they do for the master branch. Alternatively, there could be a simple way to trigger a branch build from the master branch. Then we could define the schedule in the master branch and trigger a build of the website branch (without copying the workflow).

@ethomsonFriendly ping, just to make sure that you saw my reply :slight_smile:

@andreagriffiths11 You are correct in general. But on.schedule seems to be effective only in workflows in default branch. If I put it into a workflow in a non-default branch, it does not trigger. If I have on.push ... in a workflow in a non-default branch, it works as expected.

So as of Dec 20, my conclusion is that on.schedue is interpreted only in default branch workflows. This is not explicitely documented anywhere. And this seems to be @phil-opp’s experience as well.

1 Like

It would be very nice to be able to write something like this so you can have multiple schedules that run on any branch:

on:
schedule:
    cron:
- 14 18 * * *
branches:
- master
- dev1
- dev2
3 Likes

Yeah, this is a royal PITA not being able to specify what branch you want checked out during on.schedule.  I’m honestly quite shocked there’s no ability to do this.  My team has multiple working branches at any time.  Am I really supposed to add another branch just to house where I want my github action to live, hence, pull from?

the same requirement

Yes, we have a project with multiple supported branches as well and need to run the cron every day on all of these.

Building of what was previously said, would the following work?

on:
  schedule:
  - cron: 14 18 * * *

jobs:
  hi:
    name: Hi
    runs-on: ubuntu-latest
strategy:
matrix:
branch:
- master
- dev1
- dev2
    steps:
    - uses: actions/checkout@v2
      with:
        ref: ${{ matrix.branc }}
    - run: echo I've checked out the `${{ matrix.branch }}` branch

@robkooper wrote:

Building of what was previously said, would the following work?

 

on:
schedule:

  • cron: 14 18 * * *

jobs:
hi:
name: Hi
runs-on: ubuntu-latest
strategy:
matrix:
branch:

  • master
  • dev1
  • dev2
    steps:
  • uses: actions/checkout@v2
    with:
    ref: ${{ matrix.branc }}
  • run: echo I’ve checked out the ${{ matrix.branch }} branch

 

@robkooper That looks like it should work. Watch out for the misspelling in your actions/checkout ref, and your list of branches needs to be an array according to the docs.

While this is able to checkout non-master branches, it still uses the workflow definition from the master branch. So this approach only really works if the master, dev1, and dev2 have the same build and test instructions. If they don’t, this approach requires duplicating the workflow instructions of the branches into the schedule workflow on the master branch.

For example, consider a docs branch that uses a markdown parser and a static site generator to build the documentation of the project. The master branch contains the source code of the project. With your approach, we would need to copy the build instructions for the docs into the scheduled workflow file of the master branch. This now creates the problem that we need to synchronize the contents between the docs and master branches, otherwise the scheduled workflow might do something different than the workflow on the docs branch.

1 Like

the same requirement

I have two branchs with different build structure and test flow, we hope to schedule time to trigger workflow for both.

Any updates on this by GitHub? Would be a great feature.

1 Like

+1, I’d love to know if this is planned at all. It would allow me to streamline my fork sync action for scheduling on a non-default branch.

Perhaps for now I could recommend setting the sync branch in the workflow like in the comments above, but it would be much cleaner to be able to put the workflow on the branch being synced.

@andreagriffiths11 I think the issue comes when your workflow references context values like ${{ github.sha }} - currently I believe events of type schedule will always reference the latest commit in default branch which is not always what is needed.