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>
By using this script, we can pass Kubernetes versions like v1.19 to the
CI jobs. The jobs are then responsible for detecting the a full release
version, including the '.patch' suffix.
Versions are passed as 1.19, releases have the 'v' prefix as in v1.19.1.
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 passing `--id=<id>` the labels of the given Pull-Request or Issue get
printed. When adding `--has-label=<label>`, the script verifies if the
label is set and returns 0 on succes, or 1 on failure.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
if the commit header is not present in the list of
the component we maintain. the commitlint check should
show error instead of showing the warning.
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
(cherry picked from commit 52243d0140)
The --history does not take an argument, similar to --help. Move it out
of ARGUMENT_LIST so 'getopt' does not complain about it.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
After fetching the target branch for the PR, the GIT_SINCE ref in the
git repository may not be set (in CI environments). This causes 'git
rebase' to fail. Use FETCH_HEAD instead, so that the checked out PR gets
rebased correctly.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
In case the history of the branch is needed (commitlint job), add an
option --history to skip cloning the repository with --depth=1.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
By passing REBASE=1 to the commitlint make target, the current checked
out PR will be rebased on top of the parent branch. This should result
in a linear history that commitlint can parse correctly.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
When Mergify adds a merge commit to the branch that is being tested with
commitlint, the tool tries to detect the most recent changes based on
the newly merged commit. This is for most PRs the master branch, and
that contains incorrect commit messages in the history. Because of this,
commitlint will fail.
By adding an option (REBASE=1) to the commitlint make target, CI jobs
can request a rebase so that the history of the PR becomes linear again
and commitlint should be able to detect only the new commits.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Due to a strict timeout, the job
tends to abort sometimes. Increasing the
timeout to allow sufficient time for
tests to execute.
Signed-off-by: Yug <yuggupta27@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>
By placing CSI_IMAGE_VERSION=v3.1.0 in build.env in the release-v3.1
branch, the CI jobs using single-node-k8s.sh can pickup the version
dynamically.
Other release branches can do the same, and the CI jobs will not need
modifications for each release.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
It seems ci-job-validation.groovy got merged with a mistake. The
git_repo variable is used, but was not defined.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
When running in the CI the git repository is not completely cloned. This
causes the 'commitlint' job to be unable to resolve the history of the
commits.
By using FETCH_HEAD, the last 'git fetch' output will be used.
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>
When running the commitlint CI job, the branch that the PR is based on
may not be available. That makes it impossible for commitlint to detect
the changes between the HEAD of the branch, and the commits in the PR.
By fetching GIT_SINCE unconditionally, commitlint should be able to
detect the changes and only run the tests against the commits that were
added through the PR.
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>
All bare-metal systems in the CentOS CI have 16GB or more RAM. To
improve performance of the minikube VM, give is 8GB RAM.
See-also: https://wiki.centos.org/QaWiki/PubHardware
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Curently the stage name directly
prints the name of the variable
in place of substituting it.
This is a fix for that issue.
Signed-off-by: Yug <yuggupta27@gmail.com>
Using double quotes as variables are
expanded inside them.
The script fails currently as it is
unable to expand the variables.
Signed-off-by: Yug <yuggupta27@gmail.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>
