| Age | Commit message (Collapse) | Author |
|---|
|
Suppose in raw markdown we have:
```markdown
See [foo][barr].
[bar]: https://link-to-bar
```
The intent is to link the text "foo", but because of a typo it used the
label barr instead of bar. The result is that the rendered html won't
have a link at all. The text will be rendered literally as
`[foo][barr]`. Since there's no link (not even a broken one), a link
checker run over the rendered output won't spot the problem.
The mdbook-linkcheck plugin correctly detects this issue. However, it
doesn't understand links that go between our two mdbook projects since
the relative paths in the source don't match the relative paths in the
rendered output. Since checking whether the links are non-broken is
already covered by `bin/check_links` (using linklint), we can disable
checking the link destinations altogether.
|
|
My goal here is to only run MMDC when building main and about to
deploy it for the specs.
|
|
|
|
CI jobs run as root. chrome hates that.
See
https://github.com/mermaid-js/mermaid-cli/blob/HEAD/docs/linux-sandbox-issue.md
|
|
This still doesn't work because there's one more wrinkle.
|
|
That will make the organisation of this job better when new runes
arrive that depends on these packages.
|
|
!194 + !193
|
|
Fix broken links and check in CI that we don't introduce new ones
Closes #238
See merge request tpo/core/torspec!194
|
|
|
|
This should make the CI complete in seconds rather than ~ a minute.
|
|
Putting ".sh" or ".py" on the end of scripts is an antipattern.
It makes it inconvenient to change the implementation language.
Change all call sites.
|
|
Instead, do a nice Rust image, and install mdbook from source. This
is bandwidth- and cpu-inefficient, sadly, but it does get us an
up-to-date version of mdbook.
|
|
|
|
|
|
Those will clutter each other and just lead to confusion. The pages
job is just a helper for users outside the repository, so it doesn't
make sense to run it there.
This uses the `CI_PROJECT_ROOT_NAMESPACE` variable (`tpo`) instead of
the full project name so that it can be retrofitted into the template
after testing.
|
|
This makes GitLab CI try to push the site to the static-shim
server. This will should succeed, because we have added the key in
Puppet, but will ultimately fail to deploy because the static
component hasn't been setup properly yet.
We're hoping to setup review apps so that we can see a real version of
this before switching off the old spec.tpo.
|
|
The `pages-deploy.yml` target will "do the right thing" for us here,
it's useless for us to figure out how exactly to do the pages dance
here, let's just delegate.
Alternatively, we could "vendor" that code in here, but then we lose
the benefit of improvements TPA might make here in the future. Also:
this will make it easier to enable the static shim once it's ready.
|
|
The `check` job is really a build job here, since it actually does
build the website. It just doesn't keep artifacts around... So let's
do that, and make the `pages` job just reuse those instead of
rebuilding from scratch.
This is part of migrating torspec to a static component, as we need
artifacts for the built site to be sent in to the static component
system.
See tpo/tpa/team#41348
|
|
|
|
|
|
This test just tries to make sure reindex has been run,
and that mdbook passes.
|
|
|
|
|
|
|
|
This does a rough conversion to Markdown using regexps, then uses pandoc to
convert the Markdown to HTML. An index.html is also generated to make it
easy to find the various documents. This will create a site in any GitLab
fork that has CI/CD and Pages setup, which is the default on gitlab.com.
|
