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#39479
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#39479
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#39479
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#39479
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#39479
Removing for now, since the info is stale, and we need to determine how to adjust the schedule due to the unexpected and significant version 9 delay.
PR Close#34474
In #34955, we switched to Node.js v12 on master and 9.0.x. This causes
the `aio_monitoring_job` CI job (which checks out files from the stable
branch; currently 8.2.x) to start failing yarn's engines check (since
the 8.2.x branch expects Node.js version <11).
Example failure: https://circleci.com/gh/angular/angular/602499
Since the job is expected to run with files from both the stable and the
master branches (and since the version of Node.js is not important
here), this commit uses the `--ignore-engines` option to prevent
failures due to Node.js version mismatch.
NOTE:
Typically, the stable and master branch are on the same Node.js version,
because related PRs land on both master and the patch branch. One
exception is during RC periods, when the stable branch is different than
the patch branch. These periods are usually short, but in the case of
9.0.0 the period has lasted several months causing the CI environments
between master and the stable branch to get significantly out-of-sync.
This is a backport of #34682 to the 8.2.x branch.
It fixes `Server Error. certificate has expired` errors that cause AIO
deployment to fail.
(Example CI failure: https://circleci.com/gh/angular/angular/599109)
This is a backport of #34902 to the 8.2.x branch (except that yarn
v1.17.3 is used to satisfy the yarn version requirements of the 8.2.x
branch).
This will ensure that an appropriate yarn version will be used in the
`aio_monitoring_stable` CI job, which checks out files from the git
branch corresponding to the latest stable Angular version (currently the
8.2.x branch).
(Example of the current failure:
https://circleci.com/gh/angular/angular/598455)
- resolves "Invariant violated (initialize): latest hash null has no known manifest"
- Thanks to @gkalpak and @hsta for helping test and investigate this fix
Fixes#25611
PR Close#32525
PR#28396 originally addressed an update via issue #23983 to make images more visible with a white background (implementation of gray "lightbox").
This PR implements those styles defined in PR#28396.
PR Close#33259
In the example, there's no directive nor input that's named `appHighlightColor`.
It should be `appHighlight`, referring to the input binding.
PR Close#33331
It looks like the gulp setup does not work with NodeJS v12. This
is because we still use gulp for a few tasks, but gulp v3 is not
compatible with NodeJS v12. We had a similar issue for NodeJS v12,
but worked around it by updating the `natives` module version.
To actually solve this in a more future-proof way, without
updating or removing Gulp (for now), we just overwrite the
`graceful-fs` version. The latest version of `graceful-fs`
does no longer depend on the `natives` package and therefore
works properly with NodeJS >= v10.
PR Close#33348
Previously, when navigating to a new page via a link, the scroll
position was correctly restored to 0, but navigating to a new page via
typing the URL in the browser address bar keeps the old scroll position.
This commit ensures that the scroll position is restored to 0 whenever
the `ScrollService` is instantiated anew (i.e. new page navigation). The
old behavior of retaining the scroll position on reload is kept by
storing the old URL when leaving a page and only applying the stored
scroll position if the new URL matches the stored one.
Fixes#33260
PR Close#33344
Changed `setValue` documentation for throwing an error as it contained a grammar
mistake and also may have caused ambiguity around when exactly the
method would throw.
PR Close#33126
The `dev-infra-framework` codeowners section is located after
all the codeowner sections for the individual framework packages.
This means that for certain wildcards, like `*.bzl` take precedence
over the individual package sections (like of `/packages/bazel/**`).
This can be observed in the following PR where `dev-infra` got requested
for file changes to `@angular/bazel`. #32955.
To fix this, we move the `dev-infra-framework` section before all
individual framework package sections. This means that we only match
files which are not matched by other patterns.
Additionally a pattern for `*.BAZEL` has been added to the dev-infra
section. This helps getting changes to `BUILD.bazel` files through
easier as dev-infra can review those (Note: only for bazel files which
are not matched by other patterns).
PR Close#33249
Pete Bacon Darwin