Kubernetes 1.22 is in the release process and can be used for testing
already. The CI jobs will be available and can be triggered by leaving a
comment in the PRs like
/test ci/centos/mini-e2e-helm/k8s-1.22
See-also: https://github.com/kubernetes/sig-release/tree/master/releases/release-1.22
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Kubernetes 1.21 is the latest stable release, and Ceph-CSI should be
tested with that. Currently 1.19 is still supported too, so we will need
to run the CI jobs with 1.19, 1.20 and 1.21.
See-also: https://kubernetes.io/releases/
Signed-off-by: Niels de Vos <ndevos@redhat.com>
When the `ci/centos` branch has been merged, the container images that
are built from it may need to be rebuilt. Instead of conditionally
rebuilding images only on a change, just rebuild them always, as there
are very few changes in the CI branch anyway.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The Kubernetes e2e external storage tests from v1.21 do not work yet
with Ceph-CSI. In order to address the issues, the job is now provided
and can be run with:
/test ci/centos/k8s-e2e-external-storage/1.21
The job for v1.20 is enabled by default, and identified by the
ci/centos/k8s-e2e-external-storage/1.20 context in PRs.
Updates: #2017
Signed-off-by: Niels de Vos <ndevos@redhat.com>
To test a PR with Kubernetes 1.21, leave a comment in the PR like:
/test ci/centos/mini-e2e-helm/k8s-1.21
The status of the job will be recorded in the PR, but running this job
is not required (yet).
Updates: #1963
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Kubernetes v1.20 has been released, so lets use that for testing. Note
that v1.18 is still maintained, but our CI jobs will not consume it
anymore.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Add CI jobs for Kubernetes v1.20 testing. These jobs will run, but are
not (yet) required before changes get merged.
Updates: #1784
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>
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>
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>
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>
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 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>
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>
Instead of accessing the upgrade version from environment
variable, set the variable directly in configuration file.
Signed-off-by: Yug <yuggupta27@gmail.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>
removed 1.17 as we are testing only two versions
in centos CI. as v1.19 is released, we will be
testing v1.18 and v1.19 in CI.
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
By using GitHub Hooks, jobs get triggers quickers. It also may prevent
the occasional hickup in the Jenkins GitHub-Pull-Request-Builder while
polling events for the cron-jobs.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Not everyone can restart CI jobs, only members of the Ceph organization
in GitHub. All jibs (except "commitlint") are started automatically, so
there is no functional change.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
commitlint should not run automatically on PRs, regardless who posted
the PR. Everyone should be able to trigger a run of the job with `/test
commitlint` anyway.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The jobs/commitlint.yaml refered to the containerized-test.groovy
script, not the commitlint.groovy script.
Make sure to run the righ job when requested. Add some comments to make
things a little clearer.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Each PR gets tested by the commitlint app (which is deprecated). On
occasion the app does not pickup the change in a PR, and the only way to
start a retest is to re-push the PR. All tests will then get executed
again, even if only commitlint was needed.
The new commitlint CI job introduces '/retest commitlint' and runs in
the CentOS CI like other Jenkins jobs. However, the job does not start
automatically on each (updated) PR, but needs manual starting with the
'/test commitlint' or '/retest commitlint' comments. The normal way of
running commitlint is with the app (at least for now).
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The mini-e2e-helm.groovy script is mostly a copy of mini-e2e.groovy that
does the deployment through the e2e.test executable. The new script
installs Helm and deploys Ceph-CSI through that.
Once the e2e tests have successfully finished, the deployment of
Ceph-CSI is removed again.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The "/" in the name may have a conflict with the existing "mini-e2e" job
name. Rename the new generated jobs to "mini-e2e_k8s-1.x.y", with a "_"
instead of "/".
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Currently the jjb-validate job always checks out the ci/centos branch,
not the contents of the PR. This makes testing PRs unreliable.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Move the mini-e2e job into a template-job and generate two jobs out of
it: mini-e2e/k8s-1.17.8 and mini-e2e/k8s-1.18.5
By passing the k8s_version as variable to the job-template, and placing
it in the parameters for the mini-e2e.groovy script, all hard-coded
occurences of the Kubernetes version can be replaced by the
{k8s_version} placeholder.
See-also: https://jenkins-job-builder.readthedocs.io/en/latest/definition.html#job-template
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Restarting the CI job can now be done with the following comments in a
PR:
- /test all
- /retest all
- /test ci/centos/mini-e2e
- /retest ci/centos/mini-e2e
- /test ci/centos/mini-e2e/k8s-1.18
- /retest ci/centos/mini-e2e/k8s-1.18
This is added as preparation for enabling running the mini-e2e job with
different Kubernetes versions.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The new mini-e2e jobs does the following:
- reserve a bare-metal machine
- checkout the git repository with the PR
- build used artifacts (container image and e2e.test executable)
- deploy k8s and Rook in a minikube VM
- run the e2e tests
With-contributions-from: Yug <yuggupta27@gmail.com>
Signed-off-by: Niels de Vos <ndevos@redhat.com>
