Help
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Pilot Lvl 1
Message 1 of 7

How to trigger repository_dispatch event for non-default branch?

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.

 

Thanks!

 

6 Replies
Highlighted
Community Manager
Message 2 of 7

Re: How to trigger repository_dispatch event for non-default branch?

Hi @phil-opp,

 

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. 


My very best,
Andrea

Mark helpful posts with Accept as Solution to help other users locate important info. Don't forget to give Kudos for great content!

Highlighted
Pilot Lvl 1
Message 3 of 7

Re: How to trigger repository_dispatch event for non-default branch?

Thanks for clarifying! Perhaps the documentation at https://help.github.com/en/actions/automating-your-workflow-with-github-actions/events-that-trigger-... should be updated to reflect this (the `GITHUB_REF` column says "Branch that received dispatch" instead of "default branch").

Highlighted
Copilot Lvl 2
Message 4 of 7

Re: How to trigger repository_dispatch event for non-default branch?

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.",
  "documentation_url": "https://developer.github.com/v3"
}

Both are a bit confusing, would be good to update if only default branch is possible.

Highlighted
Copilot Lvl 2
Message 5 of 7

Re: How to trigger repository_dispatch event for non-default branch?

My problem with the repository dispatch is that it needs a token with repo permission. Isn't it possible to severely limit the scope of the token in order to avoid consequences if it gets compromised?

Highlighted
Pilot Lvl 1
Message 6 of 7

Re: How to trigger repository_dispatch event for non-default branch?

This seems like a different problem, so it's probably better to create a new topic for it.

Highlighted
Pilot Lvl 1
Message 7 of 7

Re: How to trigger repository_dispatch event for non-default branch?

Since we need this a lot...

 

two questions:

  • any news on this since last November?
  • 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.