Releases: palantir/bulldozer
1.1.0
- track
pull_request
events, so bulldozer can trigger from labels that are added
1.0.0
Bulldozer is now a GitHub App! 🎉
As part of the rewrite, we've:
- Improved the configuration format
- Added more expressive blacklist and whitelist configuration
- Added support for Bulldozer-only required status checks
- Improved squash message generation
- Fixed other bugs and made minor behavior tweaks
- Updated to use
palantir/go-githubapp
andpalantir/go-baseapp
Bulldozer 1.0 still understands configuration from the 0.4.x series, so while you will have to enable the new application on repositories, you do not need to update configuration all at once.
0.4.12
0.4.11
0.4.10
0.4.9
Add support for multiple config file paths (#44)
Based on server configuration, the application will now look for the
repository configuration file in multiple paths until it finds one. If
no paths are specified, the existing .bulldozer.yml is used.
This commit makes the minimal amount of change necessary to get this
working. Ideally, there would be more refactoring to standardize config
passing and client construction, but I'm not ready to do that yet.
Fix leaks when polling for PR mergeability (#43)
The GitHub API requires polling PR status if the mergeable property is
null, because a background job is running to compute this value. But the
mergeable property is also null for merged PRs. In cases where there was
a race between multiple requests to merge the PR (e.g. if there were
many status updates at once), one or more of these requests would end up
polling a merged PR forever, waiting for it to be mergeable.
Add a limit on the total number of poll attempts and also check for PRs
that are merged or closed after we start polling. In addition, only try
to merge PRs in response to successful status checks.
Add update strategy config option (#30)
Values are "deferToPR" and "always"
0.4.8
Modify github approval verification logic (#29)
- Modify github approval verification logic
If reviews are not required for a repo, then only consider review status
as failed if someone has explicitly disapproved the repo
Fixes #27