FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Allow adding labels when a backport fails by gotmax23 · Pull Request #40 · sanitizers/patchback-github-app · GitHub

Allow adding labels when a backport fails - #40

Open
gotmax23 wants to merge 4 commits into
sanitizers:masterfrom
gotmax23:failure_label
Open

Allow adding labels when a backport fails#40
gotmax23 wants to merge 4 commits into
sanitizers:masterfrom
gotmax23:failure_label

Conversation

gotmax23 commented Oct 13, 2023
edited
Loading

Copy link
Copy Markdown

This adds a label when a backport fails and removes the original
backport label.
This makes it easier to identify failures without having to open up the
issue and scroll all the way down.


Example run:

  1. User adds backport-2.15 label
  2. Backport fails
  3. Patchback creates failed-backport-2.15 label if it doesn't already exist
  4. Patchback adds failed-backport-2.15 label
  5. Patchback removes backport-2.15

Fixes: #39

These wrappers follow the same conventions as the other *_api modules.
This will be used for the new labels API.
This adds a label when a backport fails and removes the original
backport label.
This makes it easier to identify failures without having to open up the
issue and scroll all the way down.
Comment thread patchback/config.py
Ensure backport_label_prefix and failed_label_prefix are different to
avoid infinite loops.
gotmax23 force-pushed the failure_label branch 2 times, most recently from ae57f20 to d91840a Compare October 14, 2023 20:49
Comment on lines +549 to +550
# Delete backport label
await issue_labels_api.remove_label(backport_label)

gotmax23 Oct 15, 2023
edited
Loading

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

I'm debating whether it makes sense to also drop the existing backport label on failures. Wdyt?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

A-la #12? That'd need to be a separate PR.

Copy link
Copy Markdown
Member

I'll probably have to add the standard linting I usually have in my projects before going through the review. I noticed some style deviations that I'd rather delegate to automatic systems. I haven't done so because barely anybody contributed and I usually know what I want anyway.
I'd love some testing but currently, there's no machinery for integration/e2e style checks. Unit tests should be possible to implement, I think.

Anyway, I don't think I'll get to it today as the GitHub Apps are getting kicked out of the OpenShift cluster that is going away for good tomorrow. So I'm prioritizing migrating them to OSCI today.

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[FR] Add a label to PRs when a backport fails

2 participants


Back | FazBrowse Home | New Git URL