e2e: skip pre-checkpoint tests on aarch64#26234
e2e: skip pre-checkpoint tests on aarch64#26234openshift-merge-bot[bot] merged 1 commit intocontainers:mainfrom
Conversation
openshift-ci
bot
added
release-note-none
do-not-merge/work-in-progress
|
I'll verify if the tests are skipped correctly on containers/container-selinux#378 |
Per Adrian Reber, the aarch64 kernel doesn't support the soft dirty bit and support isn't expected anytime soon. Ref: checkpoint-restore/criu#2676 Signed-off-by: Lokesh Mandvekar <[email protected]>
lsm5
force-pushed
the
pre-checkpoint-skip-aarch64
branch
from
3880396 to
5e7c0a6
Compare
This won't work if we need to fetch sources as is the case with e2e test runs. I've verified the tests are skipped on a testing farm aarch64 instance. Opening for review. |
openshift-ci
bot
removed
the
do-not-merge/work-in-progress
|
LGTM |
|
|
||
| It("podman checkpoint container with --pre-checkpoint", func() { | ||
| if podmanTest.Host.Arch == "arm64" { | ||
| Skip("skip on arm64/aarch64, checkpoint-restore/criu GH issue #2676") |
There was a problem hiding this comment.
could as well put the full URL here instead so users don't have to manually look it up.
There was a problem hiding this comment.
even better yes. I'll do a followup.
btw, long term it'd be even better to implement Adrian's suggestion of checking for criu's supported feature set on the arch and skipping based on that.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: flouthoc, lsm5, Luap99 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Followup on containers#26234. Signed-off-by: Lokesh Mandvekar <[email protected]>
stale-locking-app
bot
added
the
locked - please file new issue/PR
4 participants
Per Adrian Reber, the aarch64 kernel doesn't support the soft dirty bit and support isn't expected anytime soon.
Ref: checkpoint-restore/criu#2676
Does this PR introduce a user-facing change?