action #73468
closedcoordination #69310: [epic] SUSE QA tools team ticket process helpers
SUSE QA tools team ticket process helpers: Set due date on tickets in redmine based on SLOs
0%
Description
Motivation¶
See https://progress.opensuse.org/issues/69310#Motivation
Acceptance criteria¶
- AC1: due dates in progress tickets are automatically set based on our SLOs
Suggestions¶
- Research how we are already conducting checks on our backlog from github actions: https://github.com/os-autoinst/scripts/blob/master/.github/workflows/backlog.yml
- Consider an additional GitHub action or similar workflow
- Automatically fetch ticket queries corresponding to SLOs in https://progress.opensuse.org/projects/qa/wiki#How-we-work-on-our-backlog to find tickets which are exceeding the limits
- For each ticket set a due date automatically, e.g. to next day or current day with a comment pointing to SLOs
Updated by livdywan about 4 years ago
- Description updated (diff)
- Difficulty set to easy
Updated by livdywan about 4 years ago
- Status changed from Workable to In Progress
Updated by ilausuch about 4 years ago
I started an draft PR https://github.com/os-autoinst/scripts/pull/44
Updated by ilausuch about 4 years ago
According to the comment https://github.com/os-autoinst/scripts/pull/44#issuecomment-732184256 and after several reviews the code updates the due date under these conditions:
- The priority is not Low
- No previous due date set
- Not assigned to anyone
- Not blocked or resolved
Additionally there are a dry run mode
Runs the script without updating the tickets
dry_run=1 ./backlog-set-due-date
Equal than 1 but also extract the tickets from a file instead of a file
dry_run=1 ./backlog-set-due-date <issues-json-file>
Updated by okurz about 4 years ago
- Due date set to 2020-12-12
Setting due date based on mean cycle time of SUSE QE Tools
Updated by livdywan about 4 years ago
Also https://github.com/os-autoinst/scripts/pull/51 for the CI enablement
Updated by livdywan about 4 years ago
- Status changed from In Progress to Feedback
And it should probably be Feedback as we have the pieces, and now we can see if it works as well as we hope when normally scheduled.
Updated by ilausuch about 4 years ago
- Status changed from Feedback to Resolved
It seem it works automatically
See the last example https://github.com/os-autoinst/scripts/runs/1484188834?check_suite_focus=true
Updating ticket 80576, new due date setup to 2020-12-16
curl -v -H X-Redmine-API-Key: *** -H Content-Type: application/json -X PUT -d {"issue": {"due_date": "2020-12-16", "notes": "Setting due date based on mean cycle time of SUSE QE Tools"}} progress.opensuse.org/issues/80576.json
I put that as resolved
Updated by okurz about 4 years ago
- Status changed from Resolved to Feedback
seems to not work in all the cases, e.g. could you please check why the script does not set a due date on #67723?
Updated by ilausuch about 4 years ago
For some reason if I execute a query to extract this issue from the list of this project is not returned, and the problem is not the limit
curl "https://progress.opensuse.org/issues.json?project_id=18&limit=100000" |jq '.issues | .[] | select(.id==67723)'
NOTE: I tried to use a grep directly over the result of the query with the same results
But if I ask directly for this issue this is on this project, so I don't see a reason to not be showed
curl https://progress.opensuse.org/issues.json?issue_id=67723 | jq
{
"issues": [
{
"id": 67723,
"project": {
"id": 18,
"name": "openQA Project"
},
"tracker": {
"id": 4,
"name": "action"
},
"status": {
"id": 2,
"name": "In Progress"
},
Maybe a bug on the https://progress.opensuse.org/issues.json query?
Updated by ilausuch about 4 years ago
Update,
This is the complete result of this issue. Notice that has a close_on Date, maybe this is the reason because doesn't appears on the list
{
"issues": [
{
"id": 67723,
"project": {
"id": 18,
"name": "openQA Project"
},
"tracker": {
"id": 4,
"name": "action"
},
"status": {
"id": 2,
"name": "In Progress"
},
"priority": {
"id": 4,
"name": "Normal"
},
"author": {
"id": 29593,
"name": "ggardet_arm"
},
"assigned_to": {
"id": 32669,
"name": "Xiaojing_liu"
},
"category": {
"id": 142,
"name": "Feature requests"
},
"fixed_version": {
"id": 418,
"name": "Ready"
},
"parent": {
"id": 80372
},
"subject": "Remote openQA worker fails to run tests from openqa-clone-custom-git-refspec",
"description": "## Observation\r\n\r\nRemote openQA worker fails to run tests from `openqa-clone-custom-git-refspec`, see: https://openqa.opensuse.org/tests/1287895\r\n\r\n~~~\r\n\u001b[0mneedles_dir not found: /var/lib/openqa/pool/2/os-autoinst-distri-opensuse/var/lib/openqa/cache/openqa1-opensuse/tests/opensuse/products/opensuse/needles (check vars.json?) at /usr/lib/os-autoinst/needle.pm line 330, <$fh> line 20.\r\n\u001b[37m[2020-06-04T09:10:50.934 UTC] [debug] terminating command server 19004 because test execution ended through exception\r\n\u001b[0m\u001b[37m[2020-06-04T09:10:51.935 UTC] [debug] done with command server\r\n\u001b[0m18926: EXIT 1\r\n~~~\r\n\r\nIs there anything to setup?\r\n\r\n## Motivation\r\nAs a user of remote openQA worker instances I want to be able to use openqa-clone-custom-git-refspec as well\r\n\r\n\r\n## Acceptance criteria\r\n* **AC1:** openqa-clone-custom-git-refspec creates jobs with valid CASEDIR and valid NEEDLES_DIR if source job is a \"remote worker\"\r\n* **AC2:** openqa-clone-custom-git-refspec still creates jobs that find tests from specified git hash and needles for other workers\r\n\r\n\r\n## Suggestions\r\n* Croscheck the command line with which openqa-clone-job would be or is called within `openqa-clone-custom-git-refspec` in case of normal workers or the affected machines\r\n* As it seems that the paths given to openqa-clone-job seem valid also check how openQA internally handles paths to generate the obviously wrong path like \"/var/lib/openqa/pool/2/os-autoinst-distri-opensuse/var/lib/openqa/cache/openqa1-opensuse/tests/opensuse/products/opensuse/needles\"\r\n* Either apply fix in openQA side or openqa-clone-custom-git-refspec",
"start_date": "2020-06-04",
"due_date": null,
"done_ratio": 0,
"is_private": false,
"estimated_hours": null,
"custom_fields": [
{
"id": 16,
"name": "Difficulty",
"value": "easy"
}
],
"created_on": "2020-06-04T09:18:43Z",
"updated_on": "2020-12-03T09:47:51Z",
"closed_on": "2020-07-07T13:31:04Z"
}
],
"total_count": 1,
"offset": 0,
"limit": 25
}
Updated by okurz about 4 years ago
- Status changed from Feedback to Resolved
Thanks for crosschecking. So yes, I agree that #67723 has a bit of a messy history :D So we should keep in mind that our helper scripts leave tickets alone when they are not that "clean" anymore :) I agree that the main use case is covered and we can close this ticket as resolved.
Updated by livdywan over 3 years ago
- Copied to action #90441: Only set due date on tickets in progress added