You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Our CI process as of Jan 2022:

  1. Canonical CI for a release is ci-cassandra.apache.org
    1. Contributors can optionally run our tests on circleci as well to see if there are other failures that surface, however we will not block a release on that process.
  2. No release can be cut without a fully green CI run on ci-cassandra.apache.org
  3. Before a merge, a committer needs either a non-regressing (i.e. no new failures) run of circleci with the required test suites (TBD; see below) or of ci-cassandra.
    1. Non-regressing is defined here as "Doesn't introduce any new test failures; any new failures in CI are clearly not attributable to this diff"
    2. (NEW) After merging tickets, ci-cassandra runs against the SHA and the author gets an advisory update on the related JIRA for any new errors on CI. The author of the ticket will take point on triaging this new failure and either fixing (if clearly reproducible or related to their work) or opening a JIRA for the intermittent failure and linking it in butler (https://butler.cassandra.apache.org/#/)
  4. The Build Lead role + Butler catches and documents all failures and anything that slips through the procedural cracks in 3.b; resourcing for fixing flaky tests TBD

Pending Work

  1. ci-cassandra run bot updating ticket in JIRA w/state of test run for the SHA (JIRA Pending; to be linked)
  2. Finalize on the canonical set of tests and JDK env to run pre-commit (JIRA Pending; to be linked)
  3. Finalize Build Lead role (draft page here)
  4. Update C* website re: testing (link) with more details on CI process, running circleci, and link to this wiki article
  5. Resourcing drive to bring trunk and 4.0 down to 0 test failures (JIRA(s) Pending; to be linked)

General guidelines on how to author and run various tests

Mail list thread: https://lists.apache.org/thread/bq470ml17g106pwxpvwgws2stxc6d7b9

  • No labels