You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
By opting in explicitly we can pull these links map down at build down to validate a single docsets outbound links ahead of time.
To that end we need to extend our GitHub action to be able to publish these to a known guessable folder scheme to S3 and expose them under a nice URL through CloudFront so docs-builder can download them.
We need some form of caching e.g if the url ends up being:
/links/elasticsearch/main/links.json
We don't want to pull it down every time.
The text was updated successfully, but these errors were encountered:
With the migration to docs-builder, we will move away from product documentation books and towards more goal-focussed documentation sets (docsets). Here are the new docsets and a starting point for what their prefixes could be:
Right now
docsbuilder
only validates:What we don't support is linking to other people's docset's.
We don't want documentation authors to create links such as:
This will require crawling and live link validation which comes with its own set of challenges but most importantly won't be fast.
Instead the syntax we would be after is:
Where
es
is a prefix moniker that gets declared indocset.yml
As part of each build today we publish a links.json file.
By opting in explicitly we can pull these links map down at build down to validate a single docsets outbound links ahead of time.
To that end we need to extend our GitHub action to be able to publish these to a known guessable folder scheme to S3 and expose them under a nice URL through CloudFront so
docs-builder
can download them.We need some form of caching e.g if the url ends up being:
We don't want to pull it down every time.
The text was updated successfully, but these errors were encountered: