action #128399
closed
[bot-ng] Scheduler uses metadata from previous day size:M
Added by dzedro about 1 year ago.
Updated 11 months ago.
Description
[bot-ng] Scheduler uses metadata from previous day
Motivation¶
The bot-ng scheduler could use latest metadata.
If it's a big problem to do, then we can just wait,
but it would be nice to don't have this delay, especially for Incidents.
$ rpm --query qam-metadata-openqabot
qam-metadata-openqabot-20230427-qam.1.1.noarch
Acceptance criteria¶
- AC1: qam-metadata-openqabot is synchronously provided "quick enough" based on consumer requirements
Suggestions¶
- Crosscheck with dzedro about requirements. Do we actually need to have it quicker or just "it would be nice"?
- Check the current trigger: If it's time-based consider using event-based triggering and ensure the metadata is packaged and provided in a quicker way
- Consider switching to using the git metadata version directly (in an efficient way) unless we strongly rely on package based features
- Project changed from openQA Project to QA
- Category deleted (
Feature requests)
- Target version set to Ready
jbaier_cz wrote:
Additionaly, https://gitlab.suse.de/qa-maintenance/bot-ng/-/jobs/1539447 already uses the new metadata package which was created like 80 minutes ago. It does not feel like a big delay to me.
I didn't know how often is the package build, I thought it's like once per day.
Only thing I think of is can't scheduler use github directly instead of waiting for IBS and package ?
dzedro wrote:
I didn't know how often is the package build, I thought it's like once per day.
It's build on every change in the corresponding metadata repository.
Only thing I think of is can't scheduler use github directly instead of waiting for IBS and package ?
It would be Gitlab, assuming you mean metadata repository. Then every bot pipeline would need to clone the repository and basically duplicate all steps from the package build (running some python scripts and copying results to the corresponding paths for the bot, if I recall correctly).
It's doable, but a step in an opposite direction in my opinion.
jbaier_cz wrote:
dzedro wrote:
I didn't know how often is the package build, I thought it's like once per day.
It's build on every change in the corresponding metadata repository.
Only thing I think of is can't scheduler use github directly instead of waiting for IBS and package ?
It would be Gitlab, assuming you mean metadata repository. Then every bot pipeline would need to clone the repository and basically duplicate all steps from the package build (running some python scripts and copying results to the corresponding paths for the bot, if I recall correctly).
It's doable, but a step in an opposite direction in my opinion.
Yes, building package is not required just having latest metadata.
It's fine if it stays as it is, I already know there is some delay, can be bigger if ibs is loaded.
Thank you.
- Subject changed from [bot-ng] Scheduler uses metadata from previous day to [bot-ng] Scheduler uses metadata from previous day size:M
- Description updated (diff)
- Status changed from New to Workable
- Status changed from Workable to Resolved
All is solved but today is scheduler still using qam-metadata-openqabot-20230531-qam.5.2.noarch ...
- Assignee set to jbaier_cz
dzedro wrote:
All is solved but today is scheduler still using qam-metadata-openqabot-20230531-qam.5.2.noarch ...
Sure, that's the most recent version published. Newer version cannot be published, because someone broke the QA:Maintenance repository setup in IBS. That is another issue which I can try to fix.
jbaier_cz wrote:
dzedro wrote:
All is solved but today is scheduler still using qam-metadata-openqabot-20230531-qam.5.2.noarch ...
Sure, that's the most recent version published. Newer version cannot be published, because someone broke the QA:Maintenance repository setup in IBS. That is another issue which I can try to fix.
I have seen the slack message, Thank you!
Just for the record, the issue is caused by some problem in OBS/IBS, the buildops team is aware of the issue and is working on it. There is currently nothing we can do.
Also available in: Atom
PDF