Yocto Build Failure Swat Team: Difference between revisions

From Yocto Project
Jump to navigationJump to search
No edit summary
Line 3: Line 3:
The role of the SWAT team is to monitor the autobuilder and investigate all failures to ensure that they are logged and brought to the attention of the appropriate owner.
The role of the SWAT team is to monitor the autobuilder and investigate all failures to ensure that they are logged and brought to the attention of the appropriate owner.


All builds that are run on the [https://autobuilder.yoctoproject.org public autobuilder] are important for the Yocto Project, whether they be a post-merge validation run (for master or a release branch) or a pre-merge test build (for master-next, ross/mut, and others).
All builds that are run on the [https://autobuilder.yoctoproject.org public autobuilder] are important for the Yocto Project, whether they be a post-merge validation run (for master or a release branch) or a pre-merge test build (for master-next, ross/mut, and others).  SWAT doesn't cover company-internal autobuilders.


Every build should be monitored by the SWAT team unless the [[BuildLog]] entry for that build indicates otherwise.  SWAT is opt-out by whomever triggers a build on the autobuilder, not opt-in.
Every build should be monitored by the SWAT team unless the [[BuildLog]] entry for that build indicates otherwise.  SWAT is opt-out by whomever triggers a build on the autobuilder, not opt-in.
Line 30: Line 30:


The results of pre-triage for an issue should be added to the corresponding entry in the [[BuildLog]], including a link to the resolution (patch name, bug link, etc) and a brief summary of the issue.  Every issue should be added to the build log so it acts as a build status report.
The results of pre-triage for an issue should be added to the corresponding entry in the [[BuildLog]], including a link to the resolution (patch name, bug link, etc) and a brief summary of the issue.  Every issue should be added to the build log so it acts as a build status report.


=== Filing bugs ===
=== Filing bugs ===


When filing the bug, please:
When filing the bug two things are required:
* cut and paste the relevant error in the bug comment, and include the log file as an attachment
* A link to the build failure.  This can either be the build page (such as https://autobuilder.yoctoproject.org/typhoon/#/builders/34/builds/168) or the [http://errors.yoctoproject.org/Errors/ error reports] page (such as http://errors.yoctoproject.org/Errors/Details/199667/).
* include the log from the ''CreateAutoConf'' step as an attachment (this ensures the assignee and triage team can quickly asses this issue)
* The error itself. Trim the log down to just the error and any relevant context in the bug description, and also attach the complete log file. Autobuilder logs are not persistent so the full log must be attached.
* include a pointer to the [http://errors.yoctoproject.org ErrorLog] page associated with the failure (as ErrorLog)
 
{| style="color:black; background-color:#b8ddff" width="100%" cellpadding="10" class="wikitable"
|'''Note''': Autobuilder logs are non-persistent, feel free to include a link to the log in a bug report but be sure to ''also'' attach a copy of the log and include relevant sections copy/pasted into the bug.
|}
{| style="color:black; background-color:#b8ddff" width="100%" cellpadding="10" class="wikitable"
|'''Note''': Sometimes, failures occur on autobuilders on private company networks. Do not post links into the bugzilla for these failures as nobody else can access them.
|}


=== Process summary ===
=== Process summary ===


* Monitor builds via one (or more) of:
* Monitor builds via one or more of:
** the autobuilder: [https://autobuilder.yoctoproject.org/typhoon/ main page], [https://autobuilder.yoctoproject.org/typhoon/#/console console view].
** the autobuilder: [https://autobuilder.yoctoproject.org/typhoon/ main page], [https://autobuilder.yoctoproject.org/typhoon/#/console console view].
** the [[BuildLog]] wiki page
** the [[BuildLog]] wiki page
** the [https://lists.yoctoproject.org/listinfo/yocto-builds yocto-builds] mailing list
** the [https://lists.yoctoproject.org/listinfo/yocto-builds yocto-builds] mailing list
* Pre-triage each failure:
* Pre-triage each failure:
** File a bugzilla ticket ''OR'' respond to a patch ''OR'' note known issues
** File a bug ''or'' respond to a patch ''or'' note known issues
** Update the [[BuildLog]] with the result of pre-triage, linking to issues/mail archives when possible
** Update the [[BuildLog]] with the result of pre-triage, linking to the resolution where possible.


== Questions / Contact ==
== Questions / Contact ==

Revision as of 12:38, 13 November 2018

Overview

The role of the SWAT team is to monitor the autobuilder and investigate all failures to ensure that they are logged and brought to the attention of the appropriate owner.

All builds that are run on the public autobuilder are important for the Yocto Project, whether they be a post-merge validation run (for master or a release branch) or a pre-merge test build (for master-next, ross/mut, and others). SWAT doesn't cover company-internal autobuilders.

Every build should be monitored by the SWAT team unless the BuildLog entry for that build indicates otherwise. SWAT is opt-out by whomever triggers a build on the autobuilder, not opt-in.

SWAT isn't responsible for resolving any issues encountered on the autobuilder. Their focus is on performing minimal analysis of a failure in order to ensure that it is logged and brought to the attention of a appropriate owner, a process we'll refer to as pre-triage.

Roles

Active member: the currently active member of the SWAT team is expected to monitor the autobuilder and pre-triage failures in a timely fashion. Team members are active for one week at a time and rotation is usually simple round robin through the members list. If for some reason the next person isn't available then they can be skipped.

SWAT Chair: the SWAT chair provides backup cover for the active member and is a first point of contact for SWAT. Ross Burton is the current SWAT Chair.

SWAT Facilitator: the SWAT facilitator is responsible for managing the rotation process. Stephen K. Jolley is the current SWAT Facilitator.

Process

The BuildLog wiki page is automatically updated by the autobuilder when a new build is triggered. This often includes guidance for SWAT (the "Reason" field when triggering the build) such as to ignore it (if the build is expected to break and the owner is monitoring themselves) or a request to report failures straight to a specific person (if the build only contains changes from a single person, such as a GCC upgrade). Unless when told otherwise, the usual process is as follows:

For builds against master or a release branch, any issues observed should be filed in Bugzilla.

For builds against other branches (master-next, ross/mut, -next branches for stable releases, etc.), attempt to identify what patch in the branch is likely responsible for the failure. For example, if wget fails with libgnutls errors and there is a GnuTLS upgrade in the branch, that is the likely candidate. If a patch can be identified that isn't also in master or release branch, reply on the mailing list with the failure details. If it isn't obvious which patch is responsible for the failure then file a bug and ensure the branch owner is either the assignee or on the CC list.

If in doubt, file a bug. All observed errors must be actioned unless a patch has already been sent for the issue, in which case please make note of this in the BuildLog.

If the issue is in the infrastructure or autobuilder itself then file a bug against , infrastructure bugs should be assigned to Michael Halstead and autobuilder logic bugs to Richard Purdie.

The results of pre-triage for an issue should be added to the corresponding entry in the BuildLog, including a link to the resolution (patch name, bug link, etc) and a brief summary of the issue. Every issue should be added to the build log so it acts as a build status report.

Filing bugs

When filing the bug two things are required:

Process summary

  • Monitor builds via one or more of:
  • Pre-triage each failure:
    • File a bug or respond to a patch or note known issues
    • Update the BuildLog with the result of pre-triage, linking to the resolution where possible.

Questions / Contact

If you have queries about the SWAT process you may reach out to the SWAT Facilitator Stephen K. Jolley or the SWAT Chair Ross Burton.

Members

  • Paul Eggleton (NZ)
  • Ross Burton (UK)
  • Amanda Brindle (US)
  • Chen Qi (CN)
  • Armin Kuster (California)