Skip to content

CentOS CI

Anoop C S edited this page Nov 28, 2023 · 2 revisions

With the help of community space provided for Samba by CentOS project we have our own Jenkins based test setup to validate the integration of various backend file systems. Helper scripts and necessary configuration files are maintained within samba-centosci repository.

Automatic test runs for pull requests

Every new pull request against sit-environment repository is configured to automatically trigger the following tests on CentOS CI:

Updates to pull request in the form of modified commits are also entitled to trigger the mentioned test runs. Further each test run is integrated to report their status in the list of GitHub checks.

Automatic test runs can only happen for those added to the list of approved contributors.

How and when are tests triggered?

Required test runs are configured as Jenkins jobs where polling mechanism is used to look at pull requests against a repository. Here in this case polling interval is set for 5 minutes. Therefore a maximum delay of 5 minutes can be expected but not beyond it. Or in other words tests are expected to start anywhere between the update to pull request and 5 minutes thereafter.

Watching the progress of test runs

General status of each run is displayed with yellow filled circle, green tick or red X indicating in progress, successful or failed job. In addition to that status is also provided in text format like Pending, Started, Finished etc. From the list of GitHub checks you can click on the Details hyperlink towards right hand side of any test and watch or analyze in detail from Jenkins.

Analyzing test failures

While you are at a specific Jenkins job details page you could look through what really happened by following the 2-step procedure:

  1. Console output

    Towards the left hand side you will find a Console Output link which should give you a glance at how the installation and commands worked along with the results of ansible playbooks execution.

  2. Build artifacts

    Whatever specific details we prefer to include are normally made available as artifacts. In this case we should see a tarball with statedump of various nodes and the actual test run output.

    Please note that these are kept only for a week due to other storage constraints.

Handling spurious failures

There are situations where we may encounter network issues and other unexpected glitches resulting in an early exit and corresponding test run failure. In order to circumvent such problems we have introduced mechanisms to re-trigger tests manually with required permissions. Please refer the next section How to re-trigger tests?.

How to re-trigger tests?

We make use of GitHub comments on pull request to retry failed test runs. It is as simple as putting a comment in the following format:

/retest centos-ci/cephfs

OR

/test centos-ci/xfs

In case you wish to re-trigger every tests that are supposed to run against it use the following format:

/retest all

OR

/test all

Please keep in mind the expected delay as explained in section How and when are tests triggered?

Clone this wiki locally