chrome-devtools-frontend 1.0.1515796 → 1.0.1515988

package/docs/contributing/infrastructure.md

@@ -45,7 +45,7 @@ git new-branch branch-name --upstream_current
 - `buckets/ci.star`: configurations to run on the main branch after a CL
   is submitted also known as CI or Waterfall builders.
 - `buckets/ci-hp.star`: configurations for the highly privileged
-builders that rolls dependencies.
+  builders that rolls dependencies.
 
 After you update a `.star` file, re-generate generated files using
 `lucicfg main.star`.
@@ -89,10 +89,10 @@ which builders are needed to verify a CQ. See `custom_locationsfilters`
 for the current logic.
 
 Some of the filters currently in use are:
- - `cpp_debug_extension` builders only trigger on changes related to the extension
- - `dtf_check_no_bundle` builder only trigger on GN changes
- - all other builders will not trigger if only documentation files are updated
 
+- `cpp_debug_extension` builders only trigger on changes related to the extension
+- `dtf_check_no_bundle` builder only trigger on GN changes
+- all other builders will not trigger if only documentation files are updated
 
 ## Branch cutting process
 
@@ -100,17 +100,18 @@ At the end of every release cycle Chromium will cut a new branch for the current
 
 The branch cut process for DevTools is as simple as updating the beta, stable
 and extended branch numbers in infra/config (example [CL](https://crrev.com/c/6850649)):
-  - checkout infra/config branch
-  - pull and create a new branch ([see](#Submitting an infra config change))
-  - update the definitions.star file:
-    - extended number gets updated every second release:
-      - if the extended number is equal to the stable number, then update
-        extended to the current beta number
-      - otherwise update it to the current stable number
-    - stable number updates to the current beta number
-    - beta number updates to the Chromium beta brunch number ([see](https://chromiumdash.appspot.com/branches))
-  - regenrate the cfg files (`lucicfg main.star`), commit, upload and add
-    liviurau@chromium.org as reviewer (or another infra team member)
+
+- checkout infra/config branch
+- pull and create a new branch ([see](#Submitting an infra config change))
+- update the definitions.star file:
+  - extended number gets updated every second release:
+    - if the extended number is equal to the stable number, then update
+      extended to the current beta number
+    - otherwise update it to the current stable number
+  - stable number updates to the current beta number
+  - beta number updates to the Chromium beta brunch number ([see](https://chromiumdash.appspot.com/branches))
+- regenerate the cfg files (`lucicfg main.star`), commit, upload and add
+  liviurau@chromium.org as reviewer (or another infra team member)
 
 Changing these numbers will reconfigure the CI and CQ for [beta](https://ci.chromium.org/p/devtools-frontend/g/beta/console),
 [stable](https://ci.chromium.org/p/devtools-frontend/g/stable/console) and
@@ -119,7 +120,7 @@ After landing the change the three branch consoles will get reset.
 
 ## Toggle tree closing behaviour on CI builders
 
-Sometimes we might need to avoid a misbehaing builder closing the tree. Or maybe
+Sometimes we might need to avoid a misbehaving builder closing the tree. Or maybe
 we need to make a FYI builder a tree closer.
 
 To do so find your builder buckets/ci.star file and toggle the
@@ -130,31 +131,34 @@ Make sure you regenerated the cfg files and upload your changes. [Example](https
 ## Toggle blocking behaviour of CQ builders
 
 CQ builders come in 3 flavors:
-  - regular try builder: will always prevent a CL from landing when the builder
-    fails
-  - includable builder: will run only if expecitly added to a CQ run and will
-    prevent a CL from landing if the builder fails
-  - experimental builder: will run a percentage of the times it gets an
-    oppotunity run and will not block the CL from landing if the builder fails
+
+- regular try builder: will always prevent a CL from landing when the builder
+  fails
+- includable builder: will run only if explicitly added to a CQ run and will
+  prevent a CL from landing if the builder fails
+- experimental builder: will run a percentage of the times it gets an
+  opportunity run and will not block the CL from landing if the builder fails
 
 To toggle this behaviour you need to edit `buckets/try.star` file ([example](https://crrev.com/c/6903181)):
-  - all builders must be enumetated in `cq_builders.devtools_builders` list
-  - to make a builder includable add it's name `cq_builders.includable_only_builders`
-    list; remove it from the list to make it a regular builder
-  - to make a builder experimental add it's name `cq_builders.experiment_builders`
-    dictionary together with the desired experiment rate percentage; remove it
-    from the list to make it a regular builder
+
+- all builders must be enumerated in `cq_builders.devtools_builders` list
+- to make a builder includable add it's name `cq_builders.includable_only_builders`
+  list; remove it from the list to make it a regular builder
+- to make a builder experimental add it's name `cq_builders.experiment_builders`
+  dictionary together with the desired experiment rate percentage; remove it
+  from the list to make it a regular builder
 
 ## Adding a new builder in CQ
 
-To add a new try-builder edit the `buckets/try.start` file to call one of the
+To add a new try-builder edit the [try.start](https://chromium.googlesource.com/devtools/devtools-frontend/+/refs/heads/infra/config/buckets/try.star) file to call one of the
 existing functions that generate builder definitions:
-  - `try_builder` used for builder with recipes that do not orchestrate other
-    builders:
-      - build only builders (`dtf_check_no_bundle`)
-      - chromium builders (`devtools_frontend_linux_blink_light_rel_fastbuild`)
-  - `try_pair` used for builders with orchestrating recipes (delegates to a
-    compilator builder before delegating testing to swarming)
+
+- `try_builder` used for builder with recipes that do not orchestrate other
+  builders:
+  - build only builders (`dtf_check_no_bundle`)
+  - chromium builders (`devtools_frontend_linux_blink_light_rel_fastbuild`)
+- `try_pair` used for builders with orchestrating recipes (delegates to a
+  compilator builder before delegating testing to swarming)
 
 Alternatively define your own builder function and call it for the instances you
 need (see `presubmit_builder` and `cpp_debug_extension_try`).
@@ -168,7 +172,7 @@ builder to `cq_builders.chromium_builders` list.
 
 ## Adding a new builder in CI
 
-To add a new try-builder edit the `buckets/ci.start` file to add a new
+To add a new try-builder edit the [ci.start](https://chromium.googlesource.com/devtools/devtools-frontend/+/refs/heads/infra/config/buckets/ci.star) file to add a new
 `builder_descriptor` to the `builders` of `generate_ci_configs` function call.
 
 In your descriptor decide for the name of builder, the recipe, any other custom
@@ -182,54 +186,55 @@ run the devtools/trybot_tester recipe and are responsible with building DevTools
 Frontend and running our tests.
 
 Below is a detailed description of what happens in such a build:
-  - The recipe will perform the `bot_update` and `gclient runhooks` step where
-    the tip-of-tree for devtools-frontend gets checked out, your changes get
-    patched on top of it and dependencies get updated.
-  - The compilator bot get triggered (`initialization` step)
-  - We wait for the compilator bot to finish. This bot is responsible for
-    the actual build of devtools-frontend.
-       - It does a `bot_update` of its own
-       - Generates the GN files (`gn` step)
-       - Compiles (`compile`) the project
-       - Reads the e2e_non_hosted test lists
-       - Creates a CAS archive with project and the compilation output
-       - Ouputs the `compilator_properties`
-  - Once the compilator is done we read the `compilator_properties` to find
-     - the `cas_digest` to be used when triggering tests on swarming
-     - the `e2e_non_hosted_test_list` for sharding the e2e tests execution
-  - Write the e2e test list at the location where building would have written it
-  - The default test run phase starts at `Run tests` step:
-     - We trigger all tests on swarming in parallel (`Trigger Tests`) substep.
-        - For all types of tests we calculate the command we want to run on swarming
-         and trigger a task with that command and the collected CAS digest
-        - Before calculating the command for e2e test we read the test list and
-         and split it in a number of shards. Each shard will have the allocated
-         tests specified in the command.
-     - We wait for all swarming task to complete
-  - Next we re-run the failed tests in attemt to exonerate their initial
-   failures (`Flake exonaration attempt` step):
-     - We query ResultDB for any tests that might have failed
-     - We collect the failed test names and contruct new commands to re-run
-      them on new swarming tasks
-     - We wait for all swarming task to complete
-  - Finally we will stress test the tests that were added/modified by the
-   current CL in the `Detect flakes in new tests` step
-     - Run `git diff` to determine which tests were added/modifed
-     - Construct the command to be run on swatming
-     - Trigger and wait for the swarming tasks to finish
-  - Calculate the outcome of the builder:
-     - fail the builder if tests failed in the default run and the exoneration
-      run was unsuccesful
-     - fail the builder if tests failed in the deflaking phase
-     - otherwise report build as passing
+
+- The recipe will perform the `bot_update` and `gclient runhooks` step where
+  the tip-of-tree for devtools-frontend gets checked out, your changes get
+  patched on top of it and dependencies get updated.
+- The compilator bot get triggered (`initialization` step)
+- We wait for the compilator bot to finish. This bot is responsible for
+  the actual build of devtools-frontend.
+  - It does a `bot_update` of its own
+  - Generates the GN files (`gn` step)
+  - Compiles (`compile`) the project
+  - Reads the e2e_non_hosted test lists
+  - Creates a CAS archive with project and the compilation output
+  - Outputs the `compilator_properties`
+- Once the compilator is done we read the `compilator_properties` to find
+  - the `cas_digest` to be used when triggering tests on swarming
+  - the `e2e_non_hosted_test_list` for sharding the e2e tests execution
+- Write the e2e test list at the location where building would have written it
+- The default test run phase starts at `Run tests` step:
+  - We trigger all tests on swarming in parallel (`Trigger Tests`) substep.
+    - For all types of tests we calculate the command we want to run on swarming
+      and trigger a task with that command and the collected CAS digest
+    - Before calculating the command for e2e test we read the test list and
+      and split it in a number of shards. Each shard will have the allocated
+      tests specified in the command.
+  - We wait for all swarming task to complete
+- Next we re-run the failed tests in attempt to exonerate their initial
+  failures (`Flake exoneration attempt` step):
+  - We query ResultDB for any tests that might have failed
+  - We collect the failed test names and construct new commands to re-run
+    them on new swarming tasks
+  - We wait for all swarming task to complete
+- Finally we will stress test the tests that were added/modified by the
+  current CL in the `Detect flakes in new tests` step
+  - Run `git diff` to determine which tests were added/modified
+  - Construct the command to be run on swarming
+  - Trigger and wait for the swarming tasks to finish
+- Calculate the outcome of the builder:
+  - fail the builder if tests failed in the default run and the exoneration
+    run was unsuccessful
+  - fail the builder if tests failed in the deflaking phase
+  - otherwise report build as passing
 
 ### Common build failures
 
-The first place where a build usualy fails is on `bot_update` and this usually
+The first place where a build usually fails is on `bot_update` and this usually
 happens because your changes cannot be applied on top of the current tip-of-tree.
 Rebase your CL and solve any merge conflicts and this failure will go away.
 
-Another common failure is a compilation failure. You can insepct the compilator
+Another common failure is a compilation failure. You can inspect the compilator
 builder (`dtf_*_compiler_rel`) separately by following the link next to the
 `compilator steps` step.
 
@@ -237,9 +242,53 @@ If you have too many tests failing in the default phase the exoneration phase
 gets skipped.
 
 A test might not get exonerated in your build even if your CL does not touch
-anything related to it. The exoneration phase will re-run previously faling
+anything related to it. The exoneration phase will re-run previously failing
 tests a number of times and at any point the test passes the tests gets
 exonerated. Therefore a test can have a recent history of getting exonerated
-even if it consitently failed 4 times out of 5 runs for some time. Try to
-correlate your failure with a luci-analysys report on this test and skip it
-untill the flakiness gets resolved.
+even if it consistently failed 4 times out of 5 runs for some time. Try to
+correlate your failure with a luci-analysis report on this test and skip it
+until the flakiness gets resolved.
+
+## Luci Analysis configuration
+
+[Luci Analysis](go/luci-analysis) is a tool that helps you understand the
+impact of test failures.
+
+You can find the DevTools configuration in [luci-analysis.cfg](https://chromium.googlesource.com/devtools/devtools-frontend/+/refs/heads/infra/config/luci-analysis.cfg).
+
+We configure the rules for test failure clustering based on _file_/_suite_ and
+_testcase_ names.
+
+A policy named `too-many-failures` is defined in the configuration with
+activation/deactivation thresholds and a bug template to be used when creating
+a new bug. The bugs will be automatically created in Buganizer on the configured
+default component (or on the component specified in a `DIR_METADATA` file on the
+ancestor path of the failing test file).
+
+After updating the `luci-analysis.cfg` file make sure you run `lucicfg main.star` to
+refresh the copy of this file in the `generated/` folder.
+
+## Autorollers
+
+### Rolling DevTools to Chromium
+
+A [Skia autoroller](https://skia.googlesource.com/buildbot/+/main/autoroll/README.md)
+is responsible for rolling DevTools to Chromium. Follow the links to inspect the
+[status](https://autoroll.skia.org/r/devtools-frontend-chromium?tab=status) of
+the roller.
+
+To update the configuration you will need to clone the skia [repo](sso://skia/skia-autoroll-internal-config)
+and modify the `skia-infra-public/devtools-frontend-chromium.cfg` file ([example](https://review.skia.org/1014616)).
+
+### Rolling dependencies to DevTools
+
+To roll all DevTool's dependencies we rely on the [Roll deps and chromium pin
+into devtools-frontend](https://ci.chromium.org/ui/p/devtools-frontend/builders/ci-hp/Roll%20deps%20and%20chromium%20pin%20into%20devtools-frontend)
+builder that runs on the [infra](https://ci.chromium.org/ui/p/devtools-frontend/g/infra/builders)
+console.
+
+The builder is scheduled to run every day at 05 and 14 hours. In the [recipe](https://source.chromium.org/chromium/infra/infra_superproject/+/main:build/recipes/recipes/devtools/auto_roll_incoming.py?q=file:recipes%2Fdevtools%2Fauto_roll_incoming.py)
+that runs on this builder you can configure dependencies that you need excluded
+from the rolls and reviewer emails. The recipe uses the V8's autorolling rolling
+[module](https://source.chromium.org/chromium/infra/infra_superproject/+/main:build/recipes/recipe_modules/v8_auto_roller/api.py),
+that offers support for trusted and untrusted dependencies ([regular](https://source.chromium.org/chromium/infra/infra_superproject/+/main:build/recipes/recipe_modules/v8_auto_roller/deps_handlers.py)), [CfT](https://source.chromium.org/chromium/infra/infra_superproject/+/main:build/recipes/recipe_modules/v8_auto_roller/chrome_handler.py) pin rolling, and [script based](https://source.chromium.org/chromium/infra/infra_superproject/+/main:build/recipes/recipe_modules/v8_auto_roller/script_handlers.py) special rolls.

package/front_end/Tests.js

@@ -1,32 +1,6 @@
-/*
- * Copyright (C) 2010 Google Inc. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are
- * met:
- *
- *     * Redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer.
- *     * Redistributions in binary form must reproduce the above
- * copyright notice, this list of conditions and the following disclaimer
- * in the documentation and/or other materials provided with the
- * distribution.
- *     * Neither the name of Google Inc. nor the names of its
- * contributors may be used to endorse or promote products derived from
- * this software without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
- * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
- * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
+// Copyright 2010 The Chromium Authors
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
 
 /**
  * @file This file contains small testing framework along with the

package/front_end/core/common/Progress.ts

@@ -2,20 +2,20 @@
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
-export class Progress {
-  setTotalWork(_totalWork: number): void {
-  }
-  setTitle(_title: string): void {
-  }
-  setWorked(_worked: number, _title?: string): void {
-  }
-  incrementWorked(_worked?: number): void {
-  }
-  done(): void {
-  }
-  isCanceled(): boolean {
-    return false;
-  }
+export interface Progress {
+  totalWork: number;
+  worked: number;
+  title: string|undefined;
+  canceled: boolean;
+  done: boolean;
+}
+
+export class Progress implements Progress {
+  totalWork = 0;
+  worked = 0;
+  title: string|undefined = undefined;
+  canceled = false;
+  done = false;
 }
 
 export class CompositeProgress {
@@ -27,15 +27,15 @@ export class CompositeProgress {
     this.parent = parent;
     this.#children = [];
     this.#childrenDone = 0;
-    this.parent.setTotalWork(1);
-    this.parent.setWorked(0);
+    this.parent.totalWork = 1;
+    this.parent.worked = 0;
   }
 
   childDone(): void {
     if (++this.#childrenDone !== this.#children.length) {
       return;
     }
-    this.parent.done();
+    this.parent.done = true;
   }
 
   createSubProgress(weight?: number): SubProgress {
@@ -50,12 +50,12 @@ export class CompositeProgress {
 
     for (let i = 0; i < this.#children.length; ++i) {
       const child = this.#children[i];
-      if (child.getTotalWork()) {
-        done += child.getWeight() * child.getWorked() / child.getTotalWork();
+      if (child.totalWork) {
+        done += child.weight * child.worked / child.totalWork;
       }
-      totalWeights += child.getWeight();
+      totalWeights += child.weight;
     }
-    this.parent.setWorked(done / totalWeights);
+    this.parent.worked = done / totalWeights;
   }
 }
 
@@ -72,45 +72,41 @@ export class SubProgress implements Progress {
     this.#totalWork = 0;
   }
 
-  isCanceled(): boolean {
-    return this.#composite.parent.isCanceled();
+  get canceled(): boolean {
+    return this.#composite.parent.canceled;
   }
 
-  setTitle(title: string): void {
-    this.#composite.parent.setTitle(title);
+  set title(title: string) {
+    this.#composite.parent.title = title;
   }
 
-  done(): void {
-    this.setWorked(this.#totalWork);
+  set done(done: boolean) {
+    if (!done) {
+      return;
+    }
+    this.worked = this.#totalWork;
     this.#composite.childDone();
   }
 
-  setTotalWork(totalWork: number): void {
+  set totalWork(totalWork: number) {
     this.#totalWork = totalWork;
     this.#composite.update();
   }
 
-  setWorked(worked: number, title?: string): void {
+  set worked(worked: number) {
     this.#worked = worked;
-    if (typeof title !== 'undefined') {
-      this.setTitle(title);
-    }
     this.#composite.update();
   }
 
-  incrementWorked(worked?: number): void {
-    this.setWorked(this.#worked + (worked || 1));
-  }
-
-  getWeight(): number {
+  get weight(): number {
     return this.#weight;
   }
 
-  getWorked(): number {
+  get worked(): number {
     return this.#worked;
   }
 
-  getTotalWork(): number {
+  get totalWork(): number {
     return this.#totalWork;
   }
 }
@@ -118,45 +114,67 @@ export class SubProgress implements Progress {
 export class ProgressProxy implements Progress {
   readonly #delegate: Progress|null|undefined;
   readonly #doneCallback: (() => void)|undefined;
-  constructor(delegate?: Progress|null, doneCallback?: (() => void)) {
+  readonly #updateCallback: (() => void)|undefined;
+
+  constructor(delegate?: Progress|null, doneCallback?: (() => void), updateCallback?: (() => void)) {
     this.#delegate = delegate;
     this.#doneCallback = doneCallback;
+    this.#updateCallback = updateCallback;
   }
 
-  isCanceled(): boolean {
-    return this.#delegate ? this.#delegate.isCanceled() : false;
+  get canceled(): boolean {
+    return this.#delegate ? this.#delegate.canceled : false;
   }
 
-  setTitle(title: string): void {
+  set title(title: string) {
     if (this.#delegate) {
-      this.#delegate.setTitle(title);
+      this.#delegate.title = title;
+    }
+    if (this.#updateCallback) {
+      this.#updateCallback();
     }
   }
 
-  done(): void {
+  get title(): string {
+    return this.#delegate?.title ?? '';
+  }
+
+  set done(done: boolean) {
     if (this.#delegate) {
-      this.#delegate.done();
+      this.#delegate.done = done;
     }
-    if (this.#doneCallback) {
+    if (done && this.#doneCallback) {
       this.#doneCallback();
     }
   }
 
-  setTotalWork(totalWork: number): void {
-    if (this.#delegate) {
-      this.#delegate.setTotalWork(totalWork);
-    }
+  get done(): boolean {
+    return this.#delegate ? this.#delegate.done : false;
   }
 
-  setWorked(worked: number, title?: string): void {
+  set totalWork(totalWork: number) {
     if (this.#delegate) {
-      this.#delegate.setWorked(worked, title);
+      this.#delegate.totalWork = totalWork;
     }
+    if (this.#updateCallback) {
+      this.#updateCallback();
+    }
+  }
+
+  get totalWork(): number {
+    return this.#delegate ? this.#delegate.totalWork : 0;
   }
 
-  incrementWorked(worked?: number): void {
+  set worked(worked: number) {
     if (this.#delegate) {
-      this.#delegate.incrementWorked(worked);
+      this.#delegate.worked = worked;
     }
+    if (this.#updateCallback) {
+      this.#updateCallback?.();
+    }
+  }
+
+  get worked(): number {
+    return this.#delegate ? this.#delegate.worked : 0;
   }
 }

package/front_end/core/host/UserMetrics.ts

@@ -793,7 +793,6 @@ export enum DevtoolsExperiments {
   'just-my-code' = 65,
   'use-source-map-scopes' = 76,
   'timeline-show-postmessage-events' = 86,
-  'timeline-save-as-gz' = 108,
   'timeline-enhanced-traces' = 90,
   'timeline-compiled-sources' = 91,
   'timeline-debug-mode' = 93,

package/front_end/core/protocol_client/InspectorBackend.ts

@@ -155,12 +155,14 @@ let connectionFactory: () => Connection;
 export class Connection {
   declare onMessage: ((arg0: Object) => void)|null;
 
+  // on message from browser
   setOnMessage(_onMessage: (arg0: Object|string) => void): void {
   }
 
   setOnDisconnect(_onDisconnect: (arg0: string) => void): void {
   }
 
+  // send raw CDP message to browser
   sendRawMessage(_message: string): void {
   }
 

package/front_end/core/root/Runtime.ts

@@ -326,7 +326,6 @@ export const enum ExperimentName {
   TIMELINE_DEBUG_MODE = 'timeline-debug-mode',
   TIMELINE_ENHANCED_TRACES = 'timeline-enhanced-traces',
   TIMELINE_COMPILED_SOURCES = 'timeline-compiled-sources',
-  TIMELINE_SAVE_AS_GZ = 'timeline-save-as-gz',
   // Adding or removing an entry from this enum?
   // You will need to update:
   // 1. REGISTERED_EXPERIMENTS in EnvironmentHelpers.ts (to create this experiment in the test env)