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.

1.4.0

Use GraphQL for some API operations (#37)

To access additional information, policy-bot now uses GitHub's v4 GraphQL API. As a result, the v4_api_url configuration option is required.

Add the ability to ignore update merges (#39)

If the ignore_update_merges option is true, any merge commit that was (1) created via the web UI or API and (2) includes changes from the target branch is ignored for the purpose of the computing contributors and evaluating the invalidate_on_push option. This means you can use the "Update branch" button in the GitHub UI without invalidating existing approval. See the README for more information about this feature.

Fixes

• Use push time instead of commit time when evaluating the invalidate_on_push option (#37)
• Correctly update statuses after a GitHub review is dismissed (#38)

Other Changes

• Show the total number of required reviews in the details for a rule (#36)
• Include a link to the policy file from the details UI (#40)

1.3.2

Prevent users from approving a change multiple times (#35)

Prior to this, a single user could satisfy a policy that required more than one approval. Now, only the most recent event from each user is considered when computing approval.

Other Changes

• Make Datadog configuration optional (#26)
• Improve README

1.3.1

Use only branch name in status check context (#23)

The new status check contexts added in 1.3.0 used the full branch label (which included the organization, similar to what it looks like when merging in a fork). Now, only use the branch name as originally intended.

1.3.0

Improved Status Check Context

This release is mainly focused on modifying the context value used for the status check. Originally it was the same value for all PRs. To improve policy-bot's ability to protect branches, we've changed the default behavior to produce a context using the following template: <configured-context>: <target-branch-of-pr>. For example, if the PR is targeting the master branch, the context would be: policy-bot: master.

You can still use the legacy context by turning on the config flag post_insecure_status_checks. For more information, see the godoc.

Other Changes

• Publish snapshot Docker images (#6)
• Improve README