Move build-mechnical to 04:00 UTC #1231
Conversation
The goal being to ensure build-mechnical and the downstream build-node-image jobs finish before we typically see content changed, which tends to be EMEA to US East AM hours. In situations where we're hoping to pick up late changes this may cause delays, if that becomes an issue I'd propose we consider adding a second run at 17:00 UTC (EDT 12:00 + 5hr), but ideally we'd limit that to only versions where we hope to have rapid turn around. Those versions would be 9.6 today, then 9.6, 9.8, and 10.2 starting approximately May 2026.
|
This time was originally chosen (1da5e54) based on when Fedora composes would finish for |
why? wouldn't you want to wait until after new content was available? |
|
/hold |
|
We could make the cron spec a global pipecfg knob if it comes to it. But that said, if we want perfect timing, obviously it's possible to trigger a job whenever content changes. I think ART today watches RHEL repos already, and also knows how to trigger jobs, so they're well-positioned for this. |
|
All of the last 10 rhel-9.6 jobs showing up in Jenkins were triggered by timer or me. I can check to see why we're not getting builds triggered on change by ART for at least rhel-9.6.
The RHCOS jenkins doesn't seem to have any Fedora related jobs, I assume some other pipeline instance is running the same jobs against Fedora?
I'm OK with any timing that we think yields less failed builds and content that's no more than 24 hours old as of Wednesday at 16:00 UTC. Where RHEL builds associated with GA versions of OCP are the highest priority within the set both in terms of success and freshness. |
yeah. we have an upstream pipeline, but share the same code that powers the pipeline. I'm not opposed to setting the times based on the pipeline, just trying understand the requirements. |
To be clear I wasn't implying that ART is doing this today. But that it could. |
I'd actually prefer ART didn't. Since RHEL content shouldn't really change more than once a day, is it really needed? |
Don't we today already trigger once a day? ISTM the ask here is to have better timing wrt RHEL, not necessarily have more builds. (This would actually be a reduction in builds if RHEL content changes less often than that... though I'm not sure in practice how often that happens.) But I guess if we go this way, we should probably also ask ART to cap the rate as well in case it sometimes churns faster for some reason. |
The goal being to ensure build-mechnical and the downstream build-node-image jobs finish before we typically see content changed, which tends to be EMEA to US East AM hours. In situations where we're hoping to pick up late changes this may cause delays, if that becomes an issue I'd propose we consider adding a second run at 17:00 UTC (EDT 12:00 + 5hr), but ideally we'd limit that to only versions where we hope to have rapid turn around. Those versions would be 9.6 today, then 9.6, 9.8, and 10.2 starting approximately May 2026.