Have a new workflow run from a PR (none main branch) before committing into main branch possible?

[heldrida]

Hi,

I’d like to test a workflow in a PR, but from what I understand it only shows and runs if committed to the “main branch”.

Is there a way to have new workflows show and run in the PR stage?

Just to be clear, a new workflow in .github/workflows/some-workflow.yml, when committed in a new PR, it won’t show up in the actions and I’d like to have it and run it before committing to the main branch.

Thank you!

[mickeygousset]

You can trigger off of a pull request event in your workflow file:

https://docs.github.com/en/actions/reference/events-that-trigger-workflows#pull_request

[heldrida]

Thanks for looking!

But I should have worded it differently.

I’m looking to have the workflow peer-reviewed before integrating it into the main branch. This means that the workflow is not yet available or merged with the main branch. Because it is not yet available, displayed, showing in the Github actions, I won’t be able to trigger it: manually, by PR, etc.

I believe that Github does not yet support running workflows that only exist in a none main branch. Am I correct?

Example use-case:

• Create a new branch for a new workflow
• Create a new workflow under .github/foobar.yaml
• Commit the file and changes for foobar.yaml
• Push the branch to Github
• Create a new PR for the branch against the main branch (or the same, in which the workflow should be triggered)
• Finally check actions, where the workflow won’t be available, or shown

cc @mickeygousset

[airtower-luna]

heldrida:

I believe that Github does not yet support running workflows that only exist in a none main branch. Am I correct?

It depends on the event type. There are certain event types for which the workflow file must be on the default branch (e.g. schedule), but events associated with a specific branch (e.g. push or pull_request) should work on other branches.

Check GITHUB_REF for different events in Events that trigger workflows - GitHub Docs. 🙂

[heldrida]

Thanks for the support!

If the PR holding a new workflow hasn’t yet been approved and merged to the “main” branch, is it expected to show in the actions?

Here’s an example, which is not showing (the workflow yaml only exists in the pending PR):

name: Foobar
on:

pull_request:

branches: [ main ]
workflow_dispatch:
jobs:

build:

runs-on: ubuntu-latest
steps:
  ...

My expectation was that at least I could trigger it manually, as you see the workflow_dispatch, or at least have it display in the actions sidebar. But afaik, it’ll only show once I merge into the main branch.

[heldrida]

My apologies, just found that I have the paths, in which the changes at the moment do not full-fill as I’m only working in workflow.

By removing it, the action does show as expected!

[mickeygousset]

for workflow_dispatch, you HAVE to have a version of the file in the main branch.

[igor-dovgaliuk-globallogic]

it is common practice that new functionality added to the project is not immediately merged into master/main and reviewed from there.
In case of workflow_dispatch it would be good to have a note about the limitation in the documentation
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onworkflow_dispatch

[jsoref]

Filing tickets isn't particularly difficult. Filed: github/docs#31007

[tracy-ash]

But workflow_dispatch will only run the workflow version that’s checked into the main branch, right?

[mickeygousset]

Ahhh, see that is where things get interesting. To initially make it show up on the Actions tab, and so that you can trigger it manually, it has to be checked in to the main branch.

BUT, when you trigger it, you can pick which branch to run it against. The only caveat is that the workflow file (or a version of it) also has to exist IN THAT BRANCH.

[rwader-swi]

so I'm having the workflow_dispatch triggering workflow on master, but I've made changes in the action that it is using and it's in the non-merged PR's branch now. So will my updated action run if I select that branch, or will the same action from master branch will be run?

[jsoref]

When you use workflow dispatch, GitHub asks you which branch to run. So it's your choice.

[tracy-ash]

ok, got it. thanks.

but for repository_dispatch, the workflow that runs must be in the default branch, right? if not, how can a workflow in a non-default branch be triggered by a repository_dispatch?

[mickeygousset]

That I don’t know I’d have to test it and see. The docs don’t say. Logically it makes sense that yes it would have to be on the main branch for repository_dispatch to work

[tracy-ash]

As far as I can tell with my limited experience with repository_dispatch, it only runs workflows on the default/main branch when triggered by a push on a non-default branch. Would love to be proven wrong. :slight_smile:

[tracy-ash]

This is what I’d love:

push to dev branch -> trigger and run workflow on dev branch

[blanchardjeremy]

I was struggling with this too. I followed what I picked up from this thread and did the following:

1. Make a new workflow with a very incomplete set of actions. Just a skeleton basically.
2. Add the workflow_dispatch to the config so I can trigger it manually
3. Commit the new workflow to a branch
4. Open a pull request for that new branch
5. Merge it into the default branch (main) (even though it’s not functional)
6. Now you can access the action from the Actions tab on the repo
7. You can run it against a specific branch.

[jsoref]

Fwiw, as long as the repository is public, you can create a public fork and set your public fork’s default branch to the version which has the code you want to demonstrate. (And possibly w/ the same name as the expected destination branch, instead of the name of the feature branch in your fork as used for your PR.)

In your case, removing the branches: [ main ] item of course was sufficient.

In some cases you could just add a second branch, as in:

on:
  pull_request:
    branches:
     - main
     - demo

[pnadolny13]

@jsoref thanks for this! It seems obvious but solved my problem.

I was trying to follow the workflow from https://github.com/orgs/community/discussions/25746#discussioncomment-3249056 but I didn't want to commit my draft to main. Testing on my fork main branch allows me to keep the actual main branch clean until I'm done testing. Its especially helpful in cases where I'm experimenting and am not planning to ever get this workflow into the main branch.

[fharper]

Seems like you either need to have it first in main or create a fork like described by @jsoref.

Still, I would love if GitHub add the option to be able to display the /actions view based on the selected branch in the UI or display actions available in other branches which are not in the main one in the view or at a minimum, let us fire actions from a specific branch (even if it's new or was deleted from the main branch with their CLI).

[jsoref]

Workflows can reference actions at arbitrary commits by full sha, by branch, or by tag.

That isn't a problem.

[vladimirdu]

I’m still unsure about how to test a newly implemented workflow before integrating it into the default branch. 🤔 Is there an approach to experimenting with a new workflow and verifying different commands/images, etc., without needing to merge every modification into the master beforehand for testing?”

[airtower-luna]

It depends mostly on the workflow trigger you're using. Some will only work if the workflow is on the default branch, but others (like push or workflow_dispatch) work on any branch. If you can test using one of those you don't need to merge first. If the workflow is supposed to run on a different event you might be able to test your code using sample data and then only change the data source before merge.

[fharper]

Most workflows can be tested on your computer with act. I still would like to see this implemented for edge cases.

[BrunoJuchli]

I would like to be able to test workflows with a workflow_dispatch and a choice input on a branch before merging it to the main branch.
Seems to me this is currently impossible, but I'd be happy if someone proves me wrong ;-)

[BrunoJuchli]

@jsoref
Why? Note that in our case we're using private repositories... I understand that you would not want contributors of a public repo to be able to just change and run workflows in your repo through PRs.

Also, does that disconnected fork have access to the secrets?
I think not, what introduces unnecessary complications (in our case of private repositories).

[jsoref]

You asked what's possible.

Forks don't have access to secrets.

Fwiw, if you need to test additional inputs, you could merge a thing which provides the additional inputs but no wiring w/ a user facing note explaining it's for use w/ specific branches.

[mickeygousset]

The workflow has to exist on the main branch in order to enable the manual run button. So normally what i do is create a blank workflow and push it to main. Then I can edit the workflow on a branch off of main, and when I run it, I can tell it to run on that branch and it will use the version on that branch.

[tedparagon]

Thanks @mickeygousset. This seems like the least painful option even though it still requires an extra PR. As mentioned above it would still be nice to be able to run the new workflow off the feature branch in the UI without first merging to main.

[BrunoJuchli]

@mickeygousset
That's what I usually do, but AFAIK the choice UI is not available when you add the choice spec on the branch.

@jsoref
Thanks for your comments.
These workarounds are doable but far from ideal. As long as there's no better option, it's good to have these documented.
However, I would still like GH to implement "first class" support for these scenarios.

[Zordid]

How can such a simple thing be SO SCREWED up on Github?? I simply cannot understand how completely messed up GH actions are. It is absolutely NORMAL for any developer to NOT push things directly on main, I do not want to mess up my main branch only to develop a new action. Unbelievable.

[jsoref]

I can't quite tell from your complaint which part of things is bothering you.

GitHub might not show you a workflow in its left sidebar, but you absolutely can push a workflow to a branch that is defined to run on the branch to which you push it, and have it run.

Do you have a specific repository and workflow in mind?

[Zordid]

As stated, I am talking about a workflow_dispatch Action, not triggered by a push, as I need input parameters. Finding out why my workflow shows up but cannot be run was a total mess. When you push a malformed workflow to any branch, no matter the trigger, it shows up on the left side, but you don't find the "run action" drop-down anywhere. It is simply not understandable to a new user and no document explains this. The only way to develop a brand new action with inputs is to first merge some empty / incomplete workflow on main in order to then start developing it on a feature branch. All the time the not-yet-ready workflow is now shown to all users of the repo as if it were already there and working... Josh Soref ***@***.***> schrieb am Di., 5. März 2024, 13:25:

…

I can't quite tell from your complaint which part of things is bothering you. GitHub might not show you a workflow in its left sidebar, but you absolutely can push a workflow to a branch that is defined to run on the branch to which you push it, and have it run. Do you have a specific repository and workflow in mind? — Reply to this email directly, view it on GitHub <#25746 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABETSZTXNRMJ7W6FYR6T7VDYWW2U3AVCNFSM6AAAAAAWBTL4RKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DMNZZGYZDO> . You are receiving this because you commented.Message ID: ***@***.***>

[jsoref]

https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Is this insufficient documentation? If so, you can file an issue.

I think the idea that a workflow file can't be malformed if you want it to work is kinda easy to understand if one spends a bit of time thinking about it.

Generally my approach to workflows is:

1. develop a basic workflow with the structure I need that uses on: push -- this is easy enough to test because each push to whichever branch I'm using will trigger a run.
2. I can simulate inputs things by using the env context.
3. As you've discovered (and as is well documented), to use workflow_dispatch, when I have something vaguely working, I'll add a dummy version to the default branch with on: workflow_dispatch.
4. As for workflows being visible to all users -- that's part of working in the open. The way I deal that is that I'll do my development in a fork instead of the main repository -- as an added bonus, by doing this, I can change my default branch of my fork to the one with workflow_dispatch.

[ishi]

Actually there is way to test a new workflow on branch. First you create a skeleton implementation in the branch that is triggered by

on: 
   push:

and push it to the github so the workflow is run and github is aware of such workflow.
Next you develop the target workflow replacing the on push event with desired on: workflow_dispach.
When you push it you can trigger the workflow using the github cli command:

gh workflow run <workflow-file-name>.yaml -r <branch-name> -f input-field=value