The release signal team maintains two project boards throughout the release cycle. These boards are set up by the release signal lead and are maintained by the entire release signal team. The CI Signal Project Board keeps track of the failures and flakes on the testgrid dashboards. In contrast, the Bug Triage Board tracks the current status of all issues and PRs targeting the release, their priorities, and to distribute the work amongst the team.
The CI component of the team is using GitHub project board to track the currently failing and flaking tests across various testgrid dashboards.
Release Signal team members are expected to observe the testgrid dashboards and create issues, and add them to the GitHub project board. You may create issues from the board or add them later. This board acts as a single point of reference for the current state of the CI and is referred to by both the general public and the release management team. Issues directly created in the kubernetes/kubernetes repository are not directly added to the board; they need to be manually added.
The CI component of the release signal team only looks at the dashboard mentioned in this document, failures on other boards, if important and not mentioned may go unnoticed by the team.
The release signal team members set the following items for each issue. Some are automatically populated when you create issues through the project board itself.
Status: One of the following values:NEW: Default category when an item is added to this board (defined in the workflow)CRITICAL: Indicates that the item is of critical priority. Consider addingpriority/critical-urgentlabel tooFAILING: Indicates that the issue is about a failing testFLAKY: Indicates that the issue is about a flaking testINVESTIGATING: Default category when an item is re-opened in this board (defined in the workflow)OBSERVING: Indicates that the test mentioned in the issue is under observationRESOLVED: Default category when an item is closed in this board (defined in the workflow)PASSING: Indicates that the test mentioned in the issue is passing
Testgrid Board: Indicates the board that the failing test is a part of i.e.master-blocking,master-informingor bothK8s Release: Signifies the release version this issue is targeting, consider setting themilestonelabel tooTestgrid URL: The URL of the testgrid jobDate: Date of addition to the boardCI Signal Member: The CI Signal member tracking the issueSlack discussion link: The slack discussion link in the #release-ci-signal channel or the SIG/WG channelview: The view of the board, single value, added for future modifications:issue-tracking: The item is part of currently tracked issues
- Copy the prior project board as it has some settings related to Workflows, fields, grouping, etc that help with some basic automation and the look and feel (you can look at the past Workflows in prior tabs).
- You need to add a new option to the field
K8s Releaseto add and view items being tracked in the current release.
- Your new board will need to have the filter updated (see red line below) to make sure it is pulling in issues tagged with the proper release.
The Bug Triage component of the team is using a GitHub project board to track the current status of all issues and PRs targeting the release, their priorities, and to distribute the work amongst the team.
Release Signal team members are expected to assign themselves as the Responsible person to track an issue to the extent of their
time availability throughout the cycle. The release signal team should keep an eye on the board for new issues/PRs and make sure
they are tracked.
The project board is public so that both the release team and anyone interested from the community can stay updated about the current status of issues and PRs that are targetting the release. Write access to the board is limited to members of @kubernetes/release-team-bug-triage.
New issues and PRs that target the current release milestone are automatically added to the board with a a prow job. The prow job is defined in kubernetes/test-infra and the script can be found in kubernetes/sig-release.
For each board item, the following details are set and managed by the release signal team:
Responsible: The release signal team member that is responsible for tracking the progress on the issue/PR. This is not the same as the issue assignee.Notes: Short note by the release signal team member regarding the issue/PR, e.g.[6/3] No progress made since last comment; notified them about the code freezeStatus: One of the following values:Tracked: a member of the release signal team is actively tracking the issuePending inclusion: the issue is not actively tracked by anyone yetAt Risk: the issue is marked asat-riskand might not make the releaseRelease Blocker: the issue is marked as arelease-blockerDone: work on the issue is complete and all pull requests have been merged
Priority: This should match thepriority/*label that is currently assigned to the issue or PRFixes: This should match thekind/*label that is currently assigned to the issue or PR
The following details for each item can be seen on the board. Editing the fields below from the board should be avoided (and for some it might not even be possible):
Title: Issue/PR titleType: Issue or Pull RequestMilestone: The milestone that the issue/PR is targeting. This should be the current releaseLabels: Issue/PR labels, mostly useful to identifykindandpriorityof each item
The bug triage board has a number of views to simplify issue management.
- Bug Triage shows all open issues and PRs for the current milestone
- Bug Triage (Filter by Responsible) shows all open issues and PRs, grouped by the Release Signal team member that is responsible for them
- Issues shows all open issues for the current milestone
- PR shows all open PRs for the current milestone
- Release Blocker shows all issues and PRs that are marked as release blockers
- By Priority shows all open issues and PRs, grouped by priority
- ALL shows all issues and PRs on the board
At the beginning of the cycle, the Release Signal Lead should prepare the bug triage board for the ongoing release cycle. The following steps should be taken:
- Edit bug triage board name for current cycle, e.g.
[sig-release] 1.xx bug-triage - Update the milestone for the periodic prow job. Example PR from 1.28
- Edit the Responsible field and add the new Release Signal team members
- Update the milestone filter to
milestone:v1.xxin all relevant views. You can do this by editing the filter and then clickingSave - Set the
Statusfield toPending inclusionvalue for all open issues and PRs targeting the current milestone to indicate that no one is responsible yet at the beginning of the cycle. Later, any Release Signal member picking up the issue/PR should set it toTracked.