test: add test for subscribed content#391
Conversation
d1f9e64 to
5a972a1
Compare
test/test_rhel.py
Outdated
| "manifest", | ||
| "qcow2", | ||
| "--distro", "rhel-10.0", | ||
| ], text=True) |
There was a problem hiding this comment.
This will pass, but if we start testing a full build then osbuild fails to download RPM packages. The fastest "image" type is tar which only takes few moments to build.
|
Would you mind unregistering the host as well? This uses prod environment let's be nice. |
d9e627e to
77740e1
Compare
.github/workflows/pytest.yaml
Outdated
|
|
||
| # those tests give us testing of the subscription-manager too | ||
| manifest-in-osbuild-container: | ||
| name: "RHEL manifest in container" |
There was a problem hiding this comment.
I guess this now a RHEL build :)
There was a problem hiding this comment.
Nice catch, thanks. Updated.
We need a way to test if image-builder can work with subscribed
content when run via a container. This requires a pair of secrets
SUBSCRIPTION_{ORG,ACTIVATION_KEY} and a host environment that
has `subscription-manager` installed.
Note that just running `image-builder manifest` is not enough,
even when this works the librepo/curl download can still fail
if osbuild does not find the right secrets.
Thanks to lzap for reporting this.
In oder to test if we can get subscribed content inside
a ibcli container we need a subscribed host. This is tricky
with github because:
a) there are no `runs-on: {fedora,centos,rhel}` systems
b) creating a fedora/centos chroot and running podman in it
is tricky because podman really dislikes chroots
So this commit runs it inside the osbuild test container that
is fedora based and relies on podman-in-podman container
execution (for this we need to run with `--privileged`).
77740e1 to
4dfaabd
Compare
| ]) | ||
| yield | ||
| finally: | ||
| subprocess.check_call(["subscription-manager", "unregister"]) |
|
Why this is working tho? Isn't the test supposed to fail? |
See the text in the PR description: |
|
Ah so it cannot be merged until it is fixed I assume, thanks. |
I will put it into the merge-queue, it should get kicked out again because osbuild is not ready. But if its not kicked out something else is wrong :( (or there is a miracle cure ;) |
|
meh :( and it even in the merge-queue skipped the subscribed content test because it did not have access to the secrets, that is quite disappointing :( GH action make developing/debugging this sort of thing (secrets accross forks) unfortunately quite fiddly. I will look into this again and fix it :( |
I think in these cases, I prefer having pytest markers rather than |
|
Thinking about this more lately, we need test case like this in osbuild repository, where RHSM secrets discovery is happening for builds and once osbuild/images#2055 is resolved, it would also for depsolving. Having an integration test in ibcli is good, but it is too late to test this kind of functionality here. |
Yeah, given that the merge queue is also not applying the secrets (which I don't know why) this is all not working anyway, I'm inclined to just revert it, I (still) think the idea is not bad as a smoke test but its impractical (especially at this layer). |
Yeah, I like the approach. I'll shamelessly use it in osbuild for the depsolver test (while giving you the credit) 😇 |
This is a followup for #390 - it adds a test that ensures that ibcli can access subscribed content in its container from a subscribed system.
This needs a SUBSCRIPTION_{ORG,ACTIVATIONKEY} secret and because of the way that secrets are handled in forks the test will not be run on forks but it will be run in the merge queue.
Note that just running
image-builder manifestis not enough,even when this works the librepo/curl download can still fail
if osbuild does not find the right secrets.
Thanks to lzap for reporting this.