action #77956
open[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
Updated by okurz about 4 years ago
- Related to action #77215: In jobs API data reference a parent job group name as well added
Updated by okurz about 4 years ago
Added osukup as watcher
@osukup could be interesting for you
Updated by tjyrinki_suse almost 4 years ago
- Project changed from 119 to openQA Tests
- Target version changed from QAM tests - future to Ready
openQABot is handled by the new joint QE Tools team.
Updated by okurz almost 4 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
Updated by mkittler almost 4 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.
Updated by livdywan almost 4 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.
Updated by okurz almost 4 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 :)