Workflow files only picked up from master?

I’m having the same issues. Were you able to resolve this and get it working?

Hello, it’s more than a Year after you estimated this work to 2-3 weeks. Can we please get a more accurate estimation when it will be possible to test GitHub Actions before merging to master?

10 Likes

1 Add a new workflow file on the master, but specifying to run only on the desired banch.
2 Change to the branch you want with “git checkout specificbranch”.
3 run “git checkout master .github” -> “git add .” -> "git commit -m “merge actions” " -> “git push”

This will merge only in github actions folder and it will make everything work correctly, your new branch will now hear the changes (creating the github actions folder manually will not work)

Hi, are there any update on this topic?

This is a big problem for production repositories. In my case I cannot to push directly to master neither merge non tested PR.

3 Likes

This is super upsetting right now. Even accessing the workflow from the commit, I can see that it is using the workflow from the master branch instead of the updated workflow.

I would have thought this would be a MVP requirement, considering every other CI tool out there allows branch-based CI instructions.

How is this not the top priority for gh actions?

Update 24/08/2020

Fixed for me.

According to the official GitHub Actions documentation (About workflow events):

The following steps occur to trigger a workflow run:

  1. An event occurs on your repository, and the resulting event webhook has an associated commit SHA and Git ref.

  2. The .github/workflows directory in your repository is searched for workflow files at the associated commit SHA or Git ref. The workflow files must be present in that commit SHA or Git ref to be considered.


    For example, if the event occurred on a particular repository branch, then the workflow files must be present in the repository on that branch.

  3. The workflow files for that commit SHA and Git ref are inspected, and a new workflow run is triggered for any workflows that have on: values that match the triggering event.


    The workflow runs on your repository’s code at the same commit SHA and Git ref that triggered the event. When a workflow runs, GitHub sets the GITHUB_SHA (commit SHA) and GITHUB_REF (Git ref) environment variables in the runner environment. For more information, see “Using environment variables.”

Because of this, in order to test the workflows we need to perform a git action (ie. do push) in the created branch for test its.

7 Likes

Maybe my last update post can help you: Workflow files only picked up from master?

Workflows files are picked up at the associated commit and Git ref (ie. refs/heads/master). So, if your commit is present in more than one branch, Git ref will define in which branch searching workflow files.

2 Likes

Was this a recent change? I was testing this when I made my previous comment, and it would use workflow files from master branch even though they were changed on the branch containing the triggering event.

1 Like

I really do not know. Right now it is working for me as defined by the documentation.

Not working for me either :thinking::thinking:

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.

1 Like

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:

5 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”
1 Like

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.

1 Like

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.