Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Report what staging branches a PR can land cleanly on #77

Closed
MylesBorins opened this issue Sep 12, 2016 · 6 comments
Closed

Report what staging branches a PR can land cleanly on #77

MylesBorins opened this issue Sep 12, 2016 · 6 comments
Assignees

Comments

@MylesBorins
Copy link
Contributor

This would be VERY useful information for backporting

@phillipj
Copy link
Member

Huh, this sounds like a cool feature! Should it post a comment or add labels?

@addaleax
Copy link
Member

I think labels would be good? They are pretty cheap, and maybe it’s just me but I find automated github comments by bots more noisy than helpful.

@jbergstroem
Copy link
Member

I reckon just trying to rebase any branch against whatever branch would be pretty cheap? These doesn't have to show up in regular PR's, just one's that has a the land-on-$foo stuff?

@MylesBorins
Copy link
Contributor Author

what I would personally like to see would be automating adding the
Lts-watch labels if a commit lands cleanly on that release stream

On Tue, Sep 13, 2016, 1:16 AM Johan Bergström [email protected]
wrote:

I reckon just trying to rebase any branch against whatever branch would be
pretty cheap? These doesn't have to show up in regular PR's, just one's
that has a the land-on-$foo stuff?


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#77 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAecV88GKKNsj4uu9w10VuUgaN7_Eyo5ks5qpd1TgaJpZM4J6oMu
.

@jbergstroem
Copy link
Member

Oh - that would be pretty neat.

@mscdex
Copy link
Contributor

mscdex commented Oct 18, 2016

Why use the lts-watch-* labels? Shouldn't those be added by users whether there are merge conflicts or not?

Also, how would you know which labels should be added (which branches to test), unless you mean to try all branches that are not specifically excluded via do-not-land-on-* labels?

Another issue is how would you keep the labels up-to-date? If someone hasn't updated their PR/branch in awhile, there could be merge conflicts at some point.

If we stick with labels, maybe a new set of labels would be best? Like lands-cleanly-on-* or something?

Is it possible to have a webhook like Travis and other services that shows the information at the bottom of the PR? If so, would that be better than labels?

Fishrock123 added a commit to Fishrock123/github-bot that referenced this issue Nov 16, 2016
Fishrock123 added a commit to Fishrock123/github-bot that referenced this issue Nov 16, 2016
Fishrock123 added a commit to Fishrock123/github-bot that referenced this issue Nov 16, 2016
Fishrock123 added a commit to Fishrock123/github-bot that referenced this issue Nov 16, 2016
Fishrock123 added a commit to Fishrock123/github-bot that referenced this issue Nov 16, 2016
Fishrock123 added a commit to Fishrock123/github-bot that referenced this issue Nov 16, 2016
Fishrock123 added a commit that referenced this issue Nov 16, 2016
Fishrock123 added a commit that referenced this issue Nov 16, 2016
Fishrock123 added a commit that referenced this issue Nov 16, 2016
Fishrock123 added a commit that referenced this issue Nov 16, 2016
Fishrock123 added a commit that referenced this issue Nov 16, 2016
Fishrock123 added a commit that referenced this issue Nov 16, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants