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>
The run-k8s-external-storage-e2e.sh script downloads the kubernetes-test
components, creates a configuration for RBD and CephFS drivers and runs
the external-storage tests on the current cluster.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The jjb-validate job creates a Batch Job in OCP. This job has a fixed
name, and fails to get created when one with the same name already
exists. There is no need to run jjb-validate concurrently, the number of
changes for CI jobs are not blocked by this serialization.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
refs/pull/<id>/head might not contain the most current state of the
branch. In case other PRs got merged, the PR under test needs rebasing.
GitHub offers refs/pull/<id>/merge to checkout the rebased PR, use that
in the CI jobs.
In case refs/pull/<id>/merge is not available, it means the PR can not
be rebased on its target branch. This will cause the CI job to fail, but
GitHub also will have a message about rebase conflicts.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
When the [ci/skip/e2e] label is set on PRs, the withCredentials()
statement is aborted, but the other stages still continue. This causes
the tests to run, which is not what we want when the label is added.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
It still seems that the environment is not set when the GitHub API is
called. Maybe things work better when the environment is set before
starting the cico-workspace node.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The latest Kubernetes patch release (v1.18.10) can not be deployed with
minikube. Selecting version 1.18.9 until the problems with minikube are
addressed.
Updates: #1588
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The latest Kubernetes patch release (v1.19.3) can not be deployed with
minikube. Selecting version 1.19.2 until the problems with minikube are
addressed.
Updates: #1588
Signed-off-by: Niels de Vos <ndevos@redhat.com>
In case the version that is passed with --version=... contains the patch
release already, the latest patch release will not be detected, but the
passed version will be returned (enables forcing a particular version in
CI jobs).
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Anonymous users have a low (currently 60) rate limit of API calls.
Authorized users have a much higher (currently 5000) limit. Print the
available, used and remainling rate limit when the GitHub API returns a
403 messages like:
Error: 403 Client Error: rate limit exceeded
In case of anonymous access to the API, and hitting the limit, the
message in the logs will also include the following:
Rate limit (limit/used/remaining): 60/60/0
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The `credentials()` function might only work in the `environment` block
in the Pipelines. At the moment, running the 'skip ci/skip/e2e label'
stage always reports 'Error: 401 Client Error: Unauthorized'.
Fixes: e0d49908 (ci: fetch GITHUB_API_TOKEN from Jenkins credential store)
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Fetch the named credential "github-api-token" from the Jenkins
configuration. This is a "personal access token" that has been created
with the ceph-csi-bot user account.
CC: @ceph-csi-bot
Signed-off-by: Niels de Vos <ndevos@redhat.com>
These script now check if GITHUB_API_TOKEN is set in the environment,
and use that for authenticating. There is no username needed when an API
token is used, but it may not be empty, so it is set to "unused".
Signed-off-by: Niels de Vos <ndevos@redhat.com>
On occasion the scripts that use the GitHub API fail without logging any
useful error:
./scripts/get_github_labels.py --id=1568 --has-label=ci/skip/e2e
Traceback (most recent call last):
File "./scripts/get_github_labels.py", line 71, in <module>
main()
File "./scripts/get_github_labels.py", line 55, in main
names = get_names(json)
File "./scripts/get_github_labels.py", line 40, in get_names
names.append(label['name'])
TypeError: string indices must be integers
While debugging, it seems that the limit of API calls is reached:
403 Client Error: rate limit exceeded
It is useful to have failure messages reported in the output of the CI
jobs for future potential troubleshooting.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Old jobs stay behind (and active) when jobs get updated with new
versions. This mostly affects the mini-e2e jobs at the moment.
There is no need to keep old job around, so delete them while deploying
updates to jobs.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Rebase current checked out PR on top of parent branch.
This will then prevent commitlint to check complete
history of 'ci/centos' branch.
Signed-off-by: Yug <yuggupta27@gmail.com>
Installing Docker CE on CentOS-8 currently conflicts with Podman. Both
tools can not be installed at the same time.
Instead of using the Docker command to push the image to to minikube VM,
read the image from stdin over ssh and load it with the Docker command
that is available inside the VM.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Instead of accessing the upgrade version from environment
variable, set the variable directly in configuration file.
Signed-off-by: Yug <yuggupta27@gmail.com>
Since UPGRADE_VERSION is not a groovy variable, adding an
escape character is required for proper execution of
upgrade-testing job.
Signed-off-by: Yug <yuggupta27@gmail.com>
GIT_REF can point to a ref that it not part of a branch and can not
easily be checked out (like a GitHub PR). Checking out FETCH_HEAD after
fetching the GIT_REF works.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The batch job templates for OpenShift use a GIT_REF variable that is
used by the jobs to checkout the repository. This defaults to
"ci/centos", but it never is adjusted when jjb-validate runs against a
PR.
With the new GIT_REF environment variable in the jjb.sh script, the
variable can now be used to checkout a PR from gitHub and run the
validation against that.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The GitHub Pull Requests Builder plugin sets the ghprbPullId parameter.
There is no need to make it configurable, and it even overloads the
value from the plugin by the default value.
This cauesed the jjb-validate job to run against the ci/centos branch
for each PR, not against the contents of the PR itself.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The Jenkins Jobs Builder files reference 'sandbox: true' as an option,
but this does not exist (anymore). Having the option causes warnings in
the Jenkins WebUI for admin users.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Jobs can now pass the wanted Kubernetes major version (like '1.19') to
the Jenkins Pipeline scripts. The Pipelines detect the most recent patch
release for the major version with the new get_patch_release.py script.
This causes the CI Job status context to not have the patch number (last
digit of the release) included anymore. Restarting a test will only need
the major version number, as does updating the Mergify configuration.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
