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>
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>
Commit f5cba3aaa8 added the mini-e2e job, but still referred to the
temporary location that was used for testing the job. As everything is
available in the ceph-csi:ci/centos repository:branch, there is no need
to refer to the temporary location.
Reported-by: Yug <yuggupta27@gmail.com>
Signed-off-by: Niels de Vos <ndevos@redhat.com>
While debugging issues with the job itself, a sleep has been very
useful. PRs that have been rebased on the master branch contain all the
deployment fixes that are needed for the job to pass. There is no need
anymore to run into the long sleep when the job fails.
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 CentOS CI jobs that use single-node-k8s.sh will run minikube with
additional disks. That makes it possible for Rook 1.3 and newer to
deploy the Ceph cluster.
The current Travis CI jobs run minikube on the Travis provided
environment, without any extra disks. This prevents updating Rook for
all CI jobs at the moment.
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>
Currently CentOS-7 machines were requested. CentOS-8 has been out for a
while now, and is stable for running manual jobs. There is nothing
preventing us from using CentOS-8 bare-metal machines for testing.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
On the new OCP4 cluster, deleting the batch job results in deletion of
the pod as well. Deleting the pod when it does not exist anymore results
in a failure. Ignoring the potential failure makes the job pass again.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
