action #77956
[openQABot] openQA supports showing parent group name when getting a job details
0%
Description
Motivation¶
OpenQA supports showing parent group name when getting a job's details, and the pr has been deployed on o3, will be deployed on OSD this week.
If a job belongs to a parent job group, the parent job group name and id will been shown.
such as:
openqa-cli api --o3 jobs/1470855 --pretty { "job" : { ... .... "group" : "Development Tumbleweed", "group_id" : 38, "has_parents" : 0, "id" : 1470855, "name" : "opensuse-Tumbleweed-DVD-x86_64-Build20201113-create_hdd_textmode_ext4@uefi", "parent_group" : "Development", "parent_group_id" : 6, },
Acceptance criteria¶
- AC1: All jobs below the parent job group "Development" are ignored regardless if "Development" is in the name of the child job group itself
Suggestion¶
maybe we could use the parent group name to check if a job belongs to Development
in https://gitlab.suse.de/qa-maintenance/openQABot/-/blob/master/openqabot/utils.py#L127
Related issues
History
#1
Updated by okurz over 2 years ago
- Related to action #77215: In jobs API data reference a parent job group name as well added
#2
Updated by okurz over 2 years ago
Added osukup as watcher
osukup could be interesting for you
#3
Updated by tjyrinki_suse over 2 years ago
- Project changed from QAM to openQA Tests
- Target version changed from QAM tests - future to Ready
openQABot is handled by the new joint QE Tools team.
#4
Updated by okurz over 2 years ago
- Tags set to openQABot, python
- Subject changed from [openQABot]OpenQA supports showing parent group name when getting a job details to [openQABot] openQA supports showing parent group name when getting a job details
- Description updated (diff)
- Category set to Infrastructure
- Status changed from New to Workable
correct, thx
#5
Updated by mkittler over 2 years ago
I would have almost picked up this ticket but the repository doesn't contain any instructions how to run an test this bot locally. There's not even an explanation what this bot is supposed to do.
#7
Updated by cdywan over 2 years ago
Since with #80194 the code might be quite different, I'm setting this ticket to Blocked after discussing it with @osukup. The use case is still valid but it wouldn't make much sense to work on right now.
#8
Updated by cdywan over 2 years ago
- Status changed from Workable to Blocked
#9
Updated by okurz over 2 years ago
- Status changed from Blocked to New
- Priority changed from Normal to Low
- Target version changed from Ready to future
makes sense but we should have only "Blocked" with an assignee. However in this case I think we can go with "New"+"Low"+"future" and not have it on the backlog for "right now" at all :)