Skip to content

Use subpages for third party deps and API #8757

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 37 commits into from
Jul 30, 2025
Merged

Conversation

barkbay
Copy link
Contributor

@barkbay barkbay commented Jul 18, 2025

This PR introduces some changes to generate third-party deps and API reference versioned pages.

Do not merge before 3.1

@barkbay barkbay added >docs Documentation v3.1.0 labels Jul 18, 2025
@prodsecmachine
Copy link
Collaborator

prodsecmachine commented Jul 18, 2025

🎉 Snyk checks have passed. No issues have been found so far.

security/snyk check is complete. No issues have been found. (View Details)

license/snyk check is complete. No issues have been found. (View Details)

@barkbay
Copy link
Contributor Author

barkbay commented Jul 18, 2025

Landing page does not look great with

toc:
  - file: index.md
  - file: api-docs.md
  - folder: third-party-dependencies
  - file: eck-configuration-flags.md
  - file: upgrade-predicates.md

⬇️

image

I don't understand why previous is "third-party deps" while I would expect it to be the next since it is a child?

@eedugon
Copy link
Contributor

eedugon commented Jul 18, 2025

I don't understand why previous is "third-party deps" while I would expect it to be the next since it is a child?

I think our previous views have some limitations, and maybe that's one of them.

Landing page does not look great with

What part you don't like and what would you like to improve? Maybe I can help you with that!

cd "$PROJECT_DIR"
go mod download
go list -m -json all | "${TEMP_DIR}"/go-licence-detector \
-depsTemplate="${SCRIPT_DIR}"/templates/dependencies.md.tmpl \
-depsOut="${PROJECT_DIR}"/docs/reference/third-party-dependencies.md \
-template-value=eckVersion="${version}" \
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@barkbay
Copy link
Contributor Author

barkbay commented Jul 21, 2025

Preview with the new template:
image

@barkbay
Copy link
Contributor Author

barkbay commented Jul 22, 2025

This PR is ready for review 🎉 , the preview is available here: https://docs-v3-preview.elastic.dev/elastic/cloud-on-k8s/pull/8757/reference

@@ -1,2073 +1,13 @@
---
mapped_pages:
- https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-api-reference.html
navigation_title: API Reference
navigation_title: API Reference (moved)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had to preserve that page because it is referenced in the docs-content repo, doc generation fails if I remove it. I believe we can fix that in a follow up PR once this one is merged.

Copy link
Collaborator

@pebrc pebrc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Nice work! As we release more versions of ECK we might have to revisit this strategy especially if there is an empty diff between versions it might make sense to think about grouping multiple versions in one document or something along those lines. But for now I am super happy we have a path forward.

@@ -4,7 +4,7 @@ mapped_pages:
navigation_title: API Reference for 3.0.0
applies_to:
deployment:
eck: ga 3.0.0
eck: ga 3.0.0, ga 3.1.0
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pebrc I tested what we discussed out of band, here is the result:

image

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice! This opens then indeed the door to collapse documentation for mulitple versions into one page.

This reverts commit 29d20d8.
@eedugon
Copy link
Contributor

eedugon commented Jul 22, 2025

@barkbay : should we remove the API reference and 3PP references docs identified as from the main branch? What's the value of them when we'll have the 3.0.0 and 3.0.1 versions published?

Copy link
Contributor

@shainaraskas shainaraskas Jul 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just quickly diffed the two api references and I'm not seeing any substantive differences (one line about fleet advanced config). do we need to generate these as separate pages right now? do you expect substantive development to come to this area soon?

I also wonder how the versioning approach for the API packages (e.g. v1, v1beta1, v1alpha1) interact with the versioning for ECK itself. it feels possibly like the API reference needs to follow its own versioning scheme based on these hints.

if that's the case, maybe we could state which api versions are compatible with which stack versions as an alternative

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one line about fleet advanced config

This is something new in ECK 3.1.0, which was not supported in 3.0.0. So I think I would keep 2 separate files.

I also wonder how the versioning approach for the API packages (e.g. v1, v1beta1, v1alpha1) interact with the versioning for ECK itself.

Each K8S API version stage can be used to represent a different maturity and stability level. When a new version is introduced it also requires a change in the operator. They are not related to stack versions.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is something new in ECK 3.1.0, which was not supported in 3.0.0. So I think I would keep 2 separate files.

this is the substance of the change:

image image

the change does not seem to a change to the API functionality (unless this is missing a related value for the new config model). Given this, I'd rather rely on the applicability information in the core docs than generate a whole new API reference for a clarifying sentence.

Each K8S API version stage can be used to represent a different maturity and stability level. When a new version is introduced it also requires a change in the operator. They are not related to stack versions.

it sounds like the version stage doesn't actually guarantee specific behavior independently of the eck version, so it still makes sense to use the ECK version as the primary versioning model 👍

@shainaraskas
Copy link
Contributor

should we remove the API reference and 3PP references docs identified as from the main branch? What's the value of them when we'll have the 3.0.0 and 3.0.1 versions published?

if we still want to generate them for internal/dev use, we could consider making them hidden files so they can be visited but not consumed by readers who might be confused by them

Copy link
Contributor

@shainaraskas shainaraskas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overall, this looks really great, and thank you for taking on the effort of refactoring the generation so quickly. my key piece of feedback is that we should think about the long-term vision for the API reference before we build a bunch of pages we need to maintain long term.


# Third-party dependencies [k8s-reference-dependencies]

This section contains reference information about third-party dependencies used by {{eck}}.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this file should ideally link to the children in the section

@@ -1,6 +1,7 @@
toc:
- file: index.md
- file: api-docs.md
- file: third-party-dependencies.md
- folder: api-reference
- folder: third-party-dependencies
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that because we're using this folder model rather than a file/children model, these are being listed in a weird order. ideally, we'd list these dependency files from newest to oldest:

image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes 😕 , I think it would be a bit more complex to automate the generation of these files with the file/children model.

@barkbay
Copy link
Contributor Author

barkbay commented Jul 23, 2025

What's the value of them when we'll have the 3.0.0 and 3.1.0 versions published?

IIRC we have to document third-party dependencies for compliance purposes, not sure if this includes the ones currently referenced by the project in its main branch though. I think it is also helpful to ensure that we can always generate these files, without waiting for a new release branch to be created. So maybe we can hide them as suggested, @pebrc do you have an opinion?

@barkbay
Copy link
Contributor Author

barkbay commented Jul 23, 2025

Preview of the new navigation titles:

image

@pebrc
Copy link
Collaborator

pebrc commented Jul 23, 2025

What's the value of them when we'll have the 3.0.0 and 3.1.0 versions published?

IIRC we have to document third-party dependencies for compliance purposes, not sure if this includes the ones currently referenced by the project in its main branch though. I think it is also helpful to ensure that we can always generate these files, without waiting for a new release branch to be created. So maybe we can hide them as suggested, @pebrc do you have an opinion?

Hiding the file for the main branch sounds like a good option to me. And I agree we should keep generating the file for main to make sure your our generation tooling is functional.

@barkbay
Copy link
Contributor Author

barkbay commented Jul 23, 2025

if we still want to generate them for internal/dev use, we could consider making them hidden files so they can be visited but not consumed by readers who might be confused by them

Are hidden files compatible with the fact that we want to avoid the file/children model?

@shainaraskas
Copy link
Contributor

Are hidden files compatible with the fact that we want to avoid the file/children model?

unfortunately, I don't think so. if we needed to, we could ship this and revisit a more granular toc separately.

@barkbay barkbay merged commit 6b3487d into elastic:main Jul 30, 2025
9 checks passed
@barkbay barkbay deleted the docs/subpages branch July 30, 2025 07:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>docs Documentation v3.1.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants