The CI scripts pull all container images from the local CI registry. If
the image name starts with "docker.io/", the images will be pushed into
the test environment as "docker.io/docker.io/ceph/ceph:v15". This image
will not be used by the tests, so things can still fail in case Docker
Hub has reached the pull rate-limit.
By dropping the additional "docker.io/" from the BASE_IMAGE name, the
image gets pushed as "docker.io/ceph/ceph:v15" so the tests will use it
automatically.
Groovy-syntax: https://www.baeldung.com/groovy-remove-string-prefix#using-regex
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Instead of using a mirror, the CI registry is now pupulated with
container images that get pulled and tagged as if they get from Docker
Hub or other locations.
This is more of a manual mirror, as the Docker Registry mirror
functionality is not flexible enough for our usecase (push images
without providing them on docker.io).
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The mirror option of the Docker Registry container is very limited and
prevents updating or manually pushing images to the registry. Instead,
it tries to push the images to the docker.io, which is not what we need.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
docker.io/nginx:latest and docker.io/vault:latest are being redirected
to docker.io/library/. The redirection is not cached, and Docker Hub
might return an error during redirection when the pull rate-limit is
hit.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Deploying Ceph with Rook fails as the ceph/ceph:v15 base image can not
be pulled from within the minikube VM. By pushing the image into the VM,
but before deploying Rook, there should be no need to pull the image
from Docker Hub anymore.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Changes in scripts will affect the CI jobs as the scripts are used while
deploying minikube, Rook and other components. These changes need
testing, just like anything else.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Some versions of minikube/docker add a "localhost/" prefix to imported
images. In that case, the image needs to get tagged without the prefix
as well.
When running podman2minikube.sh, the docker process inside the minikube
VM sometimes responds with:
# ./podman2minikube.sh rook/ceph:v1.3.9
Loaded image: localhost/rook/ceph:v1.3.9
When the "localhost/" prefix is added to the image name, deploying Rook
will try to pull the rook/ceph:v1.3.9 image again. This can fail when
the Docker Hub pull rate-limit is hit.
Without the "localhost/" prefix, there should be no further attempt to
pull the image, as it should be detected that the image is available.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Unqualified container images are currently used for CI jobs. In the
future this is expected to change. By preparing the cache/mirror and
images in minikube with the qualified tags, transition to qualified
image names should become easier.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
In case ROOK_VERSION is set in build.env, use the version from there.
Otherwise fall back to version 1.3.9.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
This makes it possible to pull images from Docker Hub through the local
container image registry in the CI OpenShift deployment. The registry in
the CI is configured with the 'cephcsibot' account so that pulling
images is accounted towards the account, and not anonymous consumers
within the whole CentOS CI.
There should be no need to manually sync the images between the local
registry and Docker Hub anymore.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Functions with Groovy can not use `def ci_registry` as the variable is
not in the scope. Pass the registry to the podman_login() and
podman_pull() functions instead.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
A typo when calling podman_log() causes CI jobs to fail.
Fixes: 1eec379 "ci: pre-pull Ceph base-image and cephcsi:devel for mini-e2e-helm jobs"
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The same changes have been made for the mini-e2e jobs yesterday, and
those seem to work well. Use the same pre-pull method for the Helm
deployment.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
It seems that "podman pull" does not consume the authentication details
from ~/.docker/config.json, so store the results of "podman login" in
~/.podman-auth.json and use the file for all "podman pull" commands.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Once the ssh command finishes, the runtime directory is removed and the
results of "podman login" are lost. By storing the results in the
standard Docker configuration file, subsequent "podman pull" commands
will be able to re-use the authentication details.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The ${BASE_IMAGE} variable gets expanded by running the ssh command.
This becomes an empty variable, so the "echo" part of the command does
not output anything.
By escaping the command, there is no variable substitution, and the
BASE_IMAGE variable should get stored in the variable.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The commitlint job is not used normally, so there is no need to run it
when all CI jobs need retesting.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The BASE_IMAGE variable was not stored in the variable so that the CI
job can consume it. By using sh(), this should be the case now.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
In case the '--cmd' option is missing, usage() will be called and the
script exits with 0. A missing option is a failure, so make usage()
return and handle the exit status when usage() got called instead.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
As ${RUN_DISPLAY_URL} also matches the format for template
substitutions, it can not be used like this for all Jenkins Jobs Builder
files. Instead, $RUN_DISPLAY_URL can be used, as it does not have the
{curly_braces} format and the template engine skips it.
Fixes: 87870369 (ci: link to the job in the Blue Ocean webui)
Signed-off-by: Niels de Vos <ndevos@redhat.com>
In order to speed up testing, "go mod verify" can be run parallel from
other tests. Downloading and verifying all dependencies is the most time
consuming step in the containerized-test CI job.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The new Blue Ocean webui is much easier to navigate than the traditional
Jenkins webui. Developers that want to check failures of CI jobs will be
able to find the logs much quicker as each stage/step has a clear
success or failed status.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
There is no need to re-use different layers with the images that are
built. The separation of the layers causes more time to be used while
pulling the images, so flattening makes speeds up the CI jobs a little
(about 30 seconds from 2+ minutes).
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Because the parallel steps, the build.env is not in the local directory
where the command is executed. So fetch the BASE_IMAGE before continuing
with 'oc start-build', and pass the name of the image on the
commandline.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Add the ability to run JJB from private branch/fork
jjb-deploy.yaml:
- Add GIT_REPO parameter (not required) with default value
jjb.sh:
- Changing PS4 for more indicative debug prompt
- Adding flags to get the repo and branch
jjb-deploy.yaml:
- Calling the jjb.sh with the correct flags
Signed-off-by: liranmauda <liran.mauda@gmail.com>
The new 'build-images' job rebuilds ceph-csi:canary, ceph-csi:devel and
ceph-csi:test images after a PR has been merged in the master branch.
These images can then be used by other CI jobs, to improve the speed by
reducing unneeded rebuilds of the images.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The BuildConfig can be imported in the OpenShift environment so that
Ceph-CSI images can be built automatically. These images will be cached
in a private container image registry, which can speed up CI jobs that
currently rebuild the images every time.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
With a private container image registry, the images that CI jobs use can
be cached and re-used. This speeds up the CI jobs, as building the
container images takes up the majority of the runtime for some jobs.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
When running on Minikube, the k8s-e2e-external-storage fails with an
error related to the kubeconfig file:
error creating client: unable to load in-cluster configuration, KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT must be defined
It seems that this is a problem when the kubeconfig is not
self-container, but refers to additional files. This is the case when
Minikube deployed the Kubernetes cluster.
By exporting the kubeconfig into its own self-contained file, the CI job
starts running.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
When fetching refs/pull/<pr-id/merge from GitHub, there is no need to do
a manual rebase. This makes things easier, as a the scripted rebases
sometimes cause CI jobs to fail.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
With the update to minikube v1.14.1 downloading binaries for the recent
Kubernetes patch releases works again. Enable detecttion of the latest
patch releases for use in the CI jobs.
Fixes: #1588
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The ./run-k8s-external-storage-e2e.sh script that executes the
Kubernetes e2e external-storage tests needs to be placed on the
bare-metal machine. Currently, the k8s-e2e-external-storage job fails
with:
bash: ./run-k8s-external-storage-e2e.sh: No such file or directory
Signed-off-by: Niels de Vos <ndevos@redhat.com>
