This commit updates `firebase-admin`, `firebase-functions` and
`firebase-tools` to latest versions to take advantage of the most recent
fixes and improvements.
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.
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/ |
This commit gets rid of all references to Travis and, belatedly, Jenkins.
Now all CI is done on CircleCI and releases are run locally.
The CI no longer updates the docs and code.angularjs.org for jobs that are
not on the `master` branch.
During releases, the docs and code should be uploaded manually.
Node.js 8 ends its support at the end of 2019. Node 12 will be supported
until April 2022 which is way past AngularJS end of support.
Some dependencies needed to be updated to make them work in Node.js 12.
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
Included changes:
*Update minimum Yarn version from 1.3.2 to 1.10.1*
Yarn 1.10 added the integrity field to the lockfile, making newer Yarn users
have their lockfile changed a lot if they run `yarn`. This commit updates the
required Yarn version to be at least 1.10.1 and changes Travis & Jenkins to use
Yarn 1.10.1
*Change the package.json's engines grunt field to grunt-cli*
The grunt field suggested it's the grunt package version we're checking while
we check the grunt-cli version instead.
*Stop separating Yarn script arguments from script names via " -- "*
The " -- " separator is necessary in npm but not in Yarn. In fact, it's
deprecated in Yarn and some future version is supposed to start passing this
parameter directly to the scripts which may break them.
*Don't install grunt-cli globally during the build*
It's enough to use `yarn grunt` instead of `grunt` and the global grunt-cli
installation is no longer needed.
*Use `yarn grunt` instead of `yarn run grunt`*
The former form is shorter.
*Don't define the `grunt` Yarn script*
As opposed to npm, `yarn binName` invokes a binary named `binName` exposed
by the respective package so the `grant` Yarn script is no longer needed.
*Allow Node versions newer than 8; bump the minimum*
Closes#16714
Edge 15 disconnects from Karma frequently causing extreme build instability.
We are testing on Edge 16 & Edge 17 should be released soon anyway.
Closes#16516
Previously, we rewrote index.html to index-production.html, but Firebase ignored
this, probably because an exact file match always takes priority. This lead
to the problem thatthe root - angularjs.org - didn't include the angular.js source
files from the CDN
Firebase is trying to execute our functions code locally in order to
parse the triggers. Install npm dependencies to avoid errors like:
```
Error: Error parsing triggers: Cannot find module 'firebase-functions'
```
Closes#16453
This commit restores serving the plain partials (content) when a docs
page is accessed with ?_escaped_fragment_=.
The Google Ajax Crawler accesses these urls when the page has
`<meta type="fragment" content="!">` is set.
During the migration to Firebase, this was lost, which resulted in Google
dropping the docs almost completely from the index.
We are using a Firebase cloud function to serve the partials. Since
we cannot access the static hosted files from the function, we have to
deploy them as part of the function directory instead, from which they
can be read.
Related to #16432
Related to #16417
- allow all-versions-data.js in snapshot, which is used by docs.angularjs.org
- disallow access to folders like docs-0.9.2 etc which are used by early versions
Firebase projects should be in their own folder, because the firebase-tools
search for projects in the parent folder, which makes it more difficult to create
new projects.