-
Notifications
You must be signed in to change notification settings - Fork 786
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
[skip-ci] Packit/TMT: Run gating tests #1960
base: main
Are you sure you want to change the base?
Conversation
A friendly reminder that this PR had no activity for 30 days. |
A friendly reminder that this PR had no activity for 30 days. |
A friendly reminder that this PR had no activity for 30 days. |
@lsm5 are you still working on this? (If so, this is not urgent from my POV, no need to push it to the front of your queue — I’d just like to close the PR if there is absolutely no chance this work will continue.) |
@mtrmac I do plan to work on this. But may take a while. I have bookmarked it for myself so I don't lose track. So please feel free to close it. |
Thanks, if it is still relevant, let’s keep it open. It might help, or inspire, other contributors. |
A friendly reminder that this PR had no activity for 30 days. |
A friendly reminder that this PR had no activity for 30 days. |
7bfbd1c
to
2e9afc9
Compare
@mtrmac @vrothberg @cevich RE: system tests in CI, is it critical to run them in a container or would we be ok with running |
@edsantiago is authoritative for system tests (question above). |
Forgive me please, I don't understand the question. It's been a while since I've looked at skopeo gating tests, but my recollection is that they run on a plain system, via |
IIRC the system tests run a registry server (container). So… running I’m not immediately sure how much custom tooling exists in the CI container, and would need to be reproduced; https://github.com/containers/automation_images/blob/main/skopeo_cidev/setup.sh is relevant to that, but IIRC almost all of that exists for integration, not system, tests. |
/packit test |
So, unfortunately, the issue we are hitting is a bug in Packit: It was not considered a bug before, as people were not hitting it and we did not know it had this consequence. |
Thanks @thrix . I'll disable the rhel tests for now. |
ack, the |
2e9afc9
to
49952d4
Compare
9c3a8a6
to
3607cd8
Compare
662a159
to
83405bc
Compare
/packit retest |
83405bc
to
3451bff
Compare
5bc34cb
to
9abdfca
Compare
8790b41
to
135c7ec
Compare
Tests failed. @containers/packit-build please check. |
95fbd34
to
70fb2e5
Compare
This commit adds enables unit, validate and integration testing via TMT. Tests have only been added for the x86_64 arch on Fedora and CentOS Stream as the tests depend on `quay.io/libpod/skopeo_cidev` which isn't multi-arch currently. Items for followup: - enable system tests - enable aarch64 tests - sync test files from upstream to downstream fedora Signed-off-by: Lokesh Mandvekar <[email protected]>
70fb2e5
to
5b3bb2c
Compare
@mtrmac PTAL. Only added x86_64 integration, validate and unit tests for now. |
If |
Hmm, and I guess running the tests in the skopeo_cidev container renders the multiple |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really don’t know what I’m doing here and how the things fit together — so a bunch of what I’m sure are stupid questions.
What is the longer-term plan? Is this going intended to be in addition to .cirrus.yml
, or eventually replace it?
@@ -43,7 +43,7 @@ jobs: | |||
enable_net: true | |||
|
|||
- job: copr_build | |||
trigger: pull_request | |||
trigger: ignore |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this an intentional part of the PR? It’s not obvious to me that changes to tests should affect whether we test building.
|
||
make PREFIX=/usr install | ||
if [[ ! -f /usr/bin/skopeo ]]; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAICS this introduces a risk that we are going to test some pre-existing system binary, not the one we just built (or, see elsewhere about SKOPEO_BINARY
), and that it is not caller-determined for certain, but it depends on what happens to be in the environment. That ambiguity seems undesirable to me.
- golang | ||
- make | ||
- podman | ||
- skopeo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this requiring some other Skopeo binary than the one we are testing? Or does that guarantee to use the one from copr_build
?
… and if this is the one we should be testing, how does that /usr/bin/skopeo
get injected into the test-integration
container? That doesn’t happen AFAICS.
@@ -71,7 +71,7 @@ BuildRequires: ostree-devel | |||
BuildRequires: glib2-devel | |||
BuildRequires: make | |||
BuildRequires: shadow-utils-subid-devel | |||
Requires: containers-common >= 4:1-21 | |||
Requires: containers-common |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is this related to the rest of the PR?
@@ -31,7 +31,7 @@ jobs: | |||
notifications: &copr_build_failure_notification | |||
failure_comment: | |||
message: "Ephemeral COPR build failed. @containers/packit-build please check." | |||
targets: | |||
targets: &fedora_copr_targets |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This, and centos_copr_targets
, seem to be unused. Is that intentional?
failure_comment: | ||
message: "Tests failed. @containers/packit-build please check." | ||
tmt_plan: /plans/upstream | ||
targets: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note to self: Per https://packit.dev/docs/configuration/upstream/tests#required-parameters , targets
which don’t specify an architecture imply x86_64
when used in tests
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe worth a comment in the file? Especially when it differs from the build job semantics.
ifdef SKOPEO_BINARY | ||
$(info Skipping build as SKOPEO_BINARY is specified) | ||
test-integration-local: | ||
else | ||
test-integration-local: bin/skopeo | ||
endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This suggests that SKOPEO_BINARY
might be set. (I can’t see anything setting it. for integration tests.)
But the Go test code invoked by go test
just assumes Skopeo is found in PATH
, and noting sets up SKOPEO_BINARY
to be handled.
How is this intended to work?
From an extremely brief look at the Packit / TMT documentation, the tests seem to run in an isolated VM (chroot? container?) and install RPM test subjects into that. Running an extra level of isolation in a container seems unnecessary in that case. (Also, to my knowledge no-one has been using the Also, testing the binary, if it comes from a RPM, in its expected distribution, seems clearly more valuable than running it in some other frozen / differently-built container. OTOH, at least one reason why the container exists, and is regularly rebuilt, is so that individual Skopeo CI runs don’t need to install and compile all of those tools, which rarely change, on every single CI RUN. Hence, in Cirrus, If the Packit tests are ever intended to be merge-blocking, something like that to shorten the CI time would be very valuable. And, also, I’d prefer not to maintain the test tool setup code ( https://github.com/containers/automation_images/blob/main/skopeo_cidev/setup.sh and |
@mtrmac thanks a lot for all the comments. Setting back to draft while I work through them. |
This commit adds enables unit, validate and integration testing via TMT.
Tests have only been added for the x86_64 arch on Fedora and CentOS Stream as the tests depend on
quay.io/libpod/skopeo_cidev
which isn't multi-arch currently.Items for followup: