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:

3 Likes

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”

Feels like this is kind of a deal breaker. I think projects that follow the gitflow branching strategy (which I think is many repositories) only commit to main when releasing. So, if a feature/release/develop branch needs to add a workflow, the workflow will not be able to be run at all until the workflow ends up in the main branch, which is too late. Or, the workflow will have to be committed to the main branch, but that goes that go against gitflow strategy (and in some companies, some people don’t have main branch commit permissions).

1 Like

This behavior is just dumb. I just added a workflow file in a feature branch and pushed to GH. The workflow doesn’t appear, doesn’t run. If this is the way it’s supposed to work well then it makes me want to continue with our drone deployment. Who wants to push to the default (or any specific) branch just to develop and test new workflows???

edit: Looks like at the very least you can get this working by opening a PR but… Our workflow tends to be to test on feature branches to provide feedback before a PR is opened. I guess this could work.

I agree with every post above. It would be nice for GitHub to finally address this. I sink far more time into fighting with GitHub Actions than any other task at work. A few simple features would save us all countless hours.

I am not sure if I understand the thread right. But are you guys looking for?

on:
push:
branches: [ <branch_names> ]

This worked for me even without any workflow in master.

It is really messed up.
I did the following: Created a release.yml file in three branches, all with same file name, but different ‘name’ tag inside the yml file. Only the main branch is visible in the actions. But I can run the workflow for all branches.
If I name the files in each branch differently, only the main branch is visible in actions, but I cannot run the workflow for other branches - though I can select the branch to run but then it erros me that the workflow does not exist.

Anyhow, I expect to have different workflows/actions for branches. There is a feature branch which needs to have its own action.
But all this would mean that the whole actions concept would need redesign … as I see it.

Ther is no progress on this issue?

1 Like

after several days of fighting with this, i found this thread. :frowning:

I am having this issue as well, the only way I can see to test workflow_dispatch workflows is to merge them into the default, which is main for me. I’ll add my voice to the chorus screaming into the void.

This is quite problematic as you are not able to test new workflows with manual dispatch till they are merged in the main branch, @mscoutermarsh are there any timelines for this issue fix ?

I am having the same problem. Actions seem to show up ONLY from the trunk branch, and it is quite annoying, because it means I have to commit a million times to main while working out kinks. Update: actually after the first PR merge, it appears you can keep commiting to the feature branch, which can be selected in the UI when you initiate the run.

Hello everyone, having a similar issue over here, just pushed our first workflow to a feature branch which is not the default and cannot see any github actions going on. If there is any link or doc about this I missed please let me know. Thank you all!