Skip to content
This repository has been archived by the owner on Jun 12, 2023. It is now read-only.

Trigger builds via GitHub pull request comments #288

Open
avtar opened this issue Nov 8, 2017 · 8 comments
Open

Trigger builds via GitHub pull request comments #288

avtar opened this issue Nov 8, 2017 · 8 comments

Comments

@avtar
Copy link

avtar commented Nov 8, 2017

A very common workflow for open source projects is to request that contributors fork official project repositories, make changes in their own branches, and then issue pull requests using the forked repositories and branches. The Buildkite Build pull requests from third-party forked repositories GitHub setting would be safer if additional settings were provided that prevented CI jobs from running unless verified by upstream project members. Please consider adding support for:

  • Maintaining a list of trusted GitHub accounts that can send PRs and have associated CI jobs run automatically
  • If a PR from an unrecognized account is provided then Buildkite should prompt project members in the PR comments thread -- the Jenkins GitHub Pull Request Builder plugin would be an example of this type of feature
  • If a confirmation string is posted in a PR comment by a trusted account then the CI job is run
@avtar avtar changed the title Triggering builds via GitHub pull request comments Trigger builds via GitHub pull request comments Nov 8, 2017
@KevinGrandon
Copy link

This would be cool, but TBH you can build this fairly easily using a bot like probot (https://github.com/probot/probot), and the buildkite REST API. I'm doing something similar and it's working well for us.

@lox
Copy link
Contributor

lox commented Nov 10, 2017

Yeah, would be awesome to see something like this that used a block step and our API.

@avtar
Copy link
Author

avtar commented Nov 10, 2017

@KevinGrandon, @lox I've opened #293 that focuses solely on the secure third-party PR defaults aspect.

Since the GitHub Statuses API is already being used to provide PR feedback about some aspects of the CI process I would argue that this feature (indicating a build is blocked and allow for unblocking) would be useful in Buildkite itself instead of relying on a third-party solution.

Perhaps this is an oversight on my part but currently if a block step is used the feedback provided in the PR thread seems incomplete. Because the pipeline was successfully uploaded it would seem to a third party contributor that the CI job has passed whereas on the Buildkite dashboard it's waiting to be resumed.

@nhuray
Copy link

nhuray commented Dec 7, 2017

@KevinGrandon Did you opensource your probot/buildkite application ?

@KevinGrandon
Copy link

@KevinGrandon Did you opensource your probot/buildkite application ?

Sorry, this issue has changed a bit. I think you could do a probot to trigger a build using a hosted probot and the buildkite API. I am not sure if you can turn off third party builds, and use the buildkite API to trigger a build /w block step, it seems that the API might not support running on a branch other than the default?

Regardless though, I hope we get something like #293.

@michaelpj
Copy link

A very simple version of this would be to only build on PRs from forks initiated by users who have write access to the main repository. This seems like a good proxy for "trusted", and enables the common workflow where people have write access to the main repo but still push feature branches to their forks to avoid cluttering the main repo.

@ali-ramadhan
Copy link

I'm guessing this is still not possible?

Setting up a GitHub Action to trigger a Buildkite pipeline based on a comment seems like a possible solution: https://github.com/buildkite/trigger-pipeline-action

@GMNGeoffrey
Copy link

GMNGeoffrey commented Feb 17, 2022

Returning to the topic title here. Independent of issues of third-party forks, it would be nice to be able to trigger buildkite pipelines on other GitHub events (specifically comments). Could buildkite add a generic "webhook" trigger? I would be happy to add the logic to parse the webhook event and decide what to do based on it. Triggering from a GitHub action adds an unfortunate dependency on another automation system that I have found to be pretty slow and unreliable (which is why I'm advocating Buildkite as the automation system my team standardizes on).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants
@lox @avtar @KevinGrandon @nhuray @michaelpj @GMNGeoffrey @ali-ramadhan and others