Automatic PR comment

Features Requests
1

buildkite-agent annotate is a great feature when you want to present output that should stand out for a build. I think it’s particular useful when there is a myriad of log output for a build, but really only a subset is that most important thing to present to an end-user.

I have a few usecases where I’d like to run analysis of source code and I would like to make a comment in the pull request to force the developers to notice it. Using buildkite-agent annotate is not enough as developers mostly are looking at the the Buildkite builds only when they are failing. https://codecov.io does this and we’ve been very useful with that service.

To be able to do above today, I need to create my own Github API key (or app), configure a secret environment variable for it in Buildkite, and then have some script which makes the comment (likely based on BUILDKITE_PULL_REQUEST).

Now to my idea: How about introducing buildkite-agent comment which, similarly to buildkite-agent annotate, would post a comment to Github. If Buildkite is made a public Github app (instead of manually registering webhooks on a repo) I think it might be given write-access to a repository’s issues and not just read access.

I’d say there is a trend where Github bots are communicating in pull requests and we’ve found it very useful.

I’d love to hear what you think.

2

I’d like to have this feature. Especially as it is impossible to rely on BUILDKITE_PULL_REQUEST.

3

How do you mean @louis?

4

I mean that when pushing a branch and then immediately opening a pull request, the build started by buildkite when the branch was pushed can’t be attached to the pull request. BUILDKITE_PULL_REQUEST is false. Which is logical because of the order of the events. But sometimes a bit annoying.

If we had buildkite-agent comment not relying on BUILDKITE_PULL_REQUEST, it could solve this problem.

I would be fine providing a personal token too.

5

If Buildkite is made a public Github app (instead of manually registering webhooks on a repo) I think it might be given write-access to a repository’s issues and not just read access.

Agreed on this one, we are planning to do this.

6

Totally late to this, but thought you might be interested in knowing that we avoid this problem by setting Branch Limiting on our pipelines to master. I am still getting builds for any commits to master, and any Pull Request events, but we are not triggering builds for branch pushes unless there’s an open PR.