Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Parametrized Copr builds #2610

Open
mrc0mmand opened this issue Oct 30, 2024 · 1 comment
Open

[RFC] Parametrized Copr builds #2610

mrc0mmand opened this issue Oct 30, 2024 · 1 comment
Assignees
Labels
area/copr Related to the integration with copr.fedorainfracloud.org/ complexity/single-task Regular task, should be done within days. gain/high This brings a lot of value to (not strictly a lot of) users. impact/low This issue impacts only a few users. kind/feature New feature or a request for enhancement.

Comments

@mrc0mmand
Copy link

mrc0mmand commented Oct 30, 2024

Hey!

While using Packit in various upstream projects a one potentially useful feature came to mind that's (AFAIK) currently not possible with Packit: do multiple Copr builds with different parameters and run the same tests on all such builds.

The main use case (from my side) is to do both a regular build and a sanitized build (using ASan/UBSan/etc.) in a single PR and then execute the same set of tests on both builds.

The easiest way I could think of right now would be probably allowing passing custom arguments to rpmbuild (if that's even possible from Packit's side), i.e. something like:

jobs:
- job: copr_build
  trigger: pull_request
  rpmbuild_params: --define "sanitized_build 1"
  targets:
    - fedora-stable
    - centos-stream-8-x86_64

Where the respective spec file would need to be adjusted to account for the just defined option (or maybe even something like --define "build_cflags %{__build_flags_lang_c} %{?_distro_extra_cflags} -fsanitize=address,undefined" would do, which wouldn't require spec file modifications, but it's way less obvious). But that's just an initial idea, there's probably a better way to achieve this.

Would something like this make sense in Packit or be even possible?

(/cc @evverx)

@evverx
Copy link

evverx commented Oct 30, 2024

a regular build and a sanitized build (using ASan/UBSan/etc.) in a single PR and then execute the same set of tests on both builds.

I'd add Valgrind to this list :-)

I think at some point I tried to figure out how to move stuff run on GHActions to Packit and I'm not sure it's possible. I guess it should be possible to cover, say, unit tests where it's relatively easy to switch compilers/compiler options/environment variables but with integration tests where unit files have to be edited and coredumps/ASan/UBSan/Valgrind backtraces have to be collected I'm not sure how it can be achieved. I think partly it has something to do with the fact that Packit should test packages but at the same time specfiles get in the way when test builds and test environments differ from the normal Fedora environment significantly. (For the same reason I don't use the mkosi systemd testing infrastructure much because it's kind of annoying to override the distro defaults by flipping various flags to enable various features to cover more code. Just to clarify I'm not saying it's bad. It's just that its goal is different)

That being said I think it would be really great if it was possible to somehow make it possible to do dbus-fuzzer/dfuzzer#21 with, say, polkit polkit-org/polkit#515 with ASan/UBSan and all those things.

@mfocko mfocko added kind/feature New feature or a request for enhancement. area/copr Related to the integration with copr.fedorainfracloud.org/ complexity/single-task Regular task, should be done within days. impact/low This issue impacts only a few users. gain/high This brings a lot of value to (not strictly a lot of) users. labels Oct 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/copr Related to the integration with copr.fedorainfracloud.org/ complexity/single-task Regular task, should be done within days. gain/high This brings a lot of value to (not strictly a lot of) users. impact/low This issue impacts only a few users. kind/feature New feature or a request for enhancement.
Projects
Status: new
Development

No branches or pull requests

4 participants