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
Previously, (when there was an active RC) the RC branch was only
deployed to the `rc-angular-io-site` Firebase site, which is connected
to the `rc.angular.io` domain. However, if the RC major version was
higher than the stable major version, we also had to manually configure
(via the Firebase console and/or DNS records) the `v<X>.angular.io`
domain to redirect to `rc.angular.io`. Then, once `<X>` became the new
stable version, we had to manually remove the redirect (to let
`v<X>.angular.io` be redirected to `angular.io`).
This commit is part of a new process that reduces the manual steps as
follows (the steps below only apply to RC versions that have a higher
major version than the current stable):
- A `v<X>-angular-io-site` Firebase site will be created for the new RC
version.
- The `v<X>.angular.io` domain will be connected to that new Firebase
site.
- When deploying from the RC branch, we will deploy to both
`rc-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 `rc.angular.io`.
- When the RC version becomes the new stable, we will start deploying to
`v<X>-angular-io-site` from the stable branch, which will update the
Firebase config to stop redirecting to `rc.angular.io` and redirect to
`angular.io` instead (without requiring changes in the Firebase
console or DNS).
PR Close#43963
Previously, the stable branch was always deployed to the
`v<X>-angular-io-site` Firebase site, which was connected to the
`angular.io` domain. Whenever a new major version was released (and
became the new stable version), the `angular.io` domain had to be
disconnected from the previous Firebase site and be connected to the new
`v<Y>-angular-io-site` Firebase site. This was a manual process that
involved making changes in the Firebase console and the DNS records.
This commit is part of a new process that reduces the manual steps as
follows:
- A new `stable-angular-io-site` Firebase site is created.
- The `angular.io` domain will be connected to that new Firebase site.
- When deploying from the stable branch, we will deploy to both
`stable-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 `angular.io`.
- When a new major version is released, we will start deploying from the
new stable branch to `stable-angular-io-site`, but there will be no
need to connect/disconnect the `angular.io` domain. Also,
`v<X>.angular.io` will stop redirecting to `angular.io` by means of
updating the Firebase config file (without requiring changes in the
Firebase console or DNS).
PR Close#43963
Add `deploy-to-firebase` post-deploy actions to allow testing various
redirect configs.
In a future commit, this will allow testing redirects for the `stable`,
`rc` and `next` deployments via the Firebase config file (without
requiring changes in the Firebase console or DNS).
PR Close#43963
Refactor the `deploy-to-firebase` post-deploy actions by extracting
logic to separate helper functions. This makes it easier to create more
functions for testing various redirect configs (in a future commit).
PR Close#43963
Previously, there was a `deploy-to-firebase` pre-deploy action for
configuring Firebase to redirect non-file requests to `angular.io`. This
is used for ensuring that `rc.angular.io` is correctly redirected to
`angular.io`, even when people have previously visited (and have a
ServiceWorker activated on) `rc.angular.io`.
This commit adds pre-deploy actions for configuring Firebase to redirect
a deployment to any of `angular.io`, `rc.angular.io` or
`next.angular.io` and also configure whether all requests or only
non-file requests will be redirected.
In a future commit, this will allow managing redirects for the `stable`,
`rc` and `next` deployments via the Firebase config file (without
requiring changes in the Firebase console or DNS).
PR Close#43963
Create functions to undo the changes made by any pre-deploy action.
In a future commit, this will allow deploying a build to multiple
projects/sites with different small tweaks for each.
PR Close#43963
Previously, the pre-computation of branch version info for the
`deploy-to-firebase` tests would always take place even when the tests
that used that info were skipped. This pre-computation involves network
access and may add a noticeable delay.
This commit refactors the tests to not do the pre-computation if the
corresponding tests are skipped. This allows for a faster iteration
when focusing on a different set of tests.
PR Close#43963
