9456eca7c5
Adds better caching for browser archives and their extraction. This is done because the archives are currently extracted as a build action and these are actions are invalidated frequently, causing flakiness on the CI and slow-down in local development. Here is an example flaky error on the CI (that surfaces often with RBE execution): ``` ERROR: /home/circleci/.cache/bazel/_bazel_circleci/9ce5c2144ecf75d11717c0aa41e45a8d/external/npm/@angular/dev-infra-private/bazel/browsers/chromium/BUILD.bazel:22:17: Extracting ../org_chromium_chromium_amd64/file/chrome-linux.zip failed: (Exit 34): extract.sh failed: error executing command external/io_bazel_rules_webtesting/web/internal/extract.sh external/org_chromium_chromium_amd64/file/chrome-linux.zip ... (remaining 2 argument(s) skipped). Note: Remote connection/protocol failed with: execution failed ``` We fix this by introducing a new rule that downloads a browser archive and unpacks it directly into a Bazel repository. Before this change, the archive would just be downloaded but extracted later as part of a build action. This is unnecessary and results in less efficient caching as build actions are invalidated more often, especially if developers run `bazel clean` in between. The root cause on why the extraction often fails in RBE containers is unclear. It's unclear why the extacted archive is not cached properly as part of a build action (most likely some hermeticity issue within `rules_webtesting`, but it seems more Bazel-idiomatic to unpack the archives as part of the repository anyway, and this solves the flakiness issue. PR Close #42814
117 lines
3.9 KiB
Python
117 lines
3.9 KiB
Python
# BEGIN-INTERNAL
|
|
load("@build_bazel_rules_nodejs//:index.bzl", "pkg_npm")
|
|
load("//dev-infra:defaults.bzl", "ng_dev_rolled_up_generated_file", "ts_library")
|
|
# END-INTERNAL
|
|
|
|
exports_files(["tsconfig.json"])
|
|
|
|
# BEGIN-INTERNAL
|
|
ts_library(
|
|
name = "cli",
|
|
srcs = [
|
|
"cli.ts",
|
|
],
|
|
deps = [
|
|
"//dev-infra/caretaker",
|
|
"//dev-infra/commit-message",
|
|
"//dev-infra/format",
|
|
"//dev-infra/misc",
|
|
"//dev-infra/ngbot",
|
|
"//dev-infra/pr",
|
|
"//dev-infra/pullapprove",
|
|
"//dev-infra/release",
|
|
"//dev-infra/ts-circular-dependencies",
|
|
"//dev-infra/utils",
|
|
"@npm//@types/node",
|
|
"@npm//@types/yargs",
|
|
"@npm//yargs",
|
|
],
|
|
)
|
|
|
|
genrule(
|
|
name = "package-json",
|
|
srcs = [
|
|
"tmpl-package.json",
|
|
"//:package.json",
|
|
],
|
|
outs = ["package.json"],
|
|
cmd = """
|
|
$(execpath //tools:inline-package-json-deps) $(execpath tmpl-package.json) \
|
|
$(execpath //:package.json) $@
|
|
""",
|
|
tools = ["//tools:inline-package-json-deps"],
|
|
)
|
|
|
|
pkg_npm(
|
|
name = "npm_package",
|
|
srcs = [
|
|
# Main bazel entry-point for the shared `dev-infra` package.
|
|
"index.bzl",
|
|
"BUILD.bazel",
|
|
# Some tools within `dev-infra` which are shipped as Bazel rules might
|
|
# rely on a tsconfig file. We bring the config into the NPM package.
|
|
"tsconfig.json",
|
|
"//dev-infra/bazel:files",
|
|
"//dev-infra/benchmark:files",
|
|
],
|
|
substitutions = {
|
|
# angular/angular should not consume it's own packages, so we use
|
|
# substitutions to replace these in the published version of dev-infra.
|
|
"@angular//dev-infra/": "@npm//@angular/dev-infra-private/",
|
|
"//dev-infra/": "@npm//@angular/dev-infra-private/",
|
|
"//dev-infra:": "@npm//@angular/dev-infra-private:",
|
|
|
|
# Substitutions needed for `//dev-infra/benchmark`:
|
|
"//packages/benchpress": "@npm//@angular/benchpress",
|
|
"//packages/bazel": "@npm//@angular/bazel",
|
|
"//packages/zone.js/bundles:zone.umd.js": "@npm//zone.js",
|
|
"//packages/core": "@npm//@angular/core",
|
|
"//packages/platform-browser": "@npm//@angular/platform-browser",
|
|
# This substitution is particularly verbose because we need to make sure
|
|
# that only things available via Angular Bazel are imported from
|
|
# tools/defaults.bzl.
|
|
"load\\(\"//tools:defaults.bzl\", \"ng_module\"\\)": "load(\"@npm//@angular/bazel:index.bzl\", \"ng_module\")",
|
|
},
|
|
visibility = ["//visibility:public"],
|
|
deps = [
|
|
":cli",
|
|
":package-json",
|
|
"//dev-infra/benchmark/driver-utilities",
|
|
"//dev-infra/commit-message",
|
|
"//dev-infra/ts-circular-dependencies",
|
|
"//dev-infra/tslint-rules",
|
|
],
|
|
)
|
|
|
|
# Because the angular/angular repository relies on the local repository for running ng-dev commands,
|
|
# the rollup generated javascript files are committed into the repository to be used as node
|
|
# scripts. To ensure they stay up to date, they are created using a generated file test.
|
|
#
|
|
# Currently there are two generated files which are needed
|
|
# ng-dev.js - The main script representing ng-dev
|
|
# build-worker.js - The worker script for the `ng-dev release build` command, allowing it to run
|
|
# in a forked process.
|
|
ng_dev_rolled_up_generated_file(
|
|
name = "ng-dev",
|
|
entry_point = ":cli.ts",
|
|
rollup_args = [
|
|
"--plugin",
|
|
"rollup-plugin-hashbang",
|
|
],
|
|
deps = [
|
|
":cli",
|
|
# TODO(josephperrott): Determine if this plugin is the best method for ensuring the hashbang
|
|
# in both local and published use case.
|
|
"@npm//rollup-plugin-hashbang",
|
|
],
|
|
)
|
|
|
|
ng_dev_rolled_up_generated_file(
|
|
name = "build-worker",
|
|
entry_point = "//dev-infra/release/build:build-worker.ts",
|
|
deps = [
|
|
"//dev-infra/release/build",
|
|
],
|
|
)
|
|
# END-INTERNAL
|