Currently it looks like the PRs trigger builds only when they are opened or new commits are pushed to the PR branch.
What I’m missing is control over which PRs should trigger the builds in the first place. Mainly I don’t want to trigger a build when the base branch is not one I care about. Maybe even use the global branch filtering for this? Now it’s possible to do with pipeline conditionals, but that’s a bit of a hack IMO and adds the “This build was skipped” in the UI.
Second thing I’d like to see around this, is that if I open a PR first against a base branch I don’t care about and later change the base branch, that should trigger a potential build if the new base branch matches that new branch filter. Ideally it should also trigger the build if the base branch is modified. That way it would be possible to do integration builds without the need to be constantly rebasing the PR branch.
The integration testing itself isn’t that hard to do with basic git commands. Unless that plugin somehow also triggers the builds when there are changes to the ref branch, I don’t see how it helps here.
For example, 2 PRs are open against main branch, both have passing builds. PR#1 gets merged, PR#2 should get rebuilt, to verify it still passes with the changes of the PR#1.
Also the plugin doesn’t really help if we’re not using Github :)
That is fair - based on the features you were describing I presumed you were talking about our GitHub integration. What source control provider are you using?
Hey @pahnev as Jess mentioned we have some new gear that we plan to release in the next couple of months that might help. If you send us a message to support@buildkite.com we can look at setting it up for you if you would like to beta test it out?