After updating the Nodesets, running make render should do the trick. Make sure that fedora-zuul-jobs-config and fedora-zuul-jobs are checked-out in the parent directory.

About the latest definitions, we could bump them to f36, and you can use this website to check what jobs are using them:

• https://softwarefactory-project.io/weeder/tenant/fedora/object/nodeset/fedora-latest-container
• https://softwarefactory-project.io/weeder/tenant/fedora/object/nodeset/fedora-latest-vm

OK, filed https://pagure.io/fedora-project-config/pull-request/211 and https://pagure.io/fedora-zuul-jobs/pull-request/156 .

I did notice a lot of jobs in fedora-zuul-jobs-config are set to run on F34. They probably should all be updated to at least F35 since F34 is EOL.

Shouldn't a person or bot be tasked to check and update these things with every new Fedora release?

Hi Adam,

Thanks you for the heads-up :) ! and the patches.

So first we need the zuul-worker-f36 to be available to Zuul/Nodepool.
I've opened those changes:
- https://softwarefactory-project.io/r/c/containers/+/25731/
- https://softwarefactory-project.io/r/c/config/+/25732

Then, regarding your patches, I think that in 211 we should not change the "latest-version" let binding right now for some reasons:
- Fedora Zuul CI don't use the fedora-latest-container and fedora-latest-vm nodesets
- Those nodesets are used by projects hosted on pagure.io under the fedora-qa/ namespace (as stated by zuul-weeder)
- We might break project CI that use those nodesets if we merge

So, could you rework your patches to only add the Fedora-36-Container by removing the change to "latest-version" ?

I think we should even remove that "latest" concept and let project maintainers select the nodeset/label they we want and when they want. I keep that in my TODO list.

Once 25731, 25732, 211 (updated), 156 (updated) are merged then we can move forward and update linter, rpminspect, tmt/sti jobs to use f36 as base container via followup patches.

That makes no sense to me.

The whole point of having a latest is so I can specify that in my project and not have to "select the nodeset/label they we want" every six months.

All the projects but one (copr's csdiff-pylint) in the weeder lists are actually mine, and this is precisely why I picked them. I want those jobs to always run on 'latest stable Fedora', without me having to remember every six months to update a version number (and probably forget to, and wind up running my tests on EOL code). That was the behaviour I expected when I picked 'latest'. Me filing this bug is me being sad to discover that isn't what happened.

To me this is obviously what 'latest' means, and anyone who picks it would understand what they're getting. If you don't want the system to give you 'latest Fedora', don't pick the nodeset with 'latest' in the name. Seems simple.

I agree with Adam, I think it is expected that latest follows the latest Fedora. We can open test PR to check a job using latest is compatible with an update, but that should not be necessary.

Ok yes that make sense and I understand that's the intended behavior.

The zuul-worker-f36 label is now available so I've merged your changes.

Let us know if you see any issue on jobs using "fedora-latest-container" nodeset.

I close the issue. Please re-open if needed.