Versions Compared

Old Version 45

changes.mady.by.user Mick Wever

Saved on

compared with

New Version Current

changes.mady.by.user Mick Wever

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Date Range (reversed)WeekNameEmail#cassandra-dev slack

  -  

21


  -  

20


  -  

19


  -  

18


  -  

17Mick Semb Wevermck@apache.orgmck

  -  

16Dan Jatnieksdjatnieks@gmail.comDan Jatnieks

  -  

15


  -  

14Josh McKenziejmckenzie@apache.orgjmckenzie

  -  

13Josh McKenziejmckenzie@apache.orgjmckenzie

  -  

12Mick Semb Wevermck@apache.orgmck

  -  

11maxwellguocclive1601@gmail.commaxwellguo12

  -  

10Derek Chen-Beckerapache@chen-becker.orgdchenbecker11

  -  

109Derek Chen-Beckerapache@chen-becker.orgdchenbecker

  -  

98Mick Semb Wevermck@apache.orgmck

  -  

87maxwellguocclive1601@gmail.commaxwellguo

-  

76German Eichbergergeeichbe@microsoft.comxgerman

-  

65Dan Jatnieksdjatnieks@gmail.comDan Jatnieks

-  

54Claude Warrenclaude.warren@aiven.ioClaude Warren

-  

43Caleb Rackliffecalebrackliffe@gmail.comCaleb Rackliffe

-  

32Mick Semb Wevermck@apache.orgmck

...

  1. Check for new failures on the details page for each branch in the bottom right where it says detailed history:
  2. Look for failing tests without a JIRA link; in the following example see the top test "TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_trunk:
  3. For failing tests without a linked item we have a couple workflows depending on where the commit occurred as well as what type of failure it is:
    1. Single commit on trunk:
      1. If intermittent, create a new JIRA ticket w/"intermittent failure" in the summary for the failure and link it in Butler
      2. If consistent, git revert the SHA that introduced the failure, re-open the original JIRA ticket, and leave a note for the original assignee about the breakage they introduced.
    2. Commit on older LTS branch w/merge commits:
      1. If intermittent, create a new JIRA ticket w/"intermittent failure" in the summary for the failure and link it in Butler
      2. If consistent, create a new JIRA ticket for the failure, link it in Butler, and set assignee to the individual that introduced the failure and notify them in the comments in the JIRA ticket

Build infra:

  • Once a week, run a Circle CI for trunk (todo: maybe this could be automated), or ask someone with highres access to start a build.
  • If there are any build failures due to infra issues (say running out of disk space on Jenkins) either from the weekly cci run or when checking Butler problems, file or find existing JIRA

Notes:

  • Link failures to JIRA via the "Link selected failures" button:
  • Create new failure tickets in the ASF C* JIRA.
  • CI on Jenkins is run on every commit so for consistently failing tests (> 1 run failed on butler) it should be immediately clear which commit introduced the failure.
  • For failures with "Timeout occurred. Please note the time in the report does not reflect the time until the timeout", we can ignore them , as it's considered test-infrastructure failures. And CASSANDRA-18137 is working on this kind of failures already. 

  • [Optional] Loop failing tests locally using tools/dev/ci-test-loop (PENDING CONTRIBUTION), which relies on tools/dev/ci-test (PENDING CONTRIBUTION) for a number of iterations to determine if it's consistent or intermittent. If intermittent, reflect in subject of the created JIRA ticket for the failure.CI on Jenkins is run on every commit so for consistently failing tests (> 1 run failed on butler) it should be immediately clear which commit introduced the failure.