Adds applicability support for a new serverless project - #3872
Conversation
theletterf
left a comment
theletterf
left a comment
There was a problem hiding this comment.
OK from my PoV. +CC @shainaraskas @florent-leborgne
|
LGTM but just a thought: would |
|
what florent said! |
Very good point, thank you! I've updated the YAML key to: |
I'm actually not sure about this one at all -- is this the right implementation for this? It kind of seems wrong, when we use |
Right. It should. Is there anything idiosyncratic about vectorDB project type that might upset this apple cart?
This is kinda nonsense. Serverless is versionless so "the past" is meaningless in this context. And all project-types are opt-in 🤔 .
Footnotes
|
|
And now I'm stuck and don't know how to fix the failures (Cursor is suggesting I update a hash in a test, but I'm not sure I should be doing that). @Mpdreamz -- I'll leave this is your capable hands for a review 🥺. |
|
@copilot Fix the CI errors. |
Co-authored-by: theletterf <1773616+theletterf@users.noreply.github.com>
Addressed in |
|
@copilot can you fix these failing checks please |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
LGTM.
What is this? | From workflow: PR Review
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
|
@copilot Fix the CI errors. |
|
@copilot Be a good lad and fix the red CIs :) |
Co-authored-by: theletterf <1773616+theletterf@users.noreply.github.com>
Fixed in the latest commit. The CI failure was due to whitespace formatting issues in |
There was a problem hiding this comment.
Requesting changes: there is a correctness regression in mixed applies_to syntax where serverless: plus top-level vectordb: can silently drop existing serverless project applicability. Please address that merge/override behavior before merge.
What is this? | From workflow: PR Review
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
Prevent generic serverless applicability from being silently narrowed when a top-level serverless project key is also present. Co-authored-by: GPT-5.5 <gpt-5.5@users.noreply.github.com>
Merge project-specific overrides into generic serverless applicability, and cover documentation, LLM rendering, and search indexing paths. Co-authored-by: GPT-5.6 Sol <gpt-5.6-sol@users.noreply.github.com>
Clone the generic serverless record before applying project overrides so parsing one document cannot alter defaults used by later documents. Co-authored-by: GPT-5.6 Sol <gpt-5.6-sol@users.noreply.github.com>
Use the analyzer-preferred conditional expression without changing serverless merge behavior. Co-authored-by: GPT-5.6 Sol <gpt-5.6-sol@users.noreply.github.com>
All findings from this automated review were addressed and their threads resolved. The follow-up review rerun reported NO_FINDINGS but could not publish a replacement decision because the Copilot provider returned HTTP 403.
Summary
Fixes #1631
The new Serverless Elasticsearch Vector Database project type needs to have an applicability tag equivalent to the other project types (Elasticsearch, Observability, Security).
This project type already has a https://github.com/elastic/docs-content-internal/issues/1534.
The ask
'docs-builder' tooling functionality needs to be amended to allow for the new applicability.
I took at stab at this PR using Cursor (default agent), but am not comfortable at all with the the accuracy/correctness of this proposed solution. So this needs a thorough review from the Docs Engineering team 🙏
Please feel free to update this PR directly.
Details about the changes
Vector Database is a serverless-only, unversioned project type. Unlike Elasticsearch, Observability, and Security — which also exist as Stack solutions — this project type only exists on Elastic Cloud Serverless. That is why it uses the existing serverless versioning system (the same unversioned sentinel as serverless: ga) instead of getting its own versioning ID.
applies_tonow has a fourth serverless flavor:vectorbd. Writers can tag serverless.vectordb: ga (or top-level vectordb: ga). Versions are rejected, same as elasticsearch / observability / security.serverless: ga (and empty serverless:) now applies to all four project types: Elasticsearch, Observability, Security, and Vector Database.
When those four share the same lifecycle, they still collapse to the generic Serverless badge. A page only shows Serverless Vector Database when vectordb is tagged on its own, or when its lifecycle differs from the others.
serverless: gastill means the original three project types. Expanding it to Vector Database would have marked every existing serverless page as applying to a project type that did not exist when those tags were written. Vector Database is opt-in; a page only claims it when tagged explicitly.Badges follow the same pattern as the other project types, with a longer popover/LLM name because the product is “Elasticsearch Vector Database”: badge Serverless Vector Database, popover Serverless Elasticsearch Vector Database projects.