The Github Actions documentation mentions the repository_dispatch event in the External Events section. The table in this sections says that the GITHUB_REF points to the “Branch that received dispatch”. My question now is: How can I specify the branch when sending the repository_dispatch event? The API documentation does not mention any branch related input argument.
Thank you for being here! I wish I had better news for you, the repository_dispatch only triggers on the master branch, and it is not possible to specify a branch. We have received several pieces of feedback about this limitation and have an internal issue tracking a feature request, to which I’ve added your feedback.
Also, when the documentation links “Webhook Event Payload: repository_dispatch” through to the repositorydispatchevent type on the v3 version of the documentation, it makes it seem like I can use the payload body there, but trying to use branch gives:
"message": "Invalid request.\n\n\"branch\" is not a permitted key.",
Both are a bit confusing, would be good to update if only default branch is possible.
could I mimic the branch by passing it’s name in the client_payload and switching to that branch in my action script? (will this build be registered by github as a build on master or on the requested branch?)
is there any other webhook I could (mis)-use to signal a rebuild on a certain branch?
Our situation is as follows:
repository “lib” contains our library and publishes a package
repository “app” uses the published package to make our app
we use synchronous branches on both repositories
regularly we push to both repos at the same time after bumping the version number of the package (in lib) and its use (in app).
because they both start building at the same time the app will not find the new version of the lib and it fails.
we would like the lib to re-trigger the app as soon as a new lib-package is published, which means the second build of app would find the indicated version of the lib and will succeed
currently we have to manually baby-sit the app-build to start after lib was published
if lib could directly trigger a build of app on whatever branch it is publishing we would automate this.
This is a simplified explaination, in reality we now have 4 repos that inter-depend and that number will probably grow. This will make the baby-sitting very time-consuming.
Today, the best place to share requests for new or updated features is through our official product feedback form. Our product team working on Actions monitors that channels and considers each entry, but they may not be able to respond to every submission.
Unfortunately, the workaround you mentioned has a big drawback: It runs the workflow file specified on the default branch, not the workflow file of the checked out branch. So this only really works if the two branches have the same build/test instructions.
Some examples where this doesn’t work:
If we have a docs branch with a workflow file that converts some markdown documentation to HTML. Using your workaround, GitHub Actions would try to run the normal build instructions of the default branch (e.g. compile some code) on the markdown sources, which of course doesn’t work.
To prevent this issue, you could copy the markdown build instructions into the workflow file of the default branch. However, now you have to manually keep the two workflow files in sync when the markdown build instructions change at some point (and you need to remember to do it). This also means that any change to the markdown build instructions has to be coordinated across multiple branches, which will make things much more complicated.
Even with branches that have similar build instructions, it is very easy to get things wrong with that workaround. For example, consider some build instructions that use the current branch name for conditionally skipping checks. Another risk is that you probably won’t notice if there were slight differences in the two workflow files, which might result in inconsistent build results depending on how the build was triggered. It could even lead to corrupted release artifacts if the workaround is used to trigger a release of a different branch with slightly different build instructions.
So this workaround only works in the very specific case where both branches have exactly the same build instructions and use no advanced features such as skipping steps based on the current branch name.
To solve this problem for more use case, we need some way to trigger a workflow run on a different branch using the workflow file of that branch. I’ll send a feature request for that through the form you linked and I encourage others to do so too.