THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
The Build Lead role is inspired by the "Build Baron" role used in mongodb (see whitepaper section 3.2 here). While their role began as a performance regression and change point analysis triage role, ours comes from a perspective of triaging test failure and database correctness and may evolve into a performance regression and change point triage role in the future.
Rotation
The Build Lead role is a volunteer role with weekly rotations.
| Date Range | Name | #cassandra-dev slack | |
|---|---|---|---|
Tools
Butler: dashboard of historical test failures and per-test build history failure details w/JIRA links (see trunk here)
...
CircleCI: optionally paid for testing infrastructure (pay for parallel. See .circleci/generate.sh for details on profiles and usage)
Workflow
Weekly:
- Enter: handoff call w/previous build lead
- Exit: handoff to next build lead
- Coordinate with release manager if any releases are happening that week
...
- Check if there are new test failures in Butler that don't yet exist in JIRA (i.e. butler test failures w/out a JIRA link)
- Create JIRA tickets for new failures and link them to the failure entries in Butler
- Assign test failure JIRA to whomever introduced a new failing test or, if clear, broke an existing stable test
- Hit the #cassandra-dev slack channel for volunteers for any new test failures that show up we can't trivially find attribution for
Details
Using butler:
Currently butler functionality is limited to viewing the current test results and linking failures to existing JIRA tickets; the "Report selected failures" functionality does not currently work with the Apache JIRA project (as of ). The recommended workflow as Build Lead is as follows:
...