Due to some recent changes in the Makefile, the setup part of the script
is now breaking with the error:
```
install: cannot stat 'bin/rootlessport': No such file or directory
make: *** [Makefile:767: install.bin] Error 1
```
The root-cause seems to be the `install` targets not
properly specifying their build dependencies. This may lead to other
problems WRT automation, but for now I'm just patching this tool to
workaround the issue.
Signed-off-by: Chris Evich <cevich@redhat.com>
Followup to dbb9943
Despite skipping the `Smoke` check, it was observed on a *new* branch,
the `validate` task (specifically `git-validation`) will fail. This
is because:
* `$CIRRUS_LAST_GREEN_CHANGE` will be empty on a new branch.
* `$CIRRUS_BASE_SHA` is always empty for runs triggered by branch-push
* `$EPOCH_TEST_COMMIT` will be set to `YOU_FOUND_A_BUG`.
Fix this by eliminating the `Smoke` task entirely, simplifying all
the `make validate` operations into the `validate` cirrus task. Ensure
this task does not run when a new branch or tag is pushed.
Also, eliminate the `$CIRRUS_BUILD_ID` value as it's confusing and not
actually used anywhere. It was formerly used for building VM images,
but this has moved to another repo entirely.
Signed-off-by: Chris Evich <cevich@redhat.com>
Also removed automatic exection of setup_environment.sh since most
people using this script are podman developers (not automation/CI
folks). If executing the automation scripts is necessary, manual
attendance to required variables like `$TEST_FLAVOR` is mandatory.
Signed-off-by: Chris Evich <cevich@redhat.com>
It's not possible to run any of the scripts on distributions which do
have `bash` not in `/bin`. This is being fixed by using `/usr/bin/env
bash` instead.
Signed-off-by: Sascha Grunert <sgrunert@suse.com>
This properly prints out image-name hints when executing the hack script
without any arguments. It is required due to changes made by Ed for
test-name beatification. An identical change was made and reviewed by
Ed in the containers/storage repo.
Signed-off-by: Chris Evich <cevich@redhat.com>
in cases where the log file exceeds the available memory of a system, we had a bug that triggered an oom because the entire logfile was being read when the tail parameter was given. this reads in chunks and is more or less memory safe.
fixes: #5131
Signed-off-by: Brent Baude <bbaude@redhat.com>
Remove disused `build_cache_images` task, and
update relevant dockerfiles for F30.
Fix problem of cloud-init failing to expand root-device on boot
(/var/lib/cloud/instance left in improper state).
Fix problem of cloud-init racing with google-network-daemon.service on
boot (looking for cloudconfig metadata too early). Causing
root-device to _sometimes_ fail to expand.
Fix problem of hack/get_ci_vm.sh argument passing.
Signed-off-by: Chris Evich <cevich@redhat.com>
* Randomize the user's UID and GID
* Simplify `setup_environment.sh`
* Support new "-r" option for `hack/get_ci_vm.sh` setting up rootless
* Connect as $ROOTLESS_USER when using "-r" with `hack/get_ci_vm.sh`
Signed-off-by: Chris Evich <cevich@redhat.com>
Previously, the script would bind mount the user's home directory into
the container in order to execute gcloud commands. This was done
to preserve the `.config/gcloud` directory and new ssh keys in `.ssh`.
However, it's possible the user has modified `.bash*` or `.ssh/config`
files which do not play nicely with gcloud and/or the container.
Fix this by mounting the existing temporary directory on the host, as
the user's home directory. Then bind mount in a dedicated `gcloud/ssh`
sub-directory, and the libpod repo directory on top. Pre-create the
necessary mount-points as the user, so later removal does not require
root on the host.
The gcloud tool takes minutes to setup/manage its ssh-keys, so preserving
that work between runs is a necessary optimization. Similarly, saving the
`.gcloud` directory prevents repeatedly going through the lengthy
client-auth process.
Overall, these changes make the container environment much more selective
with the host-side data it has access to use/modify. Preventing unrelated
details from getting in the way, and preserving only the bare-minimum of
details on the host, between runs.
Signed-off-by: Chris Evich <cevich@redhat.com>
More complicated than one would think. The first problem is that,
on certain (but not all) Fedora systems, podman cannot mount
volumes read-only (issue #2312). This is baffling, and since
it's not easily reproducible it's likely that the dev team
will not spend much effort on it. Workaround: instead of bind-
mounting /tmp read-only, bind-mount a *tempdir* (subdirectory)
read-write. This is actually cleaner in some ways but it
leads to complications with the paths we use and with cleanup.
Next, allow overriding the default image and allow asking
for no sudo:
export GCLOUD_IMAGE=quay.io/edsantiago/gcloud_centos:latest
export GCLOUD_SUDO=
(yes, that's an equal-sign and EOL. Just an empty string).
The third part, unfortunately, requires a custom image because
the as_dollar_user.sh script (the one that runs gcloud in a
container) is hardwired in a cevich image and needs tweaks
in order to detect rootless and avoid sudo.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Previously it was not possible to specify keys from the ``env`` section
in the various GCE sections. Now that features is added, consolidate
all the cache image definitions into a single place, reducing
maintenance burden.
This also results in the names passing through into the VMs. This is
useful, e.g. for future tracking of image usage statistics.
Update get_ci_vm script hints for new image name definition format
Signed-off-by: Chris Evich <cevich@redhat.com>
Previously, using the ssh command directly required obtaining the
external IP of the VM and was then subject to the local configuration.
If the local configuration and/or ssh keys are incorrect, these commands
would fail, preventing automatic setup of the VM.
Fix this by using the gcloud ssh and scp wrappers. Unfortunately rsync
couldn't be made to work in this situation, so use a tarball to transfer
the local repository to the VM. Lastly, execute `setup_environment.sh`
script, then drop the caller into a bash shell sitting in the remote
`$GOSRC` directory.
Signed-off-by: Chris Evich <cevich@redhat.com>
Frequently debugging of CI-related problems requires going hands-on
within the environment. However, reproducing the environment by hand is
very tedious and error prone. This script permits authorized users to
produce VM's based on any available cache-image, and automatically remove
them upon logout.
Also: Bump up VM disk sizes to 200GB due to performance reasons
Signed-off-by: Chris Evich <cevich@redhat.com>
