-
Notifications
You must be signed in to change notification settings - Fork 13
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
Fix issues #22
Fix issues #22
Conversation
Unused types (1)
|
Co-authored-by: Mentlegen <[email protected]>
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.
Could you please update README.md since I think the configuration changed?
@gentlementlegen tests added and issue resolved |
The configuration is fixed, but I am a bit lost with the current behavior of that plugin after testing it. I do not know if that is introduced by the changes of this pull-request, but look at this run:
|
So because you used the /start command last month, then just now assigned via UI self-assign, it has taken the deadline from the what I assume is the comment as opposed to your self-assignment event. {
"now": "Sep 19, 2024, 3:09 PM",
"reminder": "Aug 22, 2024, 9:37 AM",
"deadline": "Aug 22, 2024, 9:38 AM",
"caller": "updateTaskReminder"
} So what's the solution? Fix the Do we as an org permit contributors to self-assign? It bypasses checks in other plugins. |
Likely myself who introduced it @gentlementlegen. Realized sort was backwards, but your example highlighted the fact we should use the timeline over comments if the timeline is later than the lastCheck so I implemented that and updated tests |
@Keyrxng I pulled your latest changes and ran again, the behavior was similar
This applies only to members but we could potentially be un-assigned for no reason the way it is happening to me right now. Can't we only based the checks to use the timeline events and check the last time a user was assigned? Related run: https://github.com/Meniole/user-activity-watcher/actions/runs/10952491105/job/30411260264#step:5:31 |
Ignore the deadline. Unassignment only should happen after 7 days of no activity (configurable) |
@@ -43,4 +43,9 @@ yarn test | |||
optOut: | |||
- "repoName" | |||
- "repoName2" | |||
eventWhitelist: # these are the tail of the webhook event i.e pull_request.review_requested |
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.
Should just use the full identifier. Shortening just will lead to confusion.
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.
So the config would take the full pull_request.review_requested
and I'll handle string splitting, is that what you mean?
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.
It doesn't look like this was ever updated in the readme.
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.
Looks like this was never fixed. Should use full webhook names.
daemon-disqualifier/tests/main.test.ts
Line 67 in 9ca3f7b
it("Should correctly transform the eventWhitelist", () => { |
QA: https://github.com/ubq-testing/user-activity-watcher/actions/runs/11016118749/job/30590832730
I got rid of the |
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.
It's not clear to me if you're ignoring the deadline as I requested, and if you are actually checking the assign event on the timeline, instead of checking the metadata from the /start response.
This looks really interesting. I'm trying to try the plugin currently and it seems to be working fine. |
["review_requested", "pull_request.review_requested"], | ||
["ready_for_review", "pull_request.ready_for_review"], | ||
["commented", "pull_request_review_comment.created"], | ||
["commented", "issue_comment.created"], | ||
["committed", "push"], |
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.
Are these defaults?
@@ -43,4 +43,9 @@ yarn test | |||
optOut: | |||
- "repoName" | |||
- "repoName2" | |||
eventWhitelist: # these are the tail of the webhook event i.e pull_request.review_requested |
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.
It doesn't look like this was ever updated in the readme.
metadata.startPlusLabelDuration = | ||
DateTime.fromISO(mostRecentAssignmentEvent?.created_at || issue.created_at) | ||
.plus({ milliseconds: durationInMs }) | ||
.toISO() || ""; |
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.
Setting the duration to an empty string looks wrong.
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.
Can address remaining problems later. The plugin is quite dysfunctional in production and I think this will get most of the essential functionality back up.
Unfortunately due to merge conflicts this won't be able to be merged.
Resolves #21
Below is the activity logged after
lastCheck
.old results from 110
new results: