Reallocate Job Priorities about ros_buildfarm_config HOT 3 CLOSED

We have the following job categories in priority order:

• PR jobs
• nightly CI jobs
• dev jobs
• source deb jobs
• binary deb jobs
  • amd64 and aarch64
  • armhf

The overall order of these categories makes sense imo - a very brief rational summary: we want the fastest turn around on PR jobs, followed by nightly CI and dev jobs (since developers and contributors need to the see the latest state asap). Source deb jobs should happen before binary deb jobs and armhf is lowest priority (also taking the longest).

Each category contains jobs for each ROS 2 distro - atm 4 active distros. Newer distros have a higher priority than older distros (the rational being that they have more changes and more developers are interested in seeing them turnover).

The exception atm is rolling which has a lower priority than all other distros. As pointed out before I think this should be changed. E.g. the majority of PRs is targeting rolling and there the turn around for those should be of highest priority. The same argument holds true for the other categories - rolling is expected to change the most (same as comparing Foxy to Eloquent) and should therefore be handled before e.g. Foxy.

The ros_buildfarm package has hard coded jobs up to 35 and the upper limit is 100 which leaves 60ish priority levels to choose from. With 5 (or 6 categories if you count the architecture specific binary deb jobs separately) that still leave 10 priority levels for each category.

Therefore I am proposing the following changes:

• each category get a block of 10 per category (e.g. 40-49, 50-59, etc.) and
• in each category:
  • rolling gets x0
  • foxy get x7
  • eloquent get x8
  • dashing get x9

That will leave 6 priorities empty for future ROS 2 distros without collisions. Based on the current plan of releasing a new ROS 2 distro once a year that should give us plenty of room.

from ros_buildfarm_config.

@dirk-thomas Your proposal SGTM 👍

What blocks do you think the job categories should get? Maybe leave available blocks at each end, e.g.

PR (2x)
CI (3x)
dev (4x)
source deb (5x)
binary deb amd64 / aarch64 (6x)
binary deb armhf (7x)

from ros_buildfarm_config.

What blocks do you think the job categories should get?

PR (2x)

The "free" range only starts at 40 so I would start there which will go all the way to 9x. See #110 for the actual numbers (before and after).

from ros_buildfarm_config.