@cschleiden I’m also unable to enable the workflow_dispatch UI feature on this workflow: https://github.com/informalsystems/apalache-tests/actions?query=workflow%3A"Run+Benchmarks" I’ve tried changing the name of the workflow and the name of the file its in, and none of it has seemed to help. Any chance we could be hitting the same bug?
Hello @shonfeder ,
The workflow file doesn’t appear to be in the default branch, please see https://docs.github.com/en/actions/configuring-and-managing-workflows/configuring-a-workflow#manually-running-a-workflow
Oh that explains it! I had missed that in the documentation. Thank you for the quick diagnosis and I’m sorry for the needless ping
I am facing a similar issue with private repository
In order to make workflow action visible, I have to get it triggered once by the push or something automatic, then revert the commit for auto triggers and have only manual triggers, then only the button appears to trigger it manually.
Let me know if I should provide any specific details. The branch is default branch, but to reproduce it, if any yaml file has only workflow action in private repo it just doesn’t appear.
This is the way I am using it.
on: workflow_dispatch: inputs: environment: description: 'Environment to deploy on' required: true default: "dev" action: description: 'Terraform Action to perform' required: true default: "autoapply" extraArgs: description: 'Extra Args for tf command' required: false
Any help would be appreciated, thanks in advance.
Could you guys please add that information in this documentation page as well -
(OR - Consider supporting other branches rather than the “default” one for manual triggering, it would help a lot )
Hi @cschleiden, I am also having the same issue on my private repo, the workflow with
workflow_dispatch does not show up. The same workflow but on a public repo works just fine
In case it helps someone, it worked after changed the file name! It seems that it is a bug with previous file names with the same name.
@cschleiden just FYI we had this bug too and had to rename the file.
In our case, we force pushed the git history back in time to where the file no longer existed, then merged a PR to add it back in. After this happened, the workflow never appeared in the UI (even after I forked the repo!) It was only after renaming the file it started showing up.
I can confirm, that renaming the file does the trick. And I can also confirm, that this happens if you rebase/force push.
I have exactly the same issue. Please fix this.
Hi @cschleiden The fact the workflow must be in the main branch is very odd and unexpected.
In my case, I’m working on a public repository and I don’t see the workflow because it’s not in the main branch. But the problem is, I’m working on a repository that holds different “variants” of the same app, one per branch. The “main” branch is a documentation branch and doesn’t contain any code.
Each branch has its own worklow configuration, which is different. The whole project is meant to be forked using one of the branch that will become the main branch of the fork. (it’s basically a boilerplate repository, that holds different apps, but only one app is meant to be used eventually)
My expectation was to find the workflow within the selected branch (select as filter), but it doesn’t work either.
I’m not sure if you intend to provide a solution for such advanced use case. But your way of doing things has a big shortcoming, because it’s impossible to manually test any workflow until it’s merged with master, this isn’t great at all. Also, it’s a very different developer experience compare to workflow that trigger automatically based on the branch they were pushed on. I really wonder why you designed manual triggers this way, it’s very confusing.
You could add an empty workflow with a
workflow_dispatch trigger to your default branch. That will cause the UI to show up and when you then select a different branch in the dropdown, its
inputs will be used.
Thanks for the tip, it works great. There is one thing to know though, is that you must use the exact same filename in your main branch as you do in your other branches, and you basically need to “mock” each workflow using one mock file.
Here is the content of my mock file at https://github.com/UnlyEd/next-right-now/tree/gh-pages/.github/workflows
# Summary: # Mock workflow that does nothing on its own # Trick to force GitHub UI to show the "Run workflow" button on all branches # See https://github.community/t/cant-trigger-workflow-manually/121740/53?u=vadorequest name: Mock "Deploy to Zeit (staging)" on: workflow_dispatch:
Here is a short 3mn video I recorded for those who want to see it into action:
This solves my issue, as I can now trigger any workflow on any branch and test all my different workflows even though they aren’t located in the main branch.
Not being able to trigger workflow_dispatch without it being on default branch has been a real PITA.
The workaround I’m using to “enable” it (without having the workflow in default branch) is to add a
push: trigger so that the workflow runs and gets registered then I remove the
push and can use
workflow_dispatch without having to merge/push it in the default branch first.
You should be able to target a non-default branch with workflow_dispatch by passing in a branch arg GITHUB_REF as request parameter.