mergerine / github-mergerine Goto Github PK
View Code? Open in Web Editor NEWDEPRECATED GitHub bot to automatically merge PRs matching certain criteria.
License: MIT License
DEPRECATED GitHub bot to automatically merge PRs matching certain criteria.
License: MIT License
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.
Since this cannot change while the app is running the logs are redundant.
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 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.
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).
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).
Research differences and compare to https://github.com/palantir/bulldozer.
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.
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.
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.
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.
This can get pretty lengthy (especially when using PR templates) and doesn't provide a lot of value.
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.
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.
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:
I propose that:
(
)
OR
(
)
That we then wait some smaller defined time and then poll again instead of waiting for the normal interval
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]
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.
Do not necessarily require reviews if the repo is not configured to require it.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.