Workflow files only picked up from master?

This is not working for me either. I think the main problem is that GitHub workflow configuration doesn’t distinguish between workflow names and workflow run names and simply uses the value of the name property for both purposes, with very confusing results.

In contrast, Azure pipelines, which are equivalent to workflows, handle the exact same configuration quite well, which is something that GitHub should look into. Here’s a couple of details for comparison.

The workflow name property in GitHub serves as a workflow name and a workflow run name, so when I run the same workflow against branch A, where name is set to A1, all workflow runs, even for different branches, suddenly turn into A1 as soon as the workflow is picked up. If I run the same workflow on a branch B, where name is set to B1, same thing happens - all workflow runs for all branches switch to B1. This tells me that there’s no database entity for workflows and it merely grabs name from the workflow file and renders it in the UI.

Azure pipelines, on the other hand, track pipeline names separately from the source, so if I have a pipeline called myapp or myapp-reviews, they can build any branch without changing pipeline names.

Things differ even more within the workflow/pipeline YAML. In GitHub workflow, expressions are not expanded in workflow names - it’s just a string literal, probably because it serves both purposes - as a workflow name and as a workflow run name. Run numbers are just appended to the workflow name in the UI.

In Azure pipelines, name takes variables, so I can put a branch name there or anything else. Plus, it maintains a prefix counter, which tracks numeric sequences per arbitrary prefix, not per pipeline, which is very important in tracking build numbers.

For example, I can format name in a release branch 1-1-x as name: 1.1.0+$(Rev:r) and in the trunk, where the future version 2.0.0 is being prepared, as name: 2.0.0+$(Rev:r) and builds from the same pipeline will be named as 1.1.0+1, 1.1.0+2, etc, when it builds the 1-0-x branch and as 2.0.0+1, 2.0.0+2, etc on master.

Not only this allows me to use the same workflow against different branches and to list builds according to their branches, versions, etc, but it also allows me to track build numbers sequentially for each branch independently of other branches. GitHub’s workflow run number is per workflow, so when it is used against different branches, they will be skipping build numbers from their sequences.

I hope GitHub will give this another go.

Looks like GitHub has left the building on this one. Luckily for me Azure DevOps handles build numbers well, pulls GitHub repositories and posts back to GitHub releases. It would be nice to use one site for everything for some projects, but I suppose one cannot have it all.

Would be really nice to have this feature. @mscoutermarsh Can you give us an update on that? It seems to be closer to 2-3 years than weeks now :slight_smile:


I would really like to see this feature at least in beta preview. Would be really helpful for forks that don’t want to make master outta sync and keep actions in a separate branch.

I just tested, you need to create the same file on the default branch (just make it noop)

I did it with the workflow_dispatch event.

  • Create a “echo ping” workflow on my default branch
  • On my other branch “foo” I modified it to test what I wanted
  • I created a workflow dispatch with the ref “foo” and I could test my workflow (not the one from the default branch which would have just echoing “ping”