Adding debug information for failing firebase deploy, hoping
to yield information about the missing resource. The next
multi-site seems to be failing, but is available.
PR Close#54275
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
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
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.
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
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
Move some functions that are used as post-deploy actions from
`deploy-to-firebase/index.mjs` to a separate file
(`deploy-to-firebase/post-deploy-actions.mjs`) to keep `index.mjs` small
and easier to maintain.
NOTE:
While not strictly necessary atm, `post-deploy-actions.mjs` uses the
same default export pattern for consistency with `utils.mjs`.
PR Close#43963
Move some functions that are used as pre-deploy actions from
`deploy-to-firebase/index.mjs` to a separate file
(`deploy-to-firebase/pre-deploy-actions.mjs`) to keep `index.mjs` small
and easier to maintain.
Also, rename the `removeServiceWorker()` function to
`disableServiceWorker()`, which is a little more accurate.
NOTE:
While not strictly necessary atm, `pre-deploy-actions.mjs` uses the same
default export pattern for consistency with `utils.mjs`.
PR Close#43963
Move some util functions from `deploy-to-firebase/index.mjs` to a
separate file (`deploy-to-firebase/utils.mjs`) to keep `index.mjs` small
and easier to maintain.
NOTE:
To make it easier to mock functions in tests, `utils.mjs` uses a default
export (instead of multiple named exports) and references local
functions through the default exported object.
PR Close#43963
