fedora-coreos-pipeline icon indicating copy to clipboard operation
fedora-coreos-pipeline copied to clipboard

jobs/build-development: make development streams build daily

Open dustymabe opened this issue 1 year ago • 6 comments

Over time I'm thinking the build on every push to the git repo is a bit heavy. Often times the changes will be insignificant to warrant building, testing, and pushing all that we do. On the other hand, if there is a change we want we can easily click a button and start a build if we don't want to wait.

dustymabe avatar Mar 26 '24 19:03 dustymabe

This ticket is meant more to be a discussion about the change. If we agree we can merge this, but let's have the conversation first.

dustymabe avatar Mar 26 '24 19:03 dustymabe

This is about testing-devel and next-devel builds right? I already though that was a nightly build and not a per push one so I'm +1 if my understanding is correct.

travier avatar Mar 28 '24 14:03 travier

This is about testing-devel and next-devel builds right?

correct

dustymabe avatar Mar 28 '24 15:03 dustymabe

Had a chat with Dusty about this. Things we mentioned:

  • we're currently not building multiple times per day very often
  • part of that though is probably due to Dusty manually intervening with the build job
  • until we have multi-arch CI, this would mean that multi-arch bugs in newly introduced code/tests will not be found until e.g. the next day, vs a few hours later
  • on promotion day, the latest testing-devel that we'd promote might not have been built and tested at all yet
  • a good compromise would be to leave it to trigger on git pushes, but still force a rate-limit of e.g. 20h in the job itself

jlebon avatar Mar 28 '24 20:03 jlebon

a good compromise would be to leave it to trigger on git pushes, but still force a rate-limit of e.g. 20h in the job itself

@jlebon just to make sure i understand that correctly, you mean the job wouldn't start if it haven't been idle for at least 20 hours ?

jbtrystram avatar Apr 02 '24 08:04 jbtrystram

a good compromise would be to leave it to trigger on git pushes, but still force a rate-limit of e.g. 20h in the job itself

@jlebon just to make sure i understand that correctly, you mean the job wouldn't start if it haven't been idle for at least 20 hours ?

When the job starts, it would check when the last build on that stream was. If it's less than X hours ago, then we no-op.

jlebon avatar Apr 05 '24 14:04 jlebon