Previously, the `deploy-code-firebase` CI job was run on any build
corresponding to a git tag, the master branch or the stable branch.
Given that all runs of `deploy-code-firebase` deploy to the same
Firebase project (and overwrites previous deployments), there is no
point in deploying from multiple branches/tags.

This commit fixes this by ensuring that we only run the
`deploy-code-firebase` job on builds for the master branch, which
contains the most up-to-date code/configuration.

In #17114, the `deploy-code` CI job was modified to also run some
commands via `yarn`. It turns out that this breaks on CI, because the
`deploy-code` job uses the `cloud-sdk` executor that does not have
`yarn` installed. ([Example failure][1])

This commit fixes this by splitting the `deploy-code` job into two jobs:
- `deploy-code-files` uses the `cloud-sdk` and uploads the files to
  Google Cloud.
  (This is essentially the `deploy-code` job from before #17114.)
- `deploy-code-firebase` uses the `default` executor (which has `yarn`
  installed) and deploys to Firebase.
  (This essentially includes the new bits added in #17114.)

[1]: https://circleci.com/gh/angular/angular.js/2712

…sendStoredFile()`

Previously, the `sendStoredFile()` Firebase function used `.split('/')`
to split the request path into segments and later used `path.join()` to
join them back together. This worked fine on *nix based systems, which
use `/` as the path separator. On Windows, however, where `\` is the
path separator, the re-constructed paths could not be retrieved from the
Google Cloud Storage bucket. This prevented the Firebase emulators from
working correctly when testing the function locally on Windows.

This commit fixes the issue by using `.join('/')` to join the path
segments back together.

Closes #17114

This commit updates `firebase-admin`, `firebase-functions` and
`firebase-tools` to latest versions to take advantage of the most recent
fixes and improvements.

…angularjs-org`

Previously, when deploying `scripts/{code,docs}.angularjs.org-firebase/`
to Firebase, we explicitly specified the target projects. Since the
project IDs are also specified in the respective `.firebaserc` files,
this was unnecessary (and meant we had multiple places to update if the
IDs changed).

This commit simplifies the process by automatically targeting the
default projects (as configured in the `.firebaserc` files) when
deploying to Firebase in CI.

Previously, we only deployed the built files to Google Cloud Storage for
the `code-angularjs-org` Firebase project. This meant that the other
Firebase services (such as functions, hosting, storage) were not updated
when we made changes to their source code or configuration.
(This isn't a problem at the moment, since the code/configuration for
these service changes infrequently, but could bite us in the future.)

This commit fixes this by ensuring that we deploy to all enabled
Firebase services (currently functions, hosting and storage).

Previously, we only deployed to Firebase hosting for the
`docs-angularjs-org` Firebase project. This meant that the deployed
functions used an old version of Node.js and started failing once
support was dropped for that version. See #17111 for details.

This commit fixes this by ensuring that we deploy to all enabled
Firebase services (currently functions and hosting).

Fixes #17111
Fixes angular/angularjs.org#251

…ng directory

Previously, in order to deploy to Firebase from
`scripts/docs.angularjs.org-firebase/`, we had to copy the
`firebase.json` file to the repository root and adjust the contained
paths accordingly.

By running the `firebase` CLI directly (instead of via `yarn`), we are
able to deploy from `docs.angularjs.org-firebase/` directly. This
simplifies the deployment (and local testing) process and paves the way
for also deploying from `code.angularjs.org-firebase/` in a subsequent
commit.

…tories

We have the `scripts/{code,docs}.angularjs.org-firebase/` directories,
which contain the necessary code and config for deploying built files to
the `code-angularjs-org` and `docs-angularjs-org` Firebase projects
respectively.

Previously, some of the files that needed to be deployed to Firebase (or
Google Cloud) were placed outside these directories (e.g. in
`deploy/{code,docs}/`).

Since these files are only used for deploying to Firebase/Google Cloud,
this commit changes the deployment process to instead copy the files
inside the directories. In a subsequent commit, this will allow
simplifying the deployment process, by running it from inside each
directory instead of having to copy the `firebase.json` files to the
repository root (and adjust the paths).

These are the destination directory changes:

| Before       | After                                       |
|--------------|---------------------------------------------|
| deploy/code/ | scripts/code.angularjs.org-firebase/deploy/ |
| deploy/docs/ | scripts/docs.angularjs.org-firebase/deploy/ |

…kage-lock.json`)

Since we are using `yarn` to install dependencies, it makes sense to use
`yarn.lock` as the lockfile (and get rid of the unused
`package-lock.json`).

- Remove stray backtick.
- Add missing preposition (`identical` --> `identical to`).
- Remove 1.8.1 change from the 1.8.2 section.

Closes #17093

…dResourceUrlList()`

In commit a206e26, `$sceDelegateProvider`'s
`resourceUrlWhitelist()` was deprecated in favor of the new
`trustedResourceUrlList()`. However, although both properties were
assigned the same value, it was possible for an app to break if one of
the properties was overwritten in one part of the app (or a 3rd-party
library) while another part of the app interacts with the other,
non-overwritten property.

This commit fixes it by making `resourceUrlWhitelist()` a getter/setter
that delegates to `trustedResourceUrlList()`, ensuring that the two
properties will remain in sync. This, also, makes it consistent with
other similar deprecated properties, such as `$sceDelegateProvider`'s
`resourceUrlBlacklist()`.

Closes #17090

In commits 9679e58..3dd42ce, some properties
and methods names including the terms whitelist/blacklist were
deprecated in favor of new ones not including the terms.

This commit fixes some typos in docs related to these changes and adds
links to the new properties/methods in the changelog for easier access.

Fixes #17088

Since #17039, our docs Firebase functions' `package.json` specifies a
`node` engine version. This is required for configuring which version of
Node.js should Firebase use to execute the functions. However, since
Firebase is using an older version of Node.js than the one we use to
build the AngularJS project, yarn would error due to incompatible
Node.js engine versions ([example failure][1]).

This commit avoids the error by running yarn with the `--ignore-engines`
option.

[1]: https://app.circleci.com/pipelines/github/angular/angular.js/214/
     workflows/ad2e9baf-7249-467d-bc71-bd98e6cd922c/jobs/2247

Closes #17078

Previously, the `DIST_TAG` environment variable was failing to be
computed correctly in the `deploy-code` CI job, because it relied on the
non-existent `node` executable. It worked with the default executor
(which includes `node`), but not with the `cloud-sdk` executor used in
`deploy-code`, resulting in the following error:

```sh
./.circleci/env.sh: line 59: node: command not found
DIST_TAG=
```

You can see an example failure in the "Set up environment" step logs in
https://app.circleci.com/pipelines/github/angular/angular.js/
170/workflows/32fcacf9-c89b-4020-b3eb-15debe18bb67/jobs/1793

This commit fixes it by computing `$DIST_TAG` using unix tools (`cat`,
`grep`, `sed`) that _are_ available on the docker images of all
executors.

Closes #17067

Previously, the command used to deploy the docs to Firebase (as part of
the `deploy-docs` CI job) would fail, because no target project was
specified (either directly in the command or indirectly via a
`.firebaserc` file in the working directory).

Example failure:
https://app.circleci.com/pipelines/github/angular/angular.js/
166/workflows/34c692ec-18d4-4422-a1cf-108a91219fa5/jobs/1744

This commit fixes the command by specifying the project via the
`--project` cli argument. It also adds the commit SHA as message to make
it easier to associate a deployment with the corresponding commit.

Closes #17066

Previously, the `DIST_TAG` environment variable was failing to be
computed correctly, because it was using the non-existent `jq` tool. In
the past (when running on TravisCI), `jq` used to be available, but it
is not on the currently used CircleCI docker image, resulting in the
following error:

```sh
./.circleci/env.sh: line 59: jq: command not found
DIST_TAG=
```

You can see an example failure in the "Set up environment" step logs in
https://app.circleci.com/pipelines/github/angular/angular.js/
166/workflows/34c692ec-18d4-4422-a1cf-108a91219fa5/jobs/1742

This commit fixes it by using `node` (which _is_ available on the docker
image) to compute `$DIST_TAG`.

Previously, the `prepare-deployment` CI job, which requires all unit and
e2e test jobs to have succeeded before running, was ignoring the `lint`
job. As a result, deployments might happen even when there were linting
issues. This looks like an oversight.

This commit ensures that, in addition to unit and e2e tests passing,
linting must also pass before deploying the code or documentation.

Closes #17063

One step in the `deploy-docs` CI job contains a typo that causes it to
fail: `yarn -cwd ...` instead of `yarn --cwd ...`
This has been broken since a0488b3, but
has not been noticed because the job was not running. #17060 configured
the job to run as necessary, which brought up the error.

Example failure:
  - On v1.8.x:
    https://app.circleci.com/pipelines/github/angular/angular.js/
    153/workflows/6a9826ac-d191-4042-8c39-0c969c81e381/jobs/1606

This commit fixes the typo in the command.

In #17060, the `deploy-code` job was updated to [include][1] the
`init_environment` custom command. This caused the job to start failing,
because  the `init_environment` command was not compatible with the
`cloud-sdk` executor used in `deploy-code`. There were two problems:

1. The `init_environment` command assumes that the working directory is
   `~/ng`. The `cloud-sdk` executor [did not specify][2] a working
   directory.
   Example failures:
     - On master:
       https://app.circleci.com/pipelines/github/angular/angular.js/
       152/workflows/812df7b2-4bba-4e9e-a868-8c58db5d40d1/jobs/1594
     - On v1.8.x:
       https://app.circleci.com/pipelines/github/angular/angular.js/
       153/workflows/6a9826ac-d191-4042-8c39-0c969c81e381/jobs/1607

2. The `install_java` step, which is part of the `init_environment`
   command, relies on `sudo`, which is not available in the `cloud-sdk`
   executor.
   Example failure:
   - [On a PR]:
     https://app.circleci.com/pipelines/github/angular/angular.js/
     160/workflows/2eed5cfa-751c-44ba-b825-1d6cd5ba3406/jobs/1660

This commit fixes the issues by:
1. Specifying a working directory for the `cloud-sdk` executor. It also
   updates paths used in other steps of the `deploy-code` job to take
   the working directory into account.
2. Removing the `install_java` step from the `init_environment` command
   and adding it explicitly to jobs than require it.

[1]: https://github.com/angular/angular.js/blob/83f084e5db95768dcee5/.circleci/config.yml#L359
[2]: https://github.com/angular/angular.js/blob/83f084e5db95768dcee5/.circleci/config.yml#L34-L37

…oy-docs` CI job

Previously, the `grunt prepareDeploy` command was run in both the
`prepare-deployment` and `deploy-docs` CI jobs. The reason was that not
all files affected by `grunt prepareDeploy` were persisted to the
workspace across jobs.

More specifically, the command would affect files in the `deploy/` and
`scripts/docs.angularjs.org-firebase/` directories and also create a
`firebase.json` file at the root directory, but only the `deploy/`
directory was [persisted to the workspace][1].

This commit avoids unnecessarily running the `grunt prepareDeploy`
command in the `deploy-docs` CI job by ensuring that all affected files
will be persisted to the workspace in the `prepare-deployment` CI job,
which always runs before `deploy-docs`.

[1]: https://github.com/angular/angular.js/blob/295213df953766625462/.circleci/config.yml#L265

Closes #17060

Previously, the generated build artifacts and docs were only deployed
for builds associated with the master branch. There was also a `latest`
branch mentioned in the config, but there is normally no such branch, so
this had no effect.

This commit fixes the rules so that deployments happen when necessary.
More specifically:
- The `deploy-code` job now runs for builds associated with:
  - The master branch.
  - The stable branch (i.e. the branch from which the version tagged as
    `@latest` on npm is released).
  - Tags of the form `v1.X.Y(-Z)`. (This also required configuring
    CircleCI to run builds for git tags, which does not happen by
    default.)
- The `deploy-docs` job now runs for builds associated with:
  - The stable branch (i.e. the branch from which the version tagged as
    `@latest` on npm is released).

The new rules for when deployments should take place are based on the
logic previously in [.travis.yml][1] and [scripts/travis/build.sh][2]
(from before we switched from Travis to CircleCI).

[1]: https://github.com/angular/angular.js/blob/974700af7c1/.travis.yml#L54-L103
[2]: https://github.com/angular/angular.js/blob/974700af7c1/scripts/travis/build.sh#L66-L101

As mentioned in `RELEASE.md`, now that the [CDN][1] has been updated
with the 1.8.0 version, it is safe to bump the value of the
`branchVersion` property in `package.json` to `^1.8.0`. This will cause
the docs app to use the latest version, namely 1.8.0.

[1]: https://ajax.googleapis.com/ajax/libs/angularjs/1.8.0/angular.js

…By --> keyBy)

The `indexBy()` method was renamed to `keyBy()` in lodash v4 (see
lodash/lodash@b1d52cc). This commit
updates all usages of `indexBy()` to `keyBy()`.

This is a follow-up to #16915, cleaning up `package.json` and
`.circleci/config.yml` and making release scripts executable.

Previously, the docs app used `document.write()`, causing the following
warning on Chrome:

```
A parser-blocking, cross site (i.e. different eTLD+1) script,
https://ajax.googleapis.com/ajax/libs/angularjs/1.7.9/angular.min.js, is
invoked via document.write. The network request for this script MAY be
blocked by the browser in this or a future page load due to poor network
connectivity.
```

In the past, `document.write()` seems to have been used in order for
browsers (such as Firefox) to work correctly with our dynamically set
`<base>` tag and relative style/script URLs.

This commit replaces `document.write()` with regular
`<style>`/`<script>` tabs to avoid the warning (and potential issues due
to poor network connectivity). It seems that the latest versions of
Chrome, Firefox and IE can handle this fine (without naticeable delays).

Fixes #15396

The files served for the various versions on https://code.angularjs.org/
are retrieved by a Firebase function from a Firebase Storage bucket
(where they are deployed to from Travis CI). The files are stored
exactly as they are named on disk.

It turns out that some of the files have names with special characters
that get URI-encoded when sent to the Firebase function. For example,
`input[text].html` becomes `input%5Btext%5D.html`. As a result, the
actual file cannot be retrieved from the Storage bucket (since the name
does not match) and `index.html` is returned instead. Apparently, this
never worked, but nobody noticed or reported it until recently.

An example of a failing URL is:
https://code.angularjs.org/1.7.9/docs/api/ng/input/input%5Btext%5D

(NOTE: https://docs.angularjs.org/ works correctly, since the files are
deployed to Firebase hosting directly and not to a Storage bucket.)

This commit fixes the problem by decoding the request path before trying
to retrieve the corresponding file from the Storage bucket.

Closes #16943

The currently latest-1 version of desktop Safari (v12.0) on SauceLabs is
completely unstable. Switching to the latest version (currently v12.1),
which works fine.

Closes #16888