Finish removal of aio directory as it is no longer used or relied upon.

PR Close #56496

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

Remove parts of the aio infra

PR Close #54929

This seems to be necessary to debug Node tests.

PR Close #54167

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

This commit update the RBE configuration to use `bes_instance_name` instead
of `project_id`, which got renamed [in Bazel 5.1][1]. Doing so avoids several warnings
in the CI output.

[1]: https://github.com/bazelbuild/bazel/commit/2b48c6b9a447756fcb3295b8a75899b96efa7fd4

PR Close #51696

Migrate windows job to use Github Actions

PR Close #51010

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

Bazel detects maximum number of jobs based on host resources.
Since we run remotely, we can increase this number significantly.

PR Close #50734

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

Don't run the script under Bazel, except for the tests. Configure a
Bazel flag to select the AIO build configuration.

PR Close #48188

Parallel runs of tests on circleci executor push RAM to the limits.

Npm angular deps were transitively being included, confusing the
rules_nodejs linker.

Fixes a bug where 'requires-network' tag was not propagated locally.

By default network access is disabled for actions on ci.

This is a first pass. There is more work to do on package.json, adding
more test targets under bazel, and revising documentation.

first party deps

Architect is not compatible with disabling the rules_nodejs linker so
these targets must use npm_link to link first party deps

This does not provide any added value.

PR Close #47584

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

Follow-up to: cce395a9.

PR Close #46456

Patches are required for tsec and rules_webtesting. The fix for
rules_webtesting was merged to that repo
(https://github.com/bazelbuild/rules_webtesting/commit/581b1557e382f93419da6a03b91a45c2ac9a9ec8)
but it's unclear when a release will be cut.

PR Close #46313

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

This commit removes --config=viewengine and makes Ivy the default for
building Angular.

PR Close #43884

Previously the ts_library bazel rule was used to build angular devtools. This commit migrates to ts project and brings in some bazel tooling from angular/components to run bundle spec files for karma tests.

Marks the beginning of a migration over to building Angular devtools with Bazel. This commit brings in tooling from the canonical angular bazel example repository and includes the necessary dependencies in the package.json

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

build: remove dev-infra directory and migrate to relying on @angular/dev-infra-private-builds (#43061)

Remove the dev-infra directory and complete the migration to using the code generated by the
angular/dev-infra repository.

PR Close #43061

Update to use remote instance name, primary_instance, for RBE

PR Close #42636

Uses the new shared RBE platform from the dev-infra package.

PR Close #41767

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

Update the config flags used for snapshot builds and release builds.

PR Close #40095

build: upgrade angular build, integration/bazel and @angular/bazel package to rule_nodejs 2.2.0 (#39182)

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

Revert "build: upgrade angular build, integration/bazel and @angular/bazel package to rule_nodejs 2.2.0 (#37727)" (#39097)

This reverts commit db56cf18.

PR Close #39097

build: upgrade angular build, integration/bazel and @angular/bazel package to rule_nodejs 2.2.0 (#37727)

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.
  @josephperrott, this touches `packages/bazel/src/external.bzl` which will make the sync to g3 non-trivial.

PR Close #37727

This option is no longer needed in Bazel and will be an error in the future

PR Close #38124

Disables Bazel runfile tree creation. Only if a given
execution strategy relies on runfile tree creation, the
runfile tree is created lazily. This helps as currently
Bazel spends unnecessary time on CI building runfile trees
for tests which are cached and aren't re-run.

The goal is to spend less time on CI for cached test/build
targets. We can't measure impact yet as there are targets
for the integration tests that hide the potential benefits.
on the components repo a 80% time reduction could be observed.

PR Close #36914

Migrate to using new common environment stamping script for stamping
during bazel build/release tasks.

PR Close #36844