> UNH does not use it much
> as we opt to meet the meson dependency separately in the dpdk-ci
> project's container template engine.
That's a bit of a pity, since we can't update the meson version
automatically as part of the meson update as we do with CIs using the
linux-setup script. Is there some other file that can be in the DPDK main
repo that can contain this details to regular DPDK patches can update the
CI too as part of a meson update?
I think the only way to do that would be to submit a patch alongside for the dpdk ci container template engine:
https://git.dpdk.org/tools/dpdk-ci/tree/containers/README.md. But this would not work very well as dpdk-ci is a separate repo from dpdk, so you can't really package the meson update and the ci update in one patchseries.
So, I guess based on your comments it seems like the best solution is to remove the meson step from the container template engine (Dockerfiles) and run the linux-setup.sh script right before each testrun, which solves the problem you raise about updating dpdk and CI side by side, and solves the main vs LTS issue. And of course it comes with the benefit of making CI processes more common across labs. I had run through this idea with Adam yesterday and we agreed that it would work but decided it was our second favorite option... but I think with the points you are raising it is clear this is the correct route to take.
> It will also require updates to the container template engine, which I
> can get Cody started on tomorrow.
>
> Important note: if relevant to your CI, testing against LTS branches
> must still be done with the 0.53.2 version, so no change relying on
> post 0.53.2 meson feature gets backported.
>
> Okay, full disclosure I don't think this is something we handled the
> last time the meson version got bumped in 2022. So, back then we just
> bumped the meson version for all environments to .53, then did LTS
> testing for 19.11, 20.11, 21.11 from environments running meson .53.
> But, I understand how this is an issue and something we should avoid
> this go around.
> However, it is not ideal to set the meson version "at runtime" for CI
> testing based on the repo under test (mainline and next-* want .57, old
> LTS versions want .53). It would be possible to modify our jenkinsfiles
> (automation scripts) to check the DPDK version, and run pip commands
> resetting the meson version accordingly, at the start of each testing
> job... but I have a couple concerns here with regards to
> stability/maintenance.
I would recommend against using the DPDK version as a guide. However, the
meson version is included in the project options in the meson.build file of
the code. Could you use "grep meson_version meson.build" in a script to
extra the required version info? If it's helpful, we can possibly provide
some sort of compatibility guarantee of the format of this line.
Thanks this seems like another good option (I did not realize we could get this from meson.build) and something we can fall back on if usage of the linux-setup.sh is problematic in any way.
So, we have a different strategy but the timeline should be the same as this is all fairly trivial. Let me know if yall have any concerns.
Cheers.