camunda-docs
camunda-docs copied to clipboard
elasticsearch-exporter: Add link to index templates
It took me quite a while to dig the index templates out of the source based on the given hint. So, let's add the actual link and also point out that "this module" actually means the exporter source code: https://github.com/camunda/zeebe/tree/main/zeebe/exporters/elasticsearch-exporter/src/main/resources
Description
When should this change go live?
- [ ] This is a bug fix, security concern, or something that needs urgent release support.
- [x] This is already available but undocumented and should be released within a week.
- [ ] This on a specific schedule and the assignee will coordinate a release with the DevEx team. (apply
holdlabel or convert to draft PR) - [ ] There is no urgency with this change and can be released at any time.
PR Checklist
- [x] My changes are for an already released minor and are in
/versioned_docsdirectory. - [x] My changes are for the next minor and are in
/docsdirectory (aka/next/).
- [ ] My changes require an Engineering review, and I've assigned the Engineerring DRI or delegate.
- [ ] My changes require a technical writer review, and I've assigned @christinaausley as a reviewer.
:wave: :robot: :white_check_mark: Looks like the changes were ported across versions, nice job! :tada:
You can read more about the versioning within our docs in our documentation guidelines.
@christinaausley I don't have more time to work on this. Primarily, I wanted to report the documentation issue. Could your team please finish the versioned docs? This may also need special attention, when new releases come out.
@falko I can take this from here, thanks!
@npepinpe The stable branches should work, right? https://github.com/camunda/zeebe/tree/stable/8.5/zeebe/exporters/elasticsearch-exporter/src/main/resources
Yes, every supported version has a stable branch (e.g. stable/8.4, stable/8.5). However, once the version is not supported anymore, we remove this. For the docs, we seem to keep a copy of the unsupported versions, so the links would become broken eventually. As an alternative, using the tag would work better, e.g.
- 8.5.0: https://github.com/camunda/zeebe/blob/8.5.0/zeebe/exporters/opensearch-exporter/src/main/resources/zeebe-record-job-template.json
- 8.4.0: https://github.com/camunda/zeebe/blob/8.4.0/exporters/opensearch-exporter/src/main/resources/zeebe-record-job-template.json
- 8.3.0: https://github.com/camunda/zeebe/blob/8.3.0/exporters/opensearch-exporter/src/main/resources/zeebe-record-job-template.json
- 8.2.0: https://github.com/camunda/zeebe/blob/8.2.0/exporters/opensearch-exporter/src/main/resources/zeebe-record-job-template.json
And so on.
The downside here is:
mainalways points to latest, so on every release we need to update those links to point to the new tag.- The tags point to specific patch versions. Though, I don't expect us to change these things much between patches, it's not impossible if we introduced something incorrect.
Then a combination of linking to stable branches for maintained versions and to the last release tag for older unmaintained versions would work.
#3795 (comment)
@akeller Unless you have immediate thoughts, let's discuss this (as in both PRs) and the solution in our 1:1 this week? Would be worth a style guide addition.
I'll make a note to myself to adjust the latest link per each release 👍