jobs/build-development: make development streams build daily

[dustymabe]

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]

I imagine this timer wouldn't coincide/run at exactly the same time each day as build-mechanical right? Otherwise we'd want to do something different.

[jbtrystram]

Jenkins have a built-in feature to randomize the start hours while respecting the periodicity, when you write H
https://www.jenkins.io/doc/book/pipeline/syntax/#cron-syntax

So from my understanding this should be good

[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.

[travier]

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.

[dustymabe]

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

correct

[jlebon]

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

[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 ?

[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 ?

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.