In #39470, the `deploy-to-firebase.sh` script (used to deploy AIO to
Firebase when building an upstream branch), was replaced by an
equivalent JS script. In this new `deploy-to-firebase.js` script, we
were overly aggressive with suppressing command output, which made it
hard to investigate failures ([example failing CI job][1]).
This commit updates the `deploy-to-firebase.js` script to capture
command output as usual in the CI job logs. This makes the output
similar to the one generated by the old [deploy-to-firebase.sh][2]
script ([example CI logs][3]).
One concern with capturing command output is having the value of a
secret environment variables leaked in the logs. This is not the case
here, since:
1. The secret env vars are not printed from the commands that use them.
2. CircleCI will [mask the values of secret env vars][4] in the output.
As an extra precaution (although not strictly necessary), we run `yarn`
with the `--silent` option, which avoid echoing the executed yarn
commands.
[1]: https://circleci.com/gh/angular/angular/849310
[2]: https://github.com/angular/angular/blob/3b0b7d22109c79b4dceb/aio/scripts/deploy-to-firebase.sh
[3]: https://circleci.com/gh/angular/angular/848109
[4]: https://circleci.com/docs/2.0/env-vars/#secrets-masking
PR Close#39596
The commit updates the AIO deployment script to also print the commit
SHA. This makes it easier to check whether a version has been
successfully deployed, by comparing the commit SHA from the CI job with
the SHA in the version string in the footer of the AIO app.
PR Close#39596
Previously, the documentation for each major Angular version was hosted
on each own Firebase project. This required creating a new project for
each major release and increased the administrative/maintenance cost.
Now that Firebase supports hosting [multiple websites][1] as part of the
same project, we are switching to deploying all major versions to sites
created on `angular-io` project.
This is part of the work needed to prepare angular.io for our
[new versioning/branching process][2] (also tracked in #39366).
[1]: https://firebase.google.com/docs/hosting/multisites
[2]: https://docs.google.com/document/d/197kVillDwx-RZtSVOBtPb4BBIAw0E9RT3q3v6DZkykU
PR Close#39470
This commit breaks up the code in `deploy-to-firebase.js` script, that
we use for deploying angular.io to production, to smaller functions
(instead of a monolithic block). This makes the script easier to
maintain and also makes testing individual operations easier.
The commit also updates the `deploy-to-firebase.spec.js` spec file to
take advantage of the standalone functions to speed up testing by
calling the corresponding function instead of having to spawn a new
process and run the `deploy-to-firebase.js` script with the `--dry-run`
flag.
NOTE: Before updating the tests, I verified that the updated
`deploy-to-firebase.js` script passed the old tests.
PR Close#39470
Different deployment modes (such as `archive` and `next`) are identified
by the different colors used in prominent elements of the page, such as
the topbar and the footer.
Previously, the necessary styles for creating such a deployment mode
"theme" were duplicated for each mode.
This commit simplifies the creation/modification of a deployment mode
theme by introducing a Sass mixin that generates the necessary styles
(when provided with necessary theme colors).
PR Close#39470
Previously, the `deploy-to-firebase.js` script and the accompanying
`deploy-to-firebase.spec.js` spec file were using the `origin` remote
alias in certain commands. This works fine on CI, where `origin` points
to the `angular/angular` GitHub repo, but might not work locally.
This commit ensures that the correct remote is used by explicitly
specifying it by the URL, thus ensuring that the tests will behave
identically on CI and locally.
PR Close#39470
This commit switches the `deploy-to-firebase.sh` script, that we use for
deploying angular.io to production, from Bash to JavaScript. This makes
the script easier to maintain.
For the same reasons, it also switches the `deploy-to-firebase.test.sh`
script, that we use for testing the `deploy-to-firebase` script, from
Bash to JavaScript (using jasmine as the test runner).
Finally, this commit also updates ShellJS to the latest version to get
better error messages (including the actual error) when `exec()` fails.
NOTE: Before switching the test script to JS, I verified that the new
`deploy-to-firebase.js` script passed the tests with the old
`deploy-to-firebase.test.sh` script.
PR Close#39470
The browser being launched needs to match the custom launcher name.
Otherwise Karma would still trigger the original Chrome executable without the flags.
PR Close#39480
Fixes#31186. This commit adds more context about the behavior
of template reference variables in nested templates and moves
doc into concepts section.
PR Close#31195
The `generateKeywords` dgeni processor automatically generates keywords
for each document by extracting words from each string property of a
`doc` object.
This commit adds `basePath` to the list of ignored properties, so that
it is _not_ considered when generating keywords. `basePath` mostly
contains the path to some root directory (such as
`/home/circleci/ng/packages`) and as such it does not contain useful
keywords.
For example, searching for `circleci` will match all API docs, because
it happens to be in the `basePath`:
https://v10.angular.io/?search=circleci
PR Close#39409
group together similar error messages as part of error code efforts
ProviderNotFound & NodeInjector grouped into throwProviderNotFoundError
Cyclic dependency errors grouped into throwCyclicDependencyError
PR Close#39251
This commit edits the copy of the attribute binding documentation, moves the
colspan section that is primarily about property binding to the property
binding document, and adds a docregion to the attribute-binding
example to help clarify a point in the document.
Part of the copy edit reformats the style precedence list in tabular format
so that it is easier to read and understand.
PR Close#38860
This tool can be run from anywhere in the aio folder as:
```sh
yarn create-example <example-name>
```
It will create some basic scaffold files to get the example started.
After creation the developer should then use `yarn boilerplate:add`
or similar to ensure that the example can be run and tested.
You can optionally provide an absolute path to a pre-existing CLI
project and it will copy over appropriate files (ignoring boilerplate)
to the newly created example.
```sh
yarn create-example <example-name> /path/to/other/cli/project
```
Fixes#39275
PR Close#39283
George Kalpakas