1.9.1

Add author_is_only_contributor predicate (#77)

This predicate applies if the pull request author is the only author and committer of commits in the pull request. It's useful in conjunction with has_author_in to reduce or increase the approval required for specific authors only when no other users have added commits to the same branch.

Retry loading data if initial response is missing information (#78)

This is a workaround for a GitHub API issue where new information about a pull request is sometimes not available at the time the pull_request webhook event is received.

1.9.0

This release includes changes originally released in the 1.7.x and 1.8.x versions. These older releases are not recommended due to regressions in important functionality.

Fix invalidate_on_push for pull requests from forks (#61, #68, #76)

Originally released in 1.7.0, fully fixed in 1.9.0.

Due to API limitations in GitHub, the information required to implement invalidate_on_push was not being returned for pull requests from forks, meaning new commits pushed to these PRs did not invalidate approval. We've switched to an alternate method of retrieving push times for commits from forks.

Note: policy-bot now errors on pull requests from private forks. We believe that these PRs are uncommon and that fixing the invalidate_on_push behavior is more important, but please let us know if you relied on this functionality.

Add modified_lines predicate (#71)

Originally released in 1.8.0

Users can now use the modified_lines predicate to apply rules based on the number of lines added or removed by a pull request. See the README for details on how to configure this predicate.

Fix error when posting audit statuses (#73)

Originally released in 1.8.1

policy-bot monitors status checks to verify that other users with write access do not overwrite the statuses generated by policy-bot. If an overwrite is detected, policy-bot posts a failed status, but previously used a description value that was too long, causing GitHub to return an error response instead.

Adjust how update merge commits are detected (#76)

A commit is now considered an update merge (for the purpose of the ignore_update_merges option) if it is created via the UI or API and has exactly two parents, one that is part of the pull request and one that is not. Previously, the second parent had to appear in the last 100 commits on the target branch. The new method is simpler and takes advantage of the fact that GitHub already excludes commits that exist on the target branch from the pull request commits.

Other Changes

• Administrators can now set the log level in the configuration (#60)
• Fix a long-standing data race with default approval and disapproval methods (#66)
• Build with Go 1.12.4 and Godel 2.16.0 (#67)

1.8.1

Due to a significant regresssion, this release is not recommended. Please use version 1.9.0 or newer.

1.8.0

Due to a significant regresssion, this release is not recommended. Please use version 1.9.0 or newer.

1.7.1

Due to a significant regresssion, this release is not recommended. Please use version 1.9.0 or newer.

1.7.0

Due to a significant regresssion, this release is not recommended. Please use version 1.9.0 or newer.

1.6.1

Add commit information to log messages (#58)

Log messages for webhook handlers now include the SHA of the head commit of the pull request being evaluated. This makes it easier to tell how the status of a particular commit was determined.

Other Changes

• Fix incorrect repository content permissions in the README (#59)

1.6.0

Load pull request data directly instead of using the timeline (#54)

Since 1.4.0, the pull request timeline has not been used for event ordering. The API also has some small delay in recording new events, particularly when the pull request is from a fork. This delay could cause policy-bot to miss new commits and post incorrect rules statuses based on old commits when the invalidate_on_push option was used.

Verify that the head commit of a pull request exists in the internal commit list (#55)

As described above, if GitHub APIs do not return all information for a pull request, policy-bot can generate incorrect results. There is now an explicit check for this condition, which will cause rule evaluation to fail closed if this happens again instead of failing open.

Other Changes

• Update the app URL on the install page to account for changes on github.com

1.5.0

Resolve admins and collaborators on pull requests as approval actors (#48)

This allows policies to specify that repository admins or users with write permissions should be allowed to approve pull requests. This can make policies easier to manage if you already manage repository permissions.

1.4.1

Fix usernames for bot users (#44)

The GraphQL API returns usernames for bot users in a different format, leading to a regression for policies that reference bot users with the [bot] suffix. The application now converts all usernames to the existing format used by the V3 API.

Other Changes

• Update permissions to include read-only access to repository content. This is required to read commit metadata from the GraphQL API.