Here is the dhall definition:

• https://pagure.io/fedora-project-config/pull-request/325

Here are the auto-generated PRs:

• https://pagure.io/fedora-zuul-jobs/pull-request/189
• https://pagure.io/fedora-zuul-jobs-config/pull-request/191

Could change like this be integrated into some releng workflow they follow with EOLs and branching?

BTW assuming that the lines such as + let latest-version = "40" and the let default_nodeset = Nodesets.getName Nodesets.Type.Fedora-40-Container are those which define the Fedora version used for e.g. rpmlint.

Yes it is and in the rendered file we now have https://pagure.io/fork/fbo/fedora-zuul-jobs/blob/bfbaa156848e047bfee037361bed5374dc0861f2/f/zuul.d/jobs.yaml#_251

Regarding the other question that is for sure possible but not easy. We can have some json files as input to defines supported branches and versions then converting them to dhall can be done part of the process (Makefile) then we will get a rederring according to the input data.

Then we could have a CI job to propose the PRs for review.

We need a CI job (new job) to automate the CI template (dhall) that create the CI configurations (fedora-zuul-jobs) of the CI jobs (fedora-ci). That's quite the matroschka doll :grinning:.

Edit: ah wait, there is one more layer because it can then call the tmt jobs inside

Regarding the other question that is for sure possible but not easy.

My very naive idea is just "create ticket requesting an update", which could be later automated.

I know that everybody knows that there is new Fedora branched or EOL. OTOH, for scenarios which led to this ticket, there is nothing to refer to. IOW if I wondered why old rpmlint is used, then I'd likely find "Please remove Fedora 38 due to its EOL" ticket.

@bookwar @mvadkert FYI let me know when I can proceed with the merge of this ?

I've merged the changes.