syndesisio / pure-bot Goto Github PK

Per Roland's comment here, opening this issue to request

• The bot to automatically add an issue with the label notif/uxd to https://github.com/syndesisio/syndesis/projects/2.
• The bot to automatically tag @syndesisio/uxd when label notif/uxd is applied.

If only one of the above requests can be done, that's fine. The goal is to not miss any uxd related issues and have a timely response when possible.

I'm still trying to learn to best way to use Repo Project. @rhuss @heiko-braun Please advice if you know any best pratices. Thank you!

Examples:
syndesisio/syndesis#3675
syndesisio/syndesis#3674

Since GH issues, nor ZenHub extension don't provide extensive set of status values that could be used similarly to Jira. I've a proposal to implement additional labelling by the Pure bot.

I've in mind especially unverified/ready to qe status or set resolved and then close manually maybe. That would enable clear filtering what should be checked after PR was provided for it.

For the bot config part, probably a set of labels to apply in conjunctions with approved could be sufficient for now.

Wdyt @jimmidyson @rhuss? I'm all right with asking during retrospective etc. to gather more feedback.

This would help to raise e.g. UX attention when someone else has added a "notif/uxd" label.

This issue: syndesisio/syndesis#3857 should have been reopened, moved to done and be verified by QE, but it appears the bot kicks in only when an issue is closed from a pull request, not when it's closed directly.

Suggestion: As soon as another label after the notif/triage label has been added, the notif/triage label could be removed automatically, with the assumption that labels are only addded during a triage process.

@paoloantinori @zregvart wdyt ?

Currently required to apply Triage label.

I've noticed on a couple of PRs, seems that the bot is not merging approved PRs any more. One example is syndesisio/syndesis#4213. Could be related to the CircleCI checks thing change I made.

I've found no errors the log.
pure-bot-55-56xqz.log

Seems like approved PRs are stacking up, after looking at a couple that had been sitting with an approved label for hours I found that while the PR had been approved by someone, the person who opened the PR requested reviews from multiple people, and so apparently it's now required that everyone marked as a reviewer needs to approve the changes.

Is this by design?

The same happens when changing an existing milestone.

Or however long, as issues that sit in the backlog long enough become totally irrelevant.

If it's necessary to keep a bug open, the issue reporter can always re-open, or the issue can be re-raised.

@paoloantinori @deeleman FYI

Add a new handler that checks PRs for WIP (case-insensitive, whole word) in title or a wip label and add a required status check for this to ensure this isn't merged until wip status is removed (either by removing wip label or removing WIP from PR title).

/cc @rhuss @dsimansk

See the comments on syndesisio/syndesis#3815, these should have triggered post processing, but they didn't.

Sounds like the first syllable of "Syndesis", kinda.

https://www.urbandictionary.com/define.php?term=Cindy

When a PR closes multiple issues, such as syndesisio/syndesis#6115 , the bot only automatically reopens the first one for QE verification

@zregvart and I tested yesterday a workflow for a PR which I approved in general but had one comment which might or might not be addressed (so 'nice to have'). If I would have approved it directly, then the PR gets merged immediately with no chance for the author to address the comment if he wants (he would have to open a new PR). On the other hand, I don't want to come back to the PR if there is no change. So I added a "WIP" label. The author then could either change his code because of the comment (then the Review status is reset and it would be awesome if the "Approved" label would be removed, too). Or, if he still wants to have it merged fast just remove the "WIP" label, then the PR gets merged automatically. Some sort of 'handover' of the PR back to the original author.

My idea is to extend pure-bot:

• If there is a "[handover]" in an extra line (e.g. with regexp /^\s*[+?\s*handover\s]+/mi ) in the approval comment, then pure-bot should apply a label "pr/handover" in addition to the "approved" label.
• This label should have the same semantics as "status/wip" : When present don't merge, if absent (and "approved" is there) then merge.

Thinking about it, I would consolidate the labels with semantics for pure-bot to:

• "approved" --> "pr/approved"
• "status/wip" --> "pr/wip"
• ... -> "pr/handover"

Happy for other naming suggestion, though.

@syndesis/all wdyt ?

Seems it's not working on https://github.com/atlasmap/atlasmap

pure-bot is active for every repo in the organization, but we might want to restrict the notif/triage label to syndesis only as the other repos (e.g. this one) might follow a different process.

• GET issue to return the pipeline ID together with the name
• Add release attribute events to custom webhook API (zenhub outbound)

In order to speed up the PR review process we want to automatically merge PRs without review is they are tagged by the author with 2s2f ("too small to fail"). Thes are supposed to be mini PRs changing for which the author is confident that no review is required.

See syndesisio/syndesis#506 for the original issue.

As a bonus pure-bot could check the size of the PR and if it exceeds a certain limit then do not merge (and remove this label).

@jimmidyson is this hard to implement ?

If changes are requested bot should remove pr/approved label and not merge the PR. Example syndesisio/syndesis#5329

Now it's a bit annoying to remove notif/triage everytime. Instead I'd like to have prio/p1 applied when cat/bug is applied but there's no prio/* label.

It would be neat if group and category labels would be in sync between the issue and the PR addressing that issue.

Currently, github will prevent from auto-mergin when an approved PR has been updated. It would be nice, though, when the label would get removed, too as a new review is required anyway (and the PR is factually not approved anymore when the PR has been updated.

I think that if a PR is approved, but has failing checks, it will get merged.
This shouldn't be the case.

The bot moves to backlog when milestones are assigned. Prevent it from moving things around when ,milestone changes happen outside the inbox.