On 6/21/22 11:48, Clark Boylan wrote:
Hello everyone,
One thing that we end up doing periodically in zuul-jobs is bumping the default version value in roles that install tools/platforms like python, java, go, and so on. When we do this we typically send a two week warning to zuul-announce to be sure users have a chance to update their use of the roles before the value changes under them. Other users have often already explicitly set a default value where they use these roles because they need newer versions of tools.
This has me wondering if it might be more appropriate to stop setting those values in zuul-jobs roles entirely and instead force users of these roles to be explicit about the version they want to use. Then we don't have this ongoing bookkeeping task of bumping things periodically on the zuul-jobs side. As a bonus users are less likely to break if they miss an important email.
Maybe we start doing this with any new roles, and if that works out well formulate a plan to update all of the existing roles? We would need to communicate this change broadly as chance of impact is high. We will also likely need to suggest plans for Zuul installations to accommodate this change. One idea that came up in Matrix is to suggest individual Zuul projects can set these values as project vars.
Curious to hear if others think this is a great idea or a terrible one or something in between.
Clark
I like the idea of removing the defaults from roles and expecting folks to set the values explicitly, and this is a great use case for project vars ("this project [on this branch] uses java 11") or at least job vars if project vars aren't practical due to branch locality. Jobs like "tox-py39" would still provide the value for the role from the job itself.
Basically, we'd be asking everyone to do what they're about to do right now for the java 8->11 transition, but front-loaded at the point of creating jobs and not some random time in the future when we decide to change the default.
-Jim