Specifically pertaining to executing tests in google cloud, there are
default, pre-allocated class-a subnetworks for each region (data-center).
Each includes a gateway using a `.1` LSB and all are routable from other
regions in google cloud via these gateways.
Because the default CNI configuration also utilizes class-a subnetworks,
this creates the possibility for IPv4 address-space clashes. Since the
default regional cloud subnets are pre-defined/known, preventing clashes
can be accomplished by seeding these subnets in a dummy CNI configuration.
The default behavior of podman is to grab the highest priority CNI
configuration. Name the dummy config. appropriate so it always loads
last. Also name the bridge itself with an obvious name `do-not-use`,
such that any related testing errors should be easier to debug.
Also:
* Minor cleanup of `install_test_configs()`
* Move install_test_configs in `setup_environment.sh` to after possible
run of `remove_packaged_podman_files()` because that also strips out
`/etc/cni/net.d/87-podman-bridge.conflist`.
Signed-off-by: Chris Evich <cevich@redhat.com>
This enables user to interact with varlink and create/manage rootless
containers through it.
Using as:
`varlink call unix:/run/user/1000/podman/io.podman/io.podman.ListContainers`
Signed-off-by: Matej Marusak <mmarusak@redhat.com>
Requirement from https://github.com/containers/libpod/issues/3575#issuecomment-512238393
Added --pull for podman create and pull to match the newly added flag in docker CLI.
`missing`: default value, podman will pull the image if it does not exist in the local.
`always`: podman will always pull the image.
`never`: podman will never pull the image.
Signed-off-by: Qi Wang <qiwan@redhat.com>
as issue #2702 describes, we want to make podman and podman-remote as
part of make install.
Fixes: #2702
Signed-off-by: baude <bbaude@redhat.com>
avoid `make` in `make install` in the rpmbuild process.
Signed-off-by: Lokesh Mandvekar <lsm5@fedoraproject.org>
This is mainly/initially to support use of Cirrus-CI
in https://github.com/containers/buildah since that setup
re-uses the VM images from this project. However, it also
opens doors here, if libpod ever needs/wants to do things
with a dedicated storage device and/or storage-drivers.
Signed-off-by: Chris Evich <cevich@redhat.com>
The release-task ***must*** always execute last, in order to guarantee a
consistent cache of release archives from dependent tasks. It
accomplishes this by verifying it's task-number matches one-less than
the total number of tasks. Previous to this commit, a YAML anchor/alias
was used to avoid duplication of the dependency list between 'success'
and 'release'
However, it's been observed that this opens the possibility for
'release' and 'success' tasks to race when running on a PR. Because
YAML anchor/aliases cannot be used to modify lists, duplication is
required to make 'release' actually depend upon 'success'.
This duplication will introduce an additional maintenance burden.
Though when adding a new task, it's already very easy to forget to
update the 'depends_on' list. Assist both cases by the addition
unit-tests to verify ``.cirrus.yml`` dependency contents and structure.
Signed-off-by: Chris Evich <cevich@redhat.com>
This task depends upon other tasks caching their binaries. If for
whatever reason the `release` task is re-run and/or is out-of-order
with it's dependents, the state of cache will be undefined. Previously
this would result in an error, and failing of the release task.
This commit alters this behavior to issue a warning instead.
Signed-off-by: Chris Evich <cevich@redhat.com>
It's somewhat hard to predict which units are certinly present
for any given base-image. Therefore, at image-build time, it's
distracting and unhelpful to see all the errors about units that
don't exist, on every platform. Simply ignore them and rely on
the `check_image.sh` test to confirm none are enabled.
Signed-off-by: Chris Evich <cevich@redhat.com>
For CI testing, it's important to remove as much variability from the
overall system as possible. This permits focusing just on problems
closely related to code-changes. To this end, and because VMs are very
short-lived (2 hours at most), disable all systemd services and timers
which perform periodic activities.
Signed-off-by: Chris Evich <cevich@redhat.com>
Various tasks and scripts behave differently depending on whether or not
the build is running against a PR or on a branch, post-merge. However,
a great number of them are hard-coded to the string 'master' as the
destination. Since this is not always the case (there are other
relevant branches), it makes sense to abstract the references with a
single definition.
Add a top-level `$DEST_BRANCH` variable to CI, and otherwise
default to 'master' when unset. This enables running CI builds on
additional branches without the overhead of updating all the static
references to 'master'. Simply update `$DEST_BRANCH` at the top-level
and all branch-conditional logic will function as intended.
Signed-off-by: Chris Evich <cevich@redhat.com>
Over time unless they're removed, the project could grow quite a large
collection of VM images. While generally cheap (less than a penny each,
per month), these will become a significant cost item if not kept
in-check.
Add a specialized container for handling image-pruning, but limit
it to only finding and printing (not actually deleting) images.
Also update the image-building workflow so that base-images used to
compose cache-images are also labeled with metadata.
N/B: As an additional safeguard, the service account which
executes the new container in production *DOES NOT*
have access to delete images. This can be enabled
by adding the GCE IAM role: CustomComputeImagePrune
Signed-off-by: Chris Evich <cevich@redhat.com>
Chris Evich