Previously we used a configuration flag for adev, instead we now separate into two different targets since our flag didn't
need to cause a full reanalysis to run since everything before the final target should be a cache hit.
PR Close#63845
This commit adds `lockfile_mode=error` to the `.bazelrc` file. This change ensures that any future builds will fail if the lock file is not up-to-date with the `BUILD.bazel` file, preventing inconsistencies and encouraging developers to commit updated lock files.
PR Close#63260
Instead of disabling sandbox/workers for every action; which also could
slow-down development turnaround significantly, the flag should only
disable sandboxing for the test actions; allowing for e.g. DevTools to
connect to them, even if they are inside the sandbox.
Arguably, this strategy isn't seemingly necessary in all environments,
but given that we enable network sandboxing in this repo, it seems
reasonable. Ideally we'd also expose `_debug` targets for e.g. Node
tests that have the proper no-sandbox, or requires-network tag.
PR Close#61468
This is necessary for an incremental migration to `rules_js` which
requires Bazel v6. Bazel v6 removed the managed directories feature,
which means we no longer can rely on symlinked node modules as the Bazel
repository; but rather need to duplicate dependencies. This is
okay/acceptable to enable the incremental migration.
PR Close#61087
This should help with network issues of spawned RBE actions. It should
also introduce timeouts when actions couldn't be spawned in a timely
manner.
PR Close#60355
We removed display of the Git SHA in Angular DevTools in https://github.com/angular/angular/pull/55694, so there is no longer a need to stamp release builds in Chrome or Firefox.
I opted to leave a `--config snapshot-build-firefox` option as a no-op which a reader could follow to a comment explaining exactly _why_ we can't stamp Firefox releases. This should hopefully make it less likely that we forget and attempt to re-add this feature in the future only to encounter the same release problems.
PR Close#55717
Creates a "fast mode" for building the adev site, currently only disabling prerender during fast build.
This is intended to be used for local development.
PR Close#54364
We've recently marked the ngtsc test as flaky for the Windows
job. We should not attempt running tests 3 times locally. This
negatively impacts the debugging/developer workflow.
Instead, flaky test attempts can still be made on CI. Using the
default attempt count of 3.
PR Close#50852
The experimental allow tags propagation flag is a `BuildLanguage` option
and causes all Starlark code to be re-invoked. This causes a slow-down
when switching between bazel query/ bazel build because the option is not set for `bazel query`.
We fix it by applying the option to all commands, using `common`.
PR Close#49106
The `.bazelrc` workspace file attempted to imported the `.bazelrc.user`
file. This user file is set on CI to include the CI specific Bazel
settings.
Apparently this user rc import does not work, and fails silently given
the `try-import`. It fails because for AIO Bazel commands we change
the working directory using `yarn --cwd aio` and the `try-import`
is relative to the working directory..
PR Close#48316
The dev-infra build tooling is now decoupled from `ng-dev`. This will
make it easier to update `ng-dev` without necessarily needing to upgrade
the whole build system, Bazel etc. This is useful when e.g. new release
tool features have been added and should also be ported to active LTS
branches.
PR Close#46976
Sets up the Bazel integration test with the new integration rule. This
commit is separate from the other changes because it required some
additional work. i.e.
The test has moved from `integration/bazel` to `integration/<..>/bazel`
where `<..>` is a new Bazel package defining the integration test.
This is necessary because we could not declare the integration test
within the `BUILD.bazel` file actually being part of the nested bazel
workspace. In those cases we can just define it at a higher-level and
use integration test `working_dir` attribute.
PR Close#44238
The `integration/bazel` folder cannot be excluded within the
`.bazelignore` file. This is necessary so that the integration test
rule can glob for all files within the integration test.
The downside is that the `integration/bazel/<..>` folder is being
discovered by the `//...` target query, causing Starlark files to
be interpreted/validated. e.g.
https://app.circleci.com/pipelines/github/angular/angular/39255/workflows/c6c448ed-9a44-49b3-a0c2-2c7328ce2855/jobs/1079169
Previously such errors did not appear because no Starlark `.bzl` files
within the test imported other files using the `//` absolute resolution.
Explicitly excluding the nested packages using the `--deleted_packages`
option is the most idiomatic way of achieving this currently (similarly
done by `rules_nodejs`). More information on why this is so verbose
currently:
https://github.com/bazelbuild/bazel/issues/12034
PR Close#44061
Setting the angular_ivy_enabled environment variable to True will default Bazel builds to use the Ivy
compiler rather than defaulting to ViewEngine.
PR Close#43862
A previous commit implemented a streamlined performance metric reporting
system for the compiler-cli, controlled via the compiler option
`tracePerformance`.
This commit adds a custom Bazel flag rule //packages/compiler-cli:ng_perf
to the repository, and wires it through to the `ng_module` implementation
such that if the flag is set, `ng_module` will produce perf results as part
of the build. The underlying mechanism of `//:ng_perf` is not exported from
`@angular/bazel` as a public rule that consumers can use, so there is little
risk of accidental dependency on the contents of these perf traces.
An alias is added so that `--ng_perf` is a Bazel flag which works in our
repository.
PR Close#41125
Updates to rules_nodejs 2.2.0. This is the first major release in 7 months and includes a number of features as well
as breaking changes.
Release notes: https://github.com/bazelbuild/rules_nodejs/releases/tag/2.0.0
Features of note for angular/angular:
* stdout/stderr/exit code capture; this could be potentially be useful
* TypeScript (ts_project); a simpler tsc rule that ts_library that can be used in the repo where ts_library is too
heavy weight
Breaking changes of note for angular/angular:
* loading custom rules from npm packages: `ts_library` is no longer loaded from `@npm_bazel_typescript//:index.bzl`
(which no longer exists) but is now loaded from `@npm//@bazel/typescript:index.bzl`
* with the loading changes above, `load("@npm//:install_bazel_dependencies.bzl", "install_bazel_dependencies")` is
no longer needed in the WORKSPACE which also means that yarn_install does not need to run unless building/testing
a target that depends on @npm. In angular/angular this is a minor improvement as almost everything depends on @npm.
* @angular/bazel package is also updated in this PR to support the new load location; Angular + Bazel users that
require it for ng_package (ng_module is no longer needed in OSS with Angular 10) will need to load from
`@npm//@angular/bazel:index.bzl`. I investigated if it was possible to maintain backward compatability for the old
load location `@npm_angular_bazel` but it is not since the package itself needs to be updated to load from
`@npm//@bazel/typescript:index.bzl` instead of `@npm_bazel_typescript//:index.bzl` as it depends on ts_library
internals for ng_module.
* runfiles.resolve will now throw instead of returning undefined to match behavior of node require
Other changes in angular/angular:
* integration/bazel has been updated to use both ng_module and ts_libary with use_angular_plugin=true.
The latter is the recommended way for rules_nodejs users to compile Angular 10 with Ivy. Bazel + Angular ViewEngine is
supported with @angular/bazel <= 9.0.5 and Angular <= 8. There is still Angular ViewEngine example on rules_nodejs
https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular_view_engine on these older versions but users
that want to update to Angular 10 and are on Bazel must switch to Ivy and at that point ts_library with
use_angular_plugin=true is more performant that ng_module. Angular example in rules_nodejs is configured this way
as well: https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular. As an aside, we also have an
example of building Angular 10 with architect() rule directly instead of using ts_library with angular plugin:
https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular_bazel_architect.
NB: ng_module is still required for angular/angular repository as it still builds ViewEngine & @angular/bazel
also provides the ng_package rule. ng_module can be removed in the future if ViewEngine is no longer needed in
angular repo.
* JSModuleInfo provider added to ng_module. this is for forward compat for future rules_nodejs versions.
PR Close#39182
Joey Perrott