-
Notifications
You must be signed in to change notification settings - Fork 63
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
Update Stale Workflow #1566
Update Stale Workflow #1566
Conversation
Failing check unrelated to my changes, will rerun to see if it changes the outcome. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Jdubrick, thepetk The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@thepetk workflow keeps failing but I highly doubt it is because of the changes in this PR. Wdyt is the course of action? |
Ive noticed the same behaviour in other prs (similar error trace). Id suggest waiting a little bit before investigating as the PR is not so urgent and we can retest later. Wdyt? |
Sounds good to me. Can give it some time and revisit on Monday, if the checks are still failing we can bring it up in standup about pushing through anyway if unrelated |
Yeah I agree. Is very unlikely to be related with the PR :D |
/retest |
Signed-off-by: Jordan Dubrick <jdubrick@redhat.com>
Signed-off-by: Jordan Dubrick <jdubrick@redhat.com>
ec2b5f4
to
dde31c9
Compare
New changes are detected. LGTM label has been removed. |
@thepetk rebase and fixing some whitespace seemed to fix the issue. Weird but it did the trick. Can you re-review please? |
Very weird :D But yeah my review remains the same. Nice addition to the workflow! |
What does this PR do?
Updates stale workflow to address older issues not being properly marked as stale. In the workflow we had a
start_date
which by their docs means any PR or issue opened before that date is not going to be checked. Additionally, addedascending: true
so that it will start from the lowest issue # item and work its way to the newer ones, ensuring that the oldest issues are checked first.Which issue(s) does this PR fix
fixes #1529
fixes #1528
PR acceptance criteria
Testing and documentation do not need to be complete in order for this PR to be approved. We just need to ensure tracking issues are opened.
Unit/Functional tests
QE Integration test
Documentation
Client Impact
How to test changes / Special notes to the reviewer