mergerine / github-mergerine Goto Github PK

Consider maintaining a label on the PR that's at the top of the queue. Add it initially and then possibly remove it once we've merged the PR or moved on.

We could post a message about what mergerine is waiting for on a given PR as the description using the GitHub Status API. This should be optional. Not sure if the status should be pending or failure or success while waiting.

Allow configuration of custom merge commit messages, possibly through a custom plugin function/module. Enable to override the default squash merge commit message behavior of rolling up the PR's commits' messages in a bulleted list with the PR title at the top. E.g., to pull from the PR's body/description, labels, etc.

For more immediate responsiveness and less API quota consumption as compared to the current polling implementation, we should support integration with repository webhooks and the GitHub Events API.

Add a config option, for example "staleWhenOlderThan": ["14d"]. After mergerine fetches PRs that match labels and notLabels options, it would filter stale results out before populating its queue.

When the mergeable state is "unknown" that means github is calculating mergeability. Github does not calculate this until you call the GET /repos/:owner/:repo/pulls/:number API to probe the status. You then need to wait and hit the GET /repos/:owner/:repo/pulls/:number API again to get the status.

Currently the following causes mergebot to "take longer" then normal:

• PR is merged
  • This makes all other PRs "outdated"
• Mergebot polls and all PRs return that mergeable state is unknown
• Mergebot sleeps
• Mergebot polls again and all PRs properly return their mergeable state

I propose that:

(

• if at least 1 PR isn't healthy to take action on (merge/update/wait to finish) AND
• that at least 1 PR was "mergeable state is unknown"

)
OR
(

• All PRs return "mergeable state is unknown"

)

That we then wait some smaller defined time and then poll again instead of waiting for the normal interval

Allow configuration of a custom label like merge:2020-01-01 to schedule future merges. If a PR passes all other merge criteria, but has a label indicating a merge should not occur until a future date/time, then skip it on the current cycle.

Since this cannot change while the app is running the logs are redundant.

Look for BREAKING CHANGE text in PR description or commit messages on the PR branch and include that text in the merge commit body for Conventional Commits and Semantic Versioning.

This will be an alternative to already supported syntax of including a ! after the type/scope in the PR title.

This can get pretty lengthy (especially when using PR templates) and doesn't provide a lot of value.

Research differences and compare to https://github.com/palantir/bulldozer.

With the current FIFO strategy, this would help bump critical bug fixes to the front to be merged quicker.

Add a config option, for example "priorityLabels": ["high-priority,urgent,critical"].

Quick and dirty solution: Make two Github fetch calls, one for priorityLabels and one for labels, with priorityLabels populating the end of the array and labels at the front, maintaining FIFO.

Better solution. Make a single Github fetch call and perform a sort algorithm that puts the highPriority items at the end and everything else at the front. Need to maintain the same FIFO order for each set of results.

Example:
[normal3, normal2, normal1, urgent3, urgent2, urgent1]

Look for Jira issues and smart commits in PR description or commit messages on the PR branch and include in the merge commit message body (especially for squash merges and the mergeCommitMessageSimple option).

The results array logs a list of pull requests objects that are not readable.

results:
   [ { pull: [Object] },
     { pull: [Object] },
     { pull: [Object] },
     { pull: [Object] } ]

Seems like this might be redundant with the "decision" log messages that are already logging pr number and the mergeability state.

2018-06-08T13:22:19.450Z mergerine:decide results 3986,4976,5656,7211
2018-06-08T13:22:19.450Z mergerine:decide 3986 is not clean, not merging
2018-06-08T13:22:19.452Z mergerine:decide 7211 is not clean, not merging
2018-06-08T13:22:19.499Z mergerine:decide 4976 is not behind, not updating
2018-06-08T13:22:19.499Z mergerine:decide 5656 is not behind, not updating

Look at using the GitHub GraphQL API v4 to hopefully consolidate some of the calls. May be less necessary if we switch to the Events API (#6).

Do not necessarily require reviews if the repo is not configured to require it.

Add a configuration field to disable the updating of PR branches, leaving only merges as an operation. Should probably implement as a whitelist of actions/phases to enable, so we're future proof and it's safe for users to update in future if new actions/phases are added that they would not want by default.

Optionally, via configuration, include an HTTP server that exposes a health check endpoint so that systems hosting and managing a mergerine instance can ping it to check if it's still running, etc. At least return an HTTP 204 No Content, or 200 OK status with some minimal metadata in the response body - maybe consider this IETF RCF for Health Check Response Format.