The fixed test expected there to be a doc version without a URL. This used to be
the case but not any more. As a result, an error was logged in the test output
(but no failure).
This commit fixes it by ensuring that a version without a URL exists.
PR Close#18659
This commit also updates the version of `@angular/cli` used for docs examples.
The previous (transient) dependency `@ngtools/webpack` was not compatible with
`@angular/compiler-cli@>=5` and was breaking when running against the local
builds (currently at 5.0.0-beta.2). The version of `@ngtools/webpack` used by
the latest `@angular/cli` version is compatible with `@angular/compiler-cli@5`.
There are now 3 modes for deployment: next, stable, archive.
We compute which mode (and other deployment properties)
from the `TRAVIS_BRANCH` and the `STABLE_BRANCH`.
If the TRAVIS_BRANCH is master we deploy as "next".
If the `TRAVIS_BRANCH` matches the `STABLE_BRANCH` we deploy as "stable".
Otherwise if the branch has a major version lower than the stable version
and its minor version is highest of similar branches we deploy as "archive".
For "archive" deployments we compute the firebase project and deployment
url based on the major version of the `TRAVIS_BRANCH`.
As well as choosing where to deploy the build, we also use this
to select the environment file for the AIO Angular app.
This will enable the app to change its rendering and behaviour
based on its mode.
See #18287Closes#18297
There are now 3 modes for deployment: next, stable, archive.
We compute which mode (and other deployment properties)
from the `TRAVIS_BRANCH` and the `STABLE_BRANCH`.
If the TRAVIS_BRANCH is master we deploy as "next".
Otherwise if the branch is the highest of its minor versions
we deploy as "stable" if the `TRAVIS_BRANCH` matches the `STABLE_BRANCH` or
else "archive".
For "archive" deployments we compute the firebase project and deployment
url based on the major version of the `TRAVIS_BRANCH`.
As well as choosing where to deploy the build, we also use this
to select the environment file for the AIO Angular app.
This will enable the app to change its rendering and behaviour
based on its mode.
See #18287
This is possibly a temporary fix for the layout, until we decide whether we want
to remove the guide or properly add it to the SideNav menu.
Fixes#17912
The Internationalisation documentation, "Translate text nodes" section, has an incomplete
markdown anchor, and leaks markdown into the page. Fix the anchor by adding the opening bracket.
The markdown processor expects an empty line between an opening tag and the
markdown content. (If there is no empty line, the content is interpreted as
plain HTML.)
Previously, the line between the opening `<td>` and the content contained
whitespace, which caused the content to be interpreted as HTML and not markdown.
Fixes#18312
PR Close#18349
* Tell the app that this will have no Table of Contents, since we have no
h2 headings anyway.
* Remove all the `nbsp;` from the code since that doesn't help with layout
* Remove side padding from sidenav-content when screen is narrow
* Restyle the cheatsheet table when the screen is narrow
Possibly overlooked testing documentation mistake fixed:
- `http.get('/data')` probably ought to be paired with `httpMock.expectOne('/data')` instead of `httpMock.expectOne('/data')`.
The API docs have changed. The line numbers are now found in
`startingLine` and `endingLine` properties rather than the `location`
property, which moved into the `fileInfo` property anyway.
In our attempt to remove the material ripple effect from tab labels, we were
killing all `transform`-based animations on other `md-tab-group` elements, such
as animating the content when entering/leaving. (This wasn't an issue on Chrome,
because it didn't respect our `!important` flag.)
This commit fixes it by properly hiding the ripple effect (using a feature
introduced in angular/material2@e4789c7b8) and allowing other animations to
execute normally.
Fixes#17998
Now that we have upgraded to the latest lunr search engine, the results
from the standard `search` method are more appropriate.
So we do not need to create our own special queries to get good results.
Since 808bd4af4, we are no longer pre-verifying PRs before uploading the build
artifacts to the preview server, thus we no longer need the
`travis-preverify-pr.sh` script or the `GITHUB_TEAM_MEMBERSHIP_CHECK_KEY`
variable.
This commit adds an API endpoint for notifying the preview server about PR
updates (`/pr-updated`). According to the update, the preview server can take
several actions. Currently, it will only check and (if necessary) update the
PR's preview visibility (but more actions could be supported in the future).
The API can be used with an automatic trigger (e.g. a GitHub webhook) to
instantly update a PR's preview visibility when it changes.
Fixes#16526
Previously, `BuildCreator#changePrVisibility()` would throw an error if the PR's
visibility was already up-to-date or if the PR directory did not exist (e.g. was
removed). This method was only used from inside `BuildCreator#create()`, which
had already checked for the existence of the directories.
This commit renames `changePrVisibility()` to `updatePrVisibility()` and makes
it more "forgiving" (i.e. it will only throw if both public and non-public
directories exist). This allows it to be used on events that may or may not have
caused the PR's visibility to change (e.g. a GitHub webhook triggered whenever a
PR's labels change).
Previously, there was a distinction between GET requests to invalid URLs and all
other requests. This was mainly because the upload-server only accepts GET
requests, but that is not a hard limitation and may change in the future.
Thus, it makes sense to return a 404 response for requests to invalid URLs
regardless of the method used.
Previouly, whenever a new ServiceWorker update was detected the user was
prompted to update (with a notification). This turned out to be more distracting
than helpful. Also, one would get notifications on all open browser tabs/windows
and had to manually reload each one in order for the whole content (including
the app) to be updated.
This commit changes the update strategy as follows:
- Whenever a new update is detected, it is immediately activated (and all
tabs/windows will be notified).
- Once an update is activated (regardless of whether the activation was
initiated by the current tab/window or not), a flag will be set to do a
"full page navigation" the next time the user navigates to a document.
Benefits:
- All tabs/windows are updated asap.
- The updates are applied authomatically, without the user's needing to do
anything.
- The updates are applied in a way that:
a. Ensures that the app and content versions are always compatible.
b. Does not distract the user from their usual workflow.
NOTE:
The "full page navigation" may cause a flash (while the page is loading from
scratch), but this is expected to be minimal, since at that point almost all
necessary resources are cached by and served from the ServiceWorker.
Fixes#17539
mgechev
Georgios Kalpakas
cexbrayat
ksvitkovsky
Ward Bell
Kapunahele Wong
Kara Erickson
雪狼
Peter Bacon Darwin
tinayuangao
David Brooks
Øystein Lygre
Filipe Silva
chumtoadafuq
Antoine Mary
Gerard Sans
Jesus Rodriguez
Gabriel Nicolas Avellaneda
Jeremy Elbourn
Kevin Cooper
daydr3am
matt24ray
Stepan Suvorov
Thanesh Rajandran
Nicola Sanitate
Scotty Waggoner
Jesse Palmer
Alexey Toksarov
WilliamKoza
Kasidit Iamthong
Don Denton
Daniel Bunte
Stefanie Fluin
Alex Rickabaugh
Igor Minar
Jules Kremer
bmarkov
Ketan Gote
Sarah
Trotyl Yu
Wassim Chegham
Javier Revillas
Suguru Inatomi
Victor Berchet