Red Hat Konflux update osc-podvm-payload

[red-hat-konflux]

Pipelines as Code configuration proposal

To start the PipelineRun, add a new comment with content /ok-to-test

For more detailed information about running a PipelineRun, please refer to Pipelines as Code documentation Running the PipelineRun

To customize the proposed PipelineRuns after merge, please refer to Build Pipeline customization

[littlejawa]

/ok-to-test

[littlejawa]

/retest

[littlejawa]

/retest

[littlejawa]

/retest

[spotlesstofu]

As anticipated on Slack, my proposal here is to set the guest-components submodule at f9aa889.

This allows to remove the few commits that depend on a newer Rust version (LazyLock) and the build succeeds on UBI9.

[littlejawa]

As anticipated on Slack, my proposal here is to set the guest-components submodule at f9aa889.
This allows to remove the few commits that depend on a newer Rust version (LazyLock) and the build succeeds on UBI9.

Yes. I tend to agree.

A bit more context (for future reference):
Initially, when we found that the rust version we need was not available in our builder, we discussed this possibility.
We ruled it out, because we want to use a stable tag when we build, and want to avoid changing anything if we don't need to.
We decided to ask for a new build root on the CPaaS side, managed to get it, and now we can build the guest-components v0.11 code with rust 1.84 on CPaaS.

Now here with Konflux:

• we don't have access to the CPaaS build root
• we are not supposed to use the centos:stream9 image as a builder
• we should not install a different toolchain manually (e.g: using rustup)

Based on this, I think we can consider removing the couple commits that introduce the dependency to rust 1.80.

These commits are changing the code to use a new rust stdlib lock mecanism (LazyLock), in place of the one that we were using before.
Removing them should not have an impact on the features we provide.

I will make that change and see how it goes. It will impact only the Konflux build anyway.