-
Notifications
You must be signed in to change notification settings - Fork 29
Product Configuration #1865
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
base: main
Are you sure you want to change the base?
Product Configuration #1865
Conversation
…roduct metadata, and substitution support for them
# Conflicts: # config/legacy-url-mappings.yml # src/tooling/docs-assembler/Cli/RepositoryCommands.cs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@elastic/docs-engineering I think this PR would also solve #1497
What happens with existing product subs define in docset.yml files, by the way? Should we prefer products.yml driven substitutions from now on?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few small nits and q's.
Would be good to include more tests on resolving product names and their attached versioning schemes.
src/Elastic.Documentation.Configuration/ConfigurationFileProvider.cs
Outdated
Show resolved
Hide resolved
Co-authored-by: Fabrizio Ferri-Benedetti <fabri.ferribenedetti@elastic.co>
Fabrizio with the save. Co-authored-by: Fabrizio Ferri-Benedetti <fabri.ferribenedetti@elastic.co>
Smoke tests are failing. We should run a full assembler build to validate. |
I share this confusion - can we maybe reference these in docset.yml so we can keep using the same variables? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
threw some comments on where I could. I suggested a couple of terminology fixes and version # fixes
I'd like to better understand how this actually impacts the functionality of the dropdown - maybe a quick demo could be helpful, or even just explaining using an image of the dropdown what info is populated from where. want to understand what is actually changing with the experience based on these changes
display: 'Elasticsearch Curator' | ||
versioning: 'curator' | ||
ecs: | ||
display: 'Elastic Common Schema (ECS)' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we want brackets on these? @colleenmcginnis
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It depends on how this value is being used. Recently @KOTungseth requested that we use Elastic Common Schema (ECS)
as the page title (elastic/docs-content#2212).
config/legacy-url-mappings.yml
Outdated
product: elastic-agent | ||
legacy_versions: *stack | ||
en/ingest-overview/: | ||
product: elasticsearch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not elasticsearch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've changed these to elastic-stack for now. Which entry would be more suitable?
config/legacy-url-mappings.yml
Outdated
product: elasticsearch | ||
legacy_versions: [] | ||
en/ingest/: | ||
product: elasticsearch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not elasticsearch
config/legacy-url-mappings.yml
Outdated
product: cloud-serverless | ||
legacy_versions: [] | ||
en/starting-with-the-elasticsearch-platform-and-its-solutions/: | ||
product: elasticsearch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not elasticsearch
# Conflicts: # config/versions.yml # src/Elastic.Markdown/HtmlWriter.cs
For now, the current behavior of the dropdown is maintained - we just have more information wired in to perform further adjustments later on. Usage is the same. |
Co-authored-by: shainaraskas <58563081+shainaraskas@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this looks good for the products I have knowledge of now (without being able to see how the elements are integrated in practice)
flagged one thing from the dev docs area for search ui versioning
would suggest that someone from the other docs teams (ingest and dev particularly) do a pass at this for product names and versions
legacy_versions: [] | ||
en/search-ui/: | ||
product: search-ui | ||
legacy_versions: ['1.24.1', '1.24.0'] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think these docs were versionless so there would be no legacy versions. current version is for 1.24+
Co-authored-by: shainaraskas <58563081+shainaraskas@users.noreply.github.com>
legacy_versions: [ '0.x' ] | ||
en/apm/agent/dotnet/: | ||
product: apm-agent-dotnet | ||
legacy_versions: [ '1.33.0' ] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think there should be any legacy versions for APM .NET agent.
legacy_versions: [ '1.33.0' ] | |
legacy_versions: [] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not clear if legacy_versions
should include the latest version or not.
For example, when I build the docs locally using this branch, on the APM Go agent pages, I only see 0.5
in the version dropdown, but I would expect to see 1.x
and 0.5
.

Similarly, for Stack-versioned pages, I'm seeing the 8.x
list start with 8.18
instead of 8.19
.

After I get clarity, I'll need to request more updates on the ingest-related items in this file.
apm-agent-android: | ||
display: 'APM Agent for Android' | ||
versioning: 'apm_agent_android' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@theletterf should we remove this in favor of edot-android
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know. It's the same in versions.yml
. All new documents use edot_
, but the old ones don't. I don't know if keeping this here is required for some backward compatible mechanism. Is it, @cotti?
Otherwise, I would just keep edot_android
and edot_ios
.
apm-agent-ios: | ||
display: 'APM Agent for iOS' | ||
versioning: 'apm_agent_ios' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@theletterf should we remove this in favor of edot-ios
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
edot-sdk: | ||
display: 'Elastic Distribution of OpenTelemetry SDK' | ||
versioning: 'stack' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@theletterf does this make sense as a product? It wouldn't have a single versioning system (stack
). 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, nope, it doesn't. Would this be the required edit?
edot-sdk: | |
display: 'Elastic Distribution of OpenTelemetry SDK' | |
versioning: 'stack' | |
edot-sdk: | |
display: 'Elastic Distribution of OpenTelemetry SDK' | |
versioning: 'all' |
versioning: 'stack' | ||
ess: | ||
display: 'Elastic Cloud Hosted' | ||
versioning: 'all' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is all
the same as unversioned?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same question.
apm-agent: | ||
display: 'APM Agent' | ||
versioning: 'stack' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we keep this and versioning: 'all'
means unversioned, I wonder if we should use that since no APM Agent is Stack versioned. 🤔 cc @theletterf
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed — if adding all
is indeed the right option to get a versionless product listed.
apm-agent: | |
display: 'APM Agent' | |
versioning: 'stack' | |
apm-agent: | |
display: 'APM Agent' | |
versioning: 'all' |
Co-authored-by: Colleen McGinnis <colleen.mcginnis@elastic.co>
Co-authored-by: Colleen McGinnis <colleen.mcginnis@elastic.co>
Co-authored-by: Colleen McGinnis <colleen.mcginnis@elastic.co>
Co-authored-by: Colleen McGinnis <colleen.mcginnis@elastic.co>
base: 0.1 | ||
current: 0.2.0 | ||
|
||
# Logging |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@shainaraskas @colleenmcginnis We can add UpdateCLI automated version bumps for these, too, in a follow-up PR.
Co-authored-by: Colleen McGinnis <colleen.mcginnis@elastic.co>
Co-authored-by: Colleen McGinnis <colleen.mcginnis@elastic.co>
Handles #1637
This PR performs a few refactorings into how we deal with product, versioning and legacy URL mapping definitions.
Configuration
products.yml
andlegacy-url-mappings.yml
occurs during early service bootstrapping.Products Listing
products.yml
file to gather essential product metadata. Currently, we have a friendly label for each, and reference the versioning system adopted by the project in question.Versioning
Legacy Url Mapping
legacy-url-mappings.yml
has been reviewed to include a reference to a product. Most entries have a direct correlation. For a few cases, a best-match approach was taken.Docs