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

Support building other projects as part of test image #2877

Open
dmnks opened this issue Jan 26, 2024 · 8 comments
Open

Support building other projects as part of test image #2877

dmnks opened this issue Jan 26, 2024 · 8 comments
Assignees
Labels
matryoshkas RFE test Testsuite-related

Comments

@dmnks
Copy link
Contributor

dmnks commented Jan 26, 2024

Sometimes what you want to do is also build a dependency of RPM locally, just like RPM itself, and run the test-suite with that. A prime example being the rpm-sequoia project which is currently using RPM 4.18 (i.e. the previous test-suite version using fakechroot) in their CI, see rpm-software-management/rpm-sequoia#61 for details. Another example would be popt which we also maintain.

As to how this can be facilitated by the test-suite, I'm not sure yet, but it shouldn't be that hard. Basically, we want to allow injecting custom stuff into the test image.

@pmatilai
Copy link
Member

Yep, both rpm-sequoia and popt are something we'd occasionally want to build from sources instead of packaged versions. So this is actually fairly important piece, even if we have managed without it so far.

@dmnks
Copy link
Contributor Author

dmnks commented Jan 26, 2024

Thinking about this for a moment, one simple solution comes to mind:

Allow for using a custom base image (or Dockerfile) for make check.

This way, our test image would be built on top of whatever custom image you've chosen. The only requirement would be for that image to itself be based on the same distro, e.g. the latest Fedora. That means, the project in question (e.g. rpm-sequoia) would have to provide their own Dockerfile that creates a minimal image with the project built from source and installed. To make use of it locally (or in CI), you'd simply set a cmake option in your RPM build that points to the Dockerfile (or just the given Podman/Docker tag). From there, make check would work as normal.

Does this make sense?

In any case, I can create a PoC next week (with rpm-sequoia as the "test subject") to get a better feel for it.

@pmatilai pmatilai removed this from the 4.20.0 milestone Mar 20, 2024
@pmatilai
Copy link
Member

pmatilai commented Mar 20, 2024

Seems I dropped the ball here, sorry. I suppose a custom base image could be handy.
It doesn't scale though, eg in case we'd want to build rpm-sequoia, popt and .. say, elfutils from sources to test a new feature before it's packaged in Fedora.

(dropped the 4.20 milestone as this isn't critical for that particular release)

@dmnks
Copy link
Contributor Author

dmnks commented Apr 25, 2024

I suppose a custom base image could be handy. It doesn't scale though, eg in case we'd want to build rpm-sequoia, popt and .. say, elfutils from sources to test a new feature before it's packaged in Fedora.

Imagine for a moment that the test-suite doesn't run in containers (e.g. it still uses fakechroot). How would you accomplish the above?

@dmnks dmnks removed their assignment Apr 25, 2024
@pmatilai
Copy link
Member

Have local recipes from building from those upstream sources, install in suitable prefix with LD_LIBRARY_PATH. In a word, painfully? 😄

@dmnks
Copy link
Contributor Author

dmnks commented Apr 25, 2024

Thanks for taking the bait, the purpose of the (rhetorical) question was to get us closer to finding a solution 😄

What changes with the new test-suite is that you would do those builds in a container instead of your host, one that's preferably based on the test image. Then, you would run the test-suite manually from that container or commit the container as the "new" test image and run it with make check from the host as usual.

@dmnks
Copy link
Contributor Author

dmnks commented Apr 25, 2024

Put differently, the building workflow itself doesn't have to change, you only do it in a container vs. natively. Of course, this enables us to have declarative recipes for these builds (i.e. Dockerfiles) which is what I alluded to above.

@dmnks dmnks self-assigned this Apr 25, 2024
@dmnks
Copy link
Contributor Author

dmnks commented Apr 25, 2024

Thing is, you still need to manually bother with containers and images. What we need here is an easy way to integrate this so you don't need to remember "oh, I first need to run a container, then commit it, blah blah".

One way perhaps is to use Toolbx. We just need to integrate make check into it so that you can run it from a Toolbx container directly. I've attempted this with (the now closed) #2830 but I'm planning on submitting a new version of that PR, so that could help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
matryoshkas RFE test Testsuite-related
Projects
Status: Todo
Development

No branches or pull requests

2 participants