There are currently about 15 hard-coded links to the Elastic documentation in the /_dev/build/docs/README files. As we add more integrations, however, that list will grow and as we move to the new documentation system, those URLs will need to be updated.
Given that we already have some content substitution in the README source files, such as the following in the Apache integration readme:
{{event "status"}}
{{fields "status"}}
... Can we do something similar to obfuscate the documentation links?
In the Elasticsearch API specifications, we're accomplishing this with a very simple list of keywords and URLS (https://github.com/elastic/elasticsearch-specification/blob/main/specification/_doc_ids/table.csv). We use the keywords in the source files and when the output is generated, it replaces the keyword with the full URL. If we did something similar here, at the point where the package is built and the finalized README is generated, it would mean we could have a single source of truth for the doc URLs, which is easier to maintain.
There are currently about 15 hard-coded links to the Elastic documentation in the /_dev/build/docs/README files. As we add more integrations, however, that list will grow and as we move to the new documentation system, those URLs will need to be updated.
Given that we already have some content substitution in the README source files, such as the following in the Apache integration readme:
... Can we do something similar to obfuscate the documentation links?
In the Elasticsearch API specifications, we're accomplishing this with a very simple list of keywords and URLS (https://github.com/elastic/elasticsearch-specification/blob/main/specification/_doc_ids/table.csv). We use the keywords in the source files and when the output is generated, it replaces the keyword with the full URL. If we did something similar here, at the point where the package is built and the finalized README is generated, it would mean we could have a single source of truth for the doc URLs, which is easier to maintain.