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>
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>
