Is there a way to do this? You can specify that the github webhook should fire under these conditions, but I don’t see a way to make buildkite actually execute the pipeline when this occurs. Thanks.
2 Likes
Hiya! No sorry, we don’t have a way to trigger directly based on a pull request title change. You’re right that GitHub send a webhook, but it’s not one we consider a code change, and so doesn’t trigger a build. We try to focus on the most widely application use cases, but we’d be keen to hear yours and see if there’s something we could do.
You could build a little Heroku or Lambda endpoint which receives GitHub webhooks and starts a build via our API if you have a specific need?
Hi - we’re using danger.js (https://github.com/danger/danger-js) to automate conventions regarding code review, including enforcing some content that we require in our pull request names and messages. So there’s no workaround to get this to trigger on message/title updates other than implementing something outside of buildkite?
1 Like
I think one way to do this is to write a danger plugin (https://danger.systems/js/usage/extending-danger.html) that looks at changed files (https://danger.systems/js/reference.html#JSONDiffValue). When there is a title/body change, use our REST API to create a build.
Hope this helps!
Hmm, I’m not sure that’s quite enough to notice when a pull request title/body changes independent of a code change.
Triggering a build to lint pull request details separately from code changes is a great suggestion! I’m not sure we can ship something to make it work out of the box for you immediately, but we do have a neat github action:
You could have a workflow which runs on pull request title/body changes which uses this action to trigger a buildkite build to then run danger. Sorry it’s a bit kludgey, but I think it’s the best way to hook up this specific use case for now.
Thanks! The pipeline action trigger looks like it may be the best option. Are the docs for the action up to date though? All the github documentation indicates workflows must be yaml, and must be stored in .github/workflows.
I got this working but had to fork trigger-pipeline-action and make some changes to how it parses the github webhook, thanks for the help.
Eep, sorry it’s not up to date @james-heap! We don’t use it very often.
Could we merge those updates in to make it easier or yourself and potential future folks?
@sj26 is the above still the prevailing view for title changes being excluded from build triggering?
I note that there is a setting “Rebuild pull requests when labels are changed” which is also not really “a code change”; I’d love to be able to remove the GH-action hack-around to being able to consider PR title changes significant for PR-compliance checks.
2 Likes
Hey @jerry, there hasn’t been any movement on this as yet.
I have let the Product folks know though and will update this thread if anything changes.
1 Like
Bump. We also need this to automate conventions regarding code review this would be awesome!
Hey @josef.bustamante, welcome to the community! 
There still hasn’t been any movement on this yet, so I’ve raised it with the Product folks again and we’ll be sure to update this thread when there are more updates.
2 Likes
Any update on this? We also have the Danger usecase, that’s the only CI task we aren’t able to move to BuildKite because it includes PR title checks.
Hi @saadfarooq 
Welcome to the community! 
Unfortunately this is not something that we will be able to implement. We try to cover the common cases with our webhook integration, and we typically optimize Buildkite’s GitHub webhook integration for triggering builds on code.
But, what we’d suggest to you instead (that was also mention before), and which I think might be both more resilient and more powerful, is setting up a small GitHub Action which responds to this particular event and either triggers a Buildkite build via our API, or does the setup or teardown directly. We’ve seen customers do things like this when they have very specific workflow requirements around which actions they want to respond to in particular repos with particular conditions, beyond what we offer with webhooks.
Best!