Previously, only a few characters of the SHA would appear on the preview link
comment posted on the PR. This was usually enough for GitHub to create a link to
the corresponding commit, but it was possible to have collisions with other
commits with the same first characters (which prevented GitHub from identifying
the correct commit and create a link.)
This commit fixes this issue by including the full SHA on the commentso GitHub
can identify the correct commit and create the link. GitHub will automatically
truncate the link text (by default to 7 chars unless more are necessary to
uniquely identify the commit).
Previously, when trying to upload the build artifacts for a PR/SHA that was
already successfully deployed (e.g. when re-running a Travis job), the preview
server would return a 403 and the build would fail.
Since we have other mechanisms to verify that the PR author is trusted and the
artifacts do indeed come from the specified PR and since the new artifacts
should be the same with the already deployed ones (same SHA), there is no reason
to fail the build. The preview server will reject the request with a special
HTTP status code (409 - Conflict), which the `deploy-preview` script will
recognize and exit with 0.
Don’t show the side nav in mobile (not side-by-side) view when arriving or navigating.
Only show it by request.
The side nav should continue to appear in wide mode (side-by-side) when navigating from a marketing page to a guide page.
The implementation adds three plugins to the remark processor:
* remove support for code blocks triggered by indented
text - only gfm triple backticks are supported; and also adds support for
dgeni inline tags.
* ignore content within `code-example` and `code-tabs` elements. This prevents
the content being accidentally treated as markdown
* ignore dgeni inline tags, e.g. `{@link ... }` to prevent the content of
the links from being accidentally treated as markdown
Sometimes, depending on the length of lines, anchor elements would be formatted
incorrectly by `html.prettyPrint` and the space right after the element was
removed.
This was apparently caused by a bug in `html.prettyPrint` in combination with
its default behavior of wrapping lines at a specific limit (70 chars). Since the
output is only meant to be used as JSON string data, wrapping the lines makes it
less readable by adding unnecessary `\n`.
This commit disables the line wrapping, which effectively avoids the bug that
was responsible for incorrectly formatting anchor elements and surrounding
space.
Related to #15681.
