| Message ID | 20241007171717.1436982-1-pbonzini@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | dockerfiles, gitlab-ci: add CI job using nightly Rust | expand |
On Mon, Oct 07, 2024 at 07:17:11PM +0200, Paolo Bonzini wrote: > Right now only Fedora 39 and 40 (with updates) are able to compile > QEMU with Rust enabled. Full CI enablement requires further work to > reduce the minimum supported version of the compiler, and is not a > requirement until Rust is turned on by default. > > Since a CI job based on nightly Rust will be needed later on, to > integrate clippy and have a heads-up on future clippy warnings, > adjust QEMU's 'refresh' script to customize a Fedora 40 dockerfile > with trailing text that installs nightly Rust and compiles the > latest bindgen. A matching CI job, using --enable-rust, ensures > that the toolchain is installed correctly by the Dockerfile and > that QEMU builds with Rust enabled on at least one platform. I think that in addition to the nightly job, the mappings.yml should add rust toolchain, and have a 'system-fedora-rust' job, since you say that Fedora 40 should already satisfy the min version requirement without needing nightly there. Even though the mappings.yml addition will add rust to /all/ containers this is fine - a perhaps even a good thing - as with any dep we have, it shows that QEMU does not mistakenly try to enable & use a feature on a rust version that is too old to work - it reflects that most developer envs will have rustc present, even when its too old for QEMU to use. > > Suggested-by: Daniel P. Berrangé <berrange@redhat.com> > Cc: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> > Cc: Alex Bennée <alex.bennee@linaro.org> > Based-on: <cover.1727961605.git.manos.pitsidianakis@linaro.org> > > Paolo Bonzini (2): > dockerfiles: add a Dockerfile using a nightly Rust toolchain > gitlab-ci: add Rust-enabled CI job > > .gitlab-ci.d/buildtest.yml | 13 ++ > .gitlab-ci.d/containers.yml | 6 + > .../dockerfiles/fedora-rust-nightly.docker | 173 ++++++++++++++++++ > tests/lcitool/refresh | 26 +++ > 4 files changed, 218 insertions(+) > create mode 100644 tests/docker/dockerfiles/fedora-rust-nightly.docker > > -- > 2.46.1 > With regards, Daniel
On Mon, Oct 7, 2024 at 8:19 PM Daniel P. Berrangé <berrange@redhat.com> wrote: > I think that in addition to the nightly job, the mappings.yml should > add rust toolchain, and have a 'system-fedora-rust' job, since you > say that Fedora 40 should already satisfy the min version requirement > without needing nightly there. > > Even though the mappings.yml addition will add rust to /all/ containers > this is fine - a perhaps even a good thing - as with any dep we have, it > shows that QEMU does not mistakenly try to enable & use a feature on a > rust version that is too old to work - it reflects that most developer > envs will have rustc present, even when its too old for QEMU to use. Ok, I'll work on adding bindgen support to lcitool and then do this as a separate submission. (BTW the fact that Fedora 40 works wasn't really a goal of Manos's first submission; it just happens to have new-enough packages). Paolo
On Tue, Oct 08, 2024 at 11:03:47AM +0200, Paolo Bonzini wrote: > On Mon, Oct 7, 2024 at 8:19 PM Daniel P. Berrangé <berrange@redhat.com> wrote: > > I think that in addition to the nightly job, the mappings.yml should > > add rust toolchain, and have a 'system-fedora-rust' job, since you > > say that Fedora 40 should already satisfy the min version requirement > > without needing nightly there. > > > > Even though the mappings.yml addition will add rust to /all/ containers > > this is fine - a perhaps even a good thing - as with any dep we have, it > > shows that QEMU does not mistakenly try to enable & use a feature on a > > rust version that is too old to work - it reflects that most developer > > envs will have rustc present, even when its too old for QEMU to use. > > Ok, I'll work on adding bindgen support to lcitool and then do this as > a separate submission. FYI, lcitool already has a package mapping for 'bindgen' defined as Alex added that for QEMU's benefit a few months back :-) With regards, Daniel
On Tue, Oct 8, 2024 at 11:20 AM Daniel P. Berrangé <berrange@redhat.com> wrote: > On Tue, Oct 08, 2024 at 11:03:47AM +0200, Paolo Bonzini wrote: > > Ok, I'll work on adding bindgen support to lcitool and then do this as > > a separate submission. > > FYI, lcitool already has a package mapping for 'bindgen' defined as Alex > added that for QEMU's benefit a few months back :-) Hmm, it's missing on SLES15. I wonder if we need to add support for cargo install, following the model I used in this series. Paolo
On Tue, Oct 08, 2024 at 11:45:49AM +0200, Paolo Bonzini wrote: > On Tue, Oct 8, 2024 at 11:20 AM Daniel P. Berrangé <berrange@redhat.com> wrote: > > On Tue, Oct 08, 2024 at 11:03:47AM +0200, Paolo Bonzini wrote: > > > Ok, I'll work on adding bindgen support to lcitool and then do this as > > > a separate submission. > > > > FYI, lcitool already has a package mapping for 'bindgen' defined as Alex > > added that for QEMU's benefit a few months back :-) > > Hmm, it's missing on SLES15. I wonder if we need to add support for > cargo install, following the model I used in this series. Yes, that could work as a special case, but we don't need to worry about that until we enable rust by default later. With regards, Daniel