This commit does three things that all related and required to get
rid of `webdriver-manager`:
* Our puppeteer protractor setup in AIO relies on webdriver-manager
because we install a corresponding chromedriver based on the puppeteer
chromium version. We would like to get rid of this brittle setup.
* We don't use `puppeteer` in many places because we manage chromium and
the driver through Bazel. This commit removes the remaining puppeteer
usage and replaces it with the Bazel-managed canonical browser
* We need to migrate the AIO production URL tests to Bazel. These
weren't part of Aspect's migration. This is needed so that we can drop
puppeteer and use the Bazel browser setup.
* Migrates some at-runtime TS `ts-node` test setup to proper idiomatic
Bazel code. Needed because it depends on code that also had to be
migrated to Bazel given the production e2e test Bazel migration (above
points).
Note: The xregexp dependency had to be added to the root project because
`ts_library` does not support compilation deps from `@aio_npm`. This is
something we will fix anyway when we have a more modern toolchain!
PR Close#49025
* updates ng-dev and build-tooling since the previous SHAs are
no longer existent after the CircleCI incident snapshot build removal.
* accounts for the new stamping variables.
PR Close#48731
Currently the Github action-triggered code uses the `GITHUB_TOKEN`
for querying the CLI snapshot builds repository. This does not work
because the Github actions token is scoped to the orginating
repository, even for queries to a read public repository.
We fix this by using a personal access token. The token is
readonly and only exists to avoid potential rate limiting.
PR Close#48681
This commits adds an action to update the Angular CLI help contents that are used by AIO to generate CLI guides.
This also changes the setup to include the files are source files instead of having to clone the repository each time. This also simplifies the PR review process of the PR opened by the action.
PR Close#48577
Fix non-hermetic zipping of example zips by fixing the zip entry timestamps.
I also hardcoded stamp values in stable-status.txt and volatile-status.txt using the workspace status command for the aio_local_deps config to improve cache performance. The Bazel remote cache appears to not ignore volatile-status.txt when there are no other changes, unlike the local Bazel cache:
https://github.com/bazelbuild/bazel/issues/10075#issuecomment-546872111
PR Close#48579
This is basically a pre-step for combining devmode and prodmode into a
single compilation. We are already achieving this now, and can claim
with confidence that we reduced possible actions by half. This is
especially important now that prodmode is used more often, but rules
potentially still using the devmode ESM sources. We can avoid double
compilations (which existed before the whole ESM migration too!).
We will measure this more when we have more concrete documentation
of the changes & a better planning document.
Changes:
* ts_library will no longer generate devmode `d.ts`. Definitions are
generated as part of prodmode. That way only prodmode can be exposed
via providers.
* applied the same to `ng_module`.
* updates migrations to bundle because *everything* using `ts_library`
is now ESM. This is actually also useful in the future if
schematics rely on e.g. the compiler.
* updates schematics for localize to also bundle. similar reason as
above.
PR Close#48521
Since the Bazel setup in this repo will now always use ESM,
the tooling scripts/binaries in AIO need to be switched to ESM
too. Most of the scripts are already ESM, but a few had to be converted.
Note that the Dgeni generation does not use ESM because it's unaffected
and the Dgeni CLI is used. In the future we could also update the Dgeni
setup to ESM but there is no need currently.
PR Close#48521
The docker-based AIO preview deploy setup is replaced with
significantly simpler setup using GitHub actions provided by
dev-infra (also something dev-infra can maintain better then).
The actions under the hood leverage Firebase preview channels.
PR Close#48345
When building AIO using `yarn build` the `--config=release` is added.
This was done as part of the Bazel migration to make sure the footer
shows a Git revision via Bazel stamping.
This does not provide enough benefits, compared to the downside of
reduced caching. Bazel will discard the analysis cache when the stamp
configuration changes.
This may happen easily when you work in framework where
`--config=release` is not used. Then when starting work in AIO: the
config changes and the cache is discarded. This may even mean that
existing framework package build artifacts may be discarded when an
AIO local build is started.
Co-authored-by: Joey Perrott <josephperrott@gmail.com>
PR Close#48329
Move the copy of the bazel dist folder to the firebase dist folder
earlier on in the process so that any checks operate out of a single
folder.
PR Close#48265
Cannot load the root package.json. Surfaced after trying to merge
aio-bazel-migration to main because the deployment short circuits
on ci for feature branhces.
Some earlier refactoring prevented the watchr script from running in
the source tree. There was also a Windows issue where running architect
didn't preserve symlinks causing the app to not be served.
This commit introduces a new process for generating data for the AIO
[events page](https://angular.io/events), which streamlines the process
and minimizes duplication and manual work. For more details, see
`aio/scripts/generate-events/README.md`.
PR Close#45588
The NodeJS Bazel linker does not work well on Windows because there
is no sandboxing and linker processes from different tests will attempt
to modify the same `node_modules`, causing concurrency race conditions
and resulting in flakiness.
PR Close#45872
This is the commit accounting for the Github primary branch
rename when we actually perform the update.
We have three change phases: Prepare, Direct, Cleanup. This commit
is for the `direct` phase.
Since commit 6e40551394, the
`audit-web-app` script no longer needs to skip HTTPS-related audits.
Update the docs comment to reflect that.
PR Close#44214
Previously, the master branch was only deployed to the
`next-angular-io-site` Firebase site, which is connected to the
`next.angular.io` domain. However, if the master major version was
higher than the stable major version (or the RC major version in case
there was an active RC), we also had to manually configure (via the
Firebase console and/or DNS records) the `v<X>.angular.io` domain to
redirect to `next.angular.io`. Then, once `<X>` became the new stable or
RC version, we had to manually remove the redirect (to let
`v<X>.angular.io` be redirected to `angular.io` or `rc.angular.io`).
This commit is part of a new process that reduces the manual steps as
follows (the steps below only apply when the master major version is
higher than the current stable and RC (if applicable)):
- A `v<X>-angular-io-site` Firebase site will be created as soon as the
version in the `master` branch's `package.json` is updated to a new
major.
- The `v<X>.angular.io` domain will be connected to that new Firebase
site.
- When deploying from the master branch, we will deploy to both
`next-angular-io-site` and `v<X>-angular-io-site`. In addition, the
deployment to `v<X>-angular-io-site` will update the Firebase config
file to redirect to `next.angular.io`.
- When the master version becomes the new stable/RC, we will start
deploying to `v<X>-angular-io-site` from the stable/RC branch, which
will update the Firebase config to stop redirecting to
`next.angular.io` and redirect to `(rc.)angular.io` instead (without
requiring changes in the Firebase console or DNS).
PR Close#43963
