action #111506
closedqa-tools: qem-bot - Development results leaked to dashboard size:M
0%
Description
Observation¶
Development group 'pstivanin-security@Server-DVD-Updates' results synced to qem dashboard
We already filter out development jobs in https://github.com/openSUSE/qem-bot/blob/master/openqabot/aggrsync.py#L53-L68 in case of aggregates or https://github.com/openSUSE/qem-bot/blob/master/openqabot/incsyncres.py#L48-L61 but today pstivanin-security leaked to qem-dashboard in http://dashboard.qam.suse.de/incident/24199 when it shouldn't show it.
Acceptance criteria¶
- AC1: Development jobs should not be part of incident approval
- AC2: Dashboard no longer shows development jobs
Suggestions¶
- Don't let the bot submit development jobs to the dashboard
- Prevent duplication in https://github.com/openSUSE/qem-bot/blob/master/openqabot/aggrsync.py#L53-L68 and https://github.com/openSUSE/qem-bot/blob/master/openqabot/incsyncres.py#L48-L61
- Also exclude jobs that are part of any parent job group regardless of the job group names
Further notes¶
- A "development job" is a job in a job group or in a parent job group where the name contains "Development".
Updated by mgrifalconi almost 2 years ago
After seeing the code used to filter out development job groups I have a question:
Isn't possible to get a list of al job groups in the "development" parent group, instead of filtering for job group name keywords?
To my understanding, developers know that the parent group is meant for development and not that some keywords will do the trick, but I might be the only one not knowing it.
Updated by okurz almost 2 years ago
- Tags set to reactive work
- Priority changed from Normal to High
- Target version set to Ready
Well, it was started with just having job groups with "development" in the name and at that time parent groups didn't even exist yet.
But, yes, looking into the parent group as an alternative sounds like the way to go.
Updated by mkittler almost 2 years ago
- Subject changed from qa-tools: qem-bot - Development results leaked to dashboard to qa-tools: qem-bot - Development results leaked to dashboard size:M
- Description updated (diff)
- Status changed from New to Workable
Updated by okurz almost 2 years ago
- Description updated (diff)
- Target version deleted (
Ready)
Updated by osukup almost 2 years ago
- Status changed from Workable to In Progress
- Assignee set to osukup
Updated by osukup almost 2 years ago
unfortunately openqa api call jobs/id returns only group and group_id but nothing about the parent group, so amount of API calls to openQA within bot is slightly higher now
Updated by livdywan almost 2 years ago
okurz wrote:
Well, it was started with just having job groups with "development" in the name
The code seems to recognize groups with names containing Devel, Test and Timo as well as specifically Development.
Updated by osukup almost 2 years ago
- Status changed from In Progress to Feedback
cdywan wrote:
okurz wrote:
Well, it was started with just having job groups with "development" in the name
The code seems to recognize groups with names containing
Devel,TestandTimoas well as specificallyDevelopment.
now it also checks the parent group ..., PR merged
Updated by livdywan almost 2 years ago
mgrifalconi wrote:
Isn't possible to get a list of al job groups in the "development" parent group, instead of filtering for job group name keywords?
To my understanding, developers know that the parent group is meant for development and not that some keywords will do the trick, but I might be the only one not knowing it.
I provided another PR to drop the keyword-based filtering since that's how I read your comment but I guess it's not clear what the expected workflow is.
With Ondřej's change we have both, the parent group as well as the filtering based on keywords in the name of the job group.
Updated by mgrifalconi almost 2 years ago
Hello, I think it is happening again. With "Leap 15.4" and "Maintenance: Leap 15.3". Please see https://suse.slack.com/archives/C02D16TCP99/p1654676089877079 and also http://dashboard.qam.suse.de/blocked by searching for "Leap" in the page.
Updated by livdywan almost 2 years ago
mgrifalconi wrote:
Hello, I think it is happening again. With "Leap 15.4" and "Maintenance: Leap 15.3". Please see https://suse.slack.com/archives/C02D16TCP99/p1654676089877079 and also http://dashboard.qam.suse.de/blocked by searching for "Leap" in the page.
https://github.com/openSUSE/qem-bot/pull/34 is the refactor claiming to handle parent groups as well. It didn't add any unit test coverage so I suggest we get this unit-tested first and identify the fix that way.
Updated by osukup almost 2 years ago
- Status changed from Feedback to In Progress
found problem in filter code, "name" keys has different meaning ... so using magic number is only way
Updated by okurz almost 2 years ago
osukup wrote:
found problem in filter code, "name" keys has different meaning ... so using magic number is only way
Better make it a "configuration value". It's only a "magic number" if there is no proper explanation to what it means :) And, no, a comment in source code does not count :)
Updated by openqa_review almost 2 years ago
- Due date set to 2022-06-23
Setting due date based on mean cycle time of SUSE QE Tools
Updated by osukup almost 2 years ago
okurz wrote:
osukup wrote:
found problem in filter code, "name" keys has different meaning ... so using magic number is only way
Better make it a "configuration value". It's only a "magic number" if there is no proper explanation to what it means :) And, no, a comment in source code does not count :)
now is as one initialized variable in openqabot/__init__.py
Updated by osukup almost 2 years ago
- Status changed from Feedback to Resolved
should filter out develepment result correctly now
Updated by livdywan almost 2 years ago
osukup wrote:
should filter out develepment result correctly now
For the record: https://github.com/openSUSE/qem-bot/pull/40