Conversation
03d8a78 to
4ca14dd
Compare
🌐 Coverage report
|
|
/test |
mtojek
left a comment
There was a problem hiding this comment.
I'm not sure if I fully understand what's the purposes of this PR. Do you want to add a new file to a package? Is it necessary to be a .csv file?
If so, I would start with a package-spec issue to decide about the form of the file first.
I see that the description of the PR lacked some information regarding this proposal as a first step to solve elastic/integrations#2652. I'll give some more information here (and I'll update the description accordingly afterwards). With this PR, my proposal is adding a file at the root of "integrations" repository that contains all the links to elastic documentation pages. Being there, all these links will be available and shared by all the packages in building time ( As that file would be out of the package scope, at least with this design, it should not be added to the package-spec. |
|
Yeah, but keep in mind that Elastic packages shouldn't have a strong coupling between with elastic/integrations repository. They can be stored in any place. EDIT: I'm wondering if we can decouple |
That way is way more flexible. Avoiding hard-coding the filename and the path where it should be located will help to avoid issues. Maybe later it needs to be changed to some other folder that file or just being renamed, and that should be independent of elastic-package. In case ENV is not defined, it could be kept looking in the root of the repository. I will look into it to update this PR accordingly. Thanks for the suggestion! About csv vs YAML, as first step I just wanted to follow the same structure it was shown as example in the main issue (example). But definetly, this can be changed later to YAML format. Probably easier to read. Just some other possible format using YAML: links:
link_key: http://url1.test
foo_key: http://url2.test |
I've added new tests for
EDIT: |
mtojek
left a comment
There was a problem hiding this comment.
Would it be better to add a new package? Would that test something else?
If you ask me, more tests are always better. The benefit of adding a package is that we can catch if the README.md changed. With unit tests, you won't catch it if the calling function suddenly disappears.
If you don't want to create a test package, you can modify an existing one.
docs/howto/add_package_readme.md
Outdated
| foo,http://url.com.test | ||
| help,http://other.url.com/help |
docs/howto/add_package_readme.md
Outdated
| foo,http://url.com.test | ||
| help,http://other.url.com/help |
| } | ||
|
|
||
| func renderReadme(fileName, packageRoot, templatePath string) ([]byte, error) { | ||
| func renderReadme(fileName, packageRoot, templatePath string, linksMap linkMap) ([]byte, error) { |
There was a problem hiding this comment.
Yeah, I wouldn't preoptimize it. If it becomes a bottleneck in the future, we can refactor it.
|
/test |
|
/test |
Closes #948
This PR adds a new function ("url") available into Readme templates to render links based on the
eventandfieldsfunctions. All links will be defined in a common file that will be the source of truth.This intended to be used in integrations repository where a specific
csv fileYAML filelinks_table.csvlinks_table.ymlcontaining all the available links is defined.This file should be placed at the root of the integrations repository and it should follow this pattern:
Being there at the root of the repository, this file (all the links) are available and shared by all the packages defined in the repository in building time (
elastic-package build).Example of usages in the README using the above file as basis: