travis: add aarch64 s390x epel-8 #103
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
wenningerk
force-pushed
the
test_travis
branch
30 times, most recently
from
201496d to
3a97740
Compare
wenningerk
force-pushed
the
test_travis
branch
11 times, most recently
from
c6bb416 to
1331269
Compare
wenningerk
force-pushed
the
test_travis
branch
7 times, most recently
from
2d43a14 to
9c1d8e2
Compare
making it work on LXD containers needs heavy hacking of mock and just works going that route if the ubuntu-kernel is near enough to the built-target-distribution
wenningerk
force-pushed
the
test_travis
branch
from
9c1d8e2 to
357a275
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds both additional architectures (aarch64 & s390x) and Suse build-targets to the travis-CI.
While adding the Suse build-targets just introduced a bit of uglyness due to longer lines and
less readability due to the different naming conventions for mock-build-targets and containers
the additional architectures were a real pain due to them running in LXD containers.
Problem is that the containers inside thes LXD containers can't be run privileged and not
even sys_admin-capabilities do arrive properly inside the container.
For testing the packages this can be mitigated instructing the new testbed-preload-library
to remove the requirement for device-mapper (buying us a slightly inferior test but well ...).
The real pain was mock that had to be instructed not to do a couple of things like nspawn-containers,
bindmounts and stuff. Most things could be disabled via available config. What stayed and
had to be patched out for the first was mounting of /proc and /sys.
That is all not very beautiful but it seems to be working and more effort may be moot to a
certain extent as how the additional architectures are made available via LXD is subject to
change anyway as told by travis. Enabling the nesting-capability for the containers would
e.g. sound interesting but so far there doesn't seem to be a configuration option.
Of course we won't ever have the LXD containers privileged to an extent that we could
have device-mapper and loopback-mounts inside as long as the kernel doesn't provide
the proper namespaces and running in the same namespace as the other users seems
critical of course.
Dealing with the issue makes probably sense as travis seems to intend moving the AMD64
machines to LXD containers as well.
ppc64le btw. is basically functional but is failing quite often due to slow repo access. Don't
know if it has slower network-access than the other architectures or if it is just slow or
overcommitted.
Piggybacked there comes a small relaxation for timeouts of 2 tests that turned out to
be necessary to cope better with loaded test infrastructure. (I know at least partly I
was the reason for this overload amending the PR again and again till I got it to work ;-) )