Generate the blocked releases page against the previous LTS.

[clalancette]

Note that this requires a change in https://raw.githubusercontent.com/ros-infrastructure/ros_buildfarm_config/production/index.yaml to add a tags list to each distribution (example). Once that is in place, the below will go looking for the previous distribution marked as lts, and if that is not found, default to the immediately preceding distribution.

Signed-off-by: Chris Lalancette [email protected]

[dirk-thomas]

Maybe inverting the logic / configuration here would be better. Currently the code generates all kind of combinations. Instead we could have a config file which enumerates the combinations we actually want. That would avoid adding any kind of tags or knowledge about what an "LTS" is and get rid of rarely used combinations too.

[clalancette]

Maybe inverting the logic / configuration here would be better. Currently the code generates all kind of combinations. Instead we could have a config file which enumerates the combinations we actually want. That would avoid adding any kind of tags or knowledge about what an "LTS" is and get rid of rarely used combinations too.

That's true, but the downside is that we would then have to have yet another configuration file that needs to be updated when a new distribution is added. There are already a few of them, so I'm not sure adding another one is the best idea.

A hybrid of your approach and mine is to add a new field to the buildfarm_config which defines which distro to compare against (compare distro or some such). That way it is just adding one more field when adding a new distro, and if it isn't specified, we could fall back to just using the "last" distro. What do you think about that proposal?

[dirk-thomas]

the downside is that we would then have to have yet another configuration file that needs to be updated when a new distribution is added. There are already a few of them, so I'm not sure adding another one is the best idea.

That should not take more than a minute and seems to be "cheaper" than to maintain this additional logic and provides more fine grain control what combinations are actually being generated.

A hybrid of your approach and mine is to add a new field to the buildfarm_config which defines which distro to compare against (compare distro or some such). That way it is just adding one more field when adding a new distro, and if it isn't specified, we could fall back to just using the "last" distro. What do you think about that proposal?

Where exactly do you propose to put these information. "A new field to the buildfarm_config" is not very precise. Which exact build file (and why there)?

[clalancette]

That should not take more than a minute and seems to be "cheaper" than to maintain this additional logic and provides more fine grain control what combinations are actually being generated.

Right, no one addition to the process is very expensive. It is more of a "death by a thousand cuts" problem here; the Kick-off checklist for a new ROS distro is already quite long. While I wouldn't say that keeping that list shorter is a primary goal, anything we can do to keep it down is helpful.

Where exactly do you propose to put these information. "A new field to the buildfarm_config" is not very precise. Which exact build file (and why there)?

I propose adding it to https://raw.githubusercontent.com/ros-infrastructure/ros_buildfarm_config/production/index.yaml , as a new field per distribution. So, for instance, the melodic block there would change to something like:

  melodic:
    doc_builds:
      default: melodic/doc-build.yaml
      released-packages-without-doc-job: melodic/doc-released-build.yaml
    notification_emails:
    - [email protected]
    - [email protected]
    release_builds:
      default: melodic/release-build.yaml
      ds: melodic/release-stretch-build.yaml
      dsv8: melodic/release-stretch-arm64-build.yaml
      ubhf: melodic/release-armhf-build.yaml
      ubv8: melodic/release-arm64-build.yaml
    source_builds:
      default: melodic/source-build.yaml
      ds: melodic/source-stretch-build.yaml
    package_compare: kinetic

Where package_compare is the new field. I think it makes sense here as it is configuration information for the buildfarm, which is where the status_page job is run.

[mikaelarguedas]

In this example, is package_compare used for the blocked release page ? the compare status page ? both ?

[dirk-thomas]

Since the implementation in this repo is highly compartmentalized (each job type has a separate build file) I would rather not break that design for the status pages. Instead I think a configuration file for status pages (which need that) should be created and also documented as such.

[dirk-thomas]

Closing due to inactivity. Please feel free to comment on the closed issue and the ticket can be reopened if necessary.