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>
With the jjb/session label on the Pod, tracking the job works again.
Therefor this test can be re-enabled.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The jjb-validate job is not correct, it does not always return the
results of the PR.
Prevent triggering the job automatically, and only have it run when
someone leaves the '/test ci/centos/jjb-validate' comment.
Updates: #1111
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Using the 'git' function in groovy does not allow checking out a
non-branch, so use the 'checkout' function instead.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The 'scm' section also needs to be a list. Jenkins Jobs Builder does not
detect this while validating, but it cause an error while updating the
jobs in Jenkins.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
In case there is no 'origin', jenkins-jobs fails with an error like:
jenkins_jobs.errors.JenkinsJobsException: Must specify a url for git remote "origin"
Signed-off-by: Niels de Vos <ndevos@redhat.com>
There is a new .commitlintrc.yml file in the root of the repository.
This causes jenkins-job-builder to complains that the file is not
confirm the Jenkins Job Builder format/specification.
jenkins_jobs.errors.JenkinsJobsException: The topmost collection in file '/opt/build/.commitlintrc.yml' must be a list, not a <class 'collections.OrderedDict'>
Move all Jenkins Job Builder .yaml files to jobs/ so that all the
Jenkins job configurations are kept together without other files.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
