Repository navigation
Conversation
|
Understand this PR’s impact Explore downstream dependencies and potential security impact with Blast Radius. Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughChangesThe pull request adds a searchable Clients and Integrations catalog. It adds catalog metadata, build-time validation, responsive styling, client-side filtering, navigation, submission guidance, and local testing documentation. Libraries and integrations catalog
Assessment against linked issues
Fixed issue severityPriority: ➖ Normal Severity of issue fixed: Medium Merge Risk: 🔵 Low · up to The catalog remains usable with pointer controls, but keyboard and assistive-technology users may not receive the behavior promised by the tab controls. Resolve or explicitly accept this accessibility gap before merging. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Depends on valkey-io/valkey-doc#459 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/zola-deploy.yml:
- Around line 60-62: Pin the valkey-doc checkout used by the CI workflow and the
clone command in LOCAL_TESTING.md to the same explicit branch, tag, or commit.
Update .github/workflows/zola-deploy.yml around build/init-topics-and-clients.sh
and LOCAL_TESTING.md at the valkey-doc clone so both environments consume the
intended revision consistently.
In `@build/init-topics-and-clients.sh`:
- Around line 86-90: Update the build-ai symlink creation block to replace stale
links rather than invoking ln against an existing destination. Preserve the
existing conditional, quote the $3 target path, and use the same forced
symbolic-link handling as the build-clients path: -ln -sfn "$3" ./build-ai.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 32359ff3-0bda-4be2-ad04-34383ce63be0
📒 Files selected for processing (9)
.github/workflows/zola-deploy.yml.gitignoreLOCAL_TESTING.mdbuild/init-topics-and-clients.shconfig.tomlcontent/ai/_index.mdtemplates/ai-list.htmltemplates/default.htmltemplates/macros/docs.html
 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
build/init-topics-and-clients.sh (1)
32-35: 🩺 Stability & Availability | 🟠 Major | ⚡ Quick winProvide
../valkey-doc/aibefore this validation.The deployment workflow passes
../valkey-doc/ai, but the pipeline reports that this directory does not exist. This validation exits beforebuild-aiis created, so deployment cannot proceed. Update thevalkey-doccheckout or dependency setup so the directory exists before this script runs. Keep the validation in place.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@build/init-topics-and-clients.sh` around lines 32 - 35, Ensure the deployment workflow checks out or provisions the valkey-doc dependency at ../valkey-doc/ai before invoking the initialization script, so its existing directory validation passes. Keep the validation in init-topics-and-clients.sh unchanged.Source: Pipeline failures
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@build/init-topics-and-clients.sh`:
- Around line 32-35: Ensure the deployment workflow checks out or provisions the
valkey-doc dependency at ../valkey-doc/ai before invoking the initialization
script, so its existing directory validation passes. Keep the validation in
init-topics-and-clients.sh unchanged.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 524fc7e5-c370-4636-a7de-46752f7aac58
📒 Files selected for processing (1)
build/init-topics-and-clients.sh
|
@jbrinkman Btw, there is a deployment failure, which means the site won't build, please check that. |
@madolson This PR depends on the Valkey-Doc change valkey-io/valkey-doc#459 as noted in the description. Once that is reviewed/merged, then it will allow the build CI step to complete. This is the same mechanism used for the Clients page on the website. |
stockholmux
left a comment
stockholmux
left a comment
There was a problem hiding this comment.
This seems to include none of the requested feedback I posted.
Also I'd rather not create another cross repo dependency.
Implement comprehensive AI Libraries page showing AI/ML libraries that support Valkey for caching, vector storage, and memory management. Changes: - Update build/init-topics-and-clients.sh to accept AI path as 3rd parameter - Add ai_json_path configuration to config.toml - Create content/ai/_index.md with 14 AI libraries listed - Create templates/ai-list.html for AI libraries display with proper whitespace control to prevent excessive blank lines in output - Update ai-list.html to display Description and Valkey Uses fields between Repo and Installation for better context - Add ai_json_path() macro to templates/macros/docs.html - Update templates/default.html to add AI Libraries to navigation menu - Update .github/workflows/zola-deploy.yml to include AI libraries in build - Add LOCAL_TESTING.md documentation for local development - Add build-ai to .gitignore The page displays AI libraries organized by language (Python, JavaScript, Java, Lua) with details including: - Repository link - Description (what the library does and why to use it) - Valkey Uses (how Valkey is used: vector store, caching, memory, etc.) - Installation instructions - Version and release date - License Successfully tested locally with Zola build - 257 pages generated including the new AI libraries page at /ai/ with clean HTML output and all new fields displaying correctly. Signed-off-by: Joseph Brinkman <joe.brinkman@improving.com>
Replace ln -s with ln -sfn and quote path variables to handle stale symlinks and paths containing spaces. Also replace [ -o ] with || per POSIX best practices (ShellCheck SC2166). Applied consistently to all three symlink blocks (topics, clients, AI). Signed-off-by: Joseph Brinkman <joe.brinkman@improving.com>
Signed-off-by: Riley Desserre <riley.desserre@improving.com>
a1d7a23 to
5d30c03
Compare
The current state of the UI, trying to incorporate all feedback provided and discussed. |
Content audit: remove 20 entries, correct 12, add 8Full audit detail, folded for readability — methodology, per-entry rationale, and the complete removal / addition / correction lists. 👉 The one thing needing an answer is in a separate short comment below. Nothing in here is a question. Expand: full audit detailFollow-up to #602, targeting This applies the outcome of a content audit (AEA-691) over every entry on this branch, ahead of the handoff to the Valkey project.
What this PR does now
Commits are ordered so each is reviewable on its own: removals, then field corrections + additions, then the final edits. MethodologyEvery entry started disqualified and had to earn re-inclusion. A remove-on-suspicion audit keeps whatever nobody happens to challenge; deny-by-default forces a positive case for each entry. 1. Functional verification against a live server32 verification runs, one project per run, each isolated: cloned fresh, built from source where required, exercised against a real Valkey server in its own container on its own port ( "It connects" was not a pass. The bar was set per entry type:
Every result was cross-checked server-side rather than trusting the client: Results were graded by confidence — functional proof, reproducible workaround, or static analysis only — with static positives treated as weak and static decisive negatives as strong. Two entries are retained on non-Tier-1 evidence and both say so in the trail, rather than being rounded up. 2. Source inspection, not README readingAn early pass checked READMEs and published API docs and produced false negatives — projects wrongly assessed as having no Valkey support. The method was corrected to: clone, grep the entire tree for every spelling of Valkey, read the dependency manifests directly, and search history for support that was renamed or removed. That correction changed real outcomes, five times. README absence turned out to carry no information at all:
One of them explains why: its README never enumerates backends at all. A README is a marketing surface, not a dependency manifest. 3. Human ratification of every decisionNo entry was removed or retained on tooling judgment. Verification produced verbatim audit trails — roughly 23,000 lines across the 32 runs, recording actual commands and actual output rather than summaries. Every client and integration trail was read individually, looking for the markers that separate a real integration from an incidental one: which client library is actually imported, whether Valkey is named in the project's own manifests and docs, whether Valkey-specific code, tests or CI exist, whether a version floor is published, and whether the functional proof exercised the project's own Valkey code path rather than something adjacent. Where a trail's conclusion did not hold up against its own raw output, the conclusion was overturned — which is how the reinstatements were caught, and how several claims in our own catalog were found wrong. Tooling gathered and graded evidence; the inclusion decision was mine. ClassificationThree outcomes rather than two, because "remove" was hiding two different situations:
Removals (20)Disqualified (16) — no route backNo first-class Valkey integration to fix (8). These work only because Valkey speaks RESP: they depend on a Redis client, name Valkey nowhere, and have no Valkey CI, docs, or changelog entry. Adding support would be a feature request upstream, not a correction.
Whole project stale or abandoned (5). Not merely the Valkey parts — no maintainer is present to merge a fix: Audience (2). Both serve people developing Valkey itself: Licence (1).
|
| Entry | Integration | Defect |
|---|---|---|
recall |
official @valkey/valkey-glide + dedicated adapter |
README install command at line 294 installs nothing; the working commands already exist at lines 313 and 494 |
db-gpt |
valkey-glide, 870-line vector store |
3 undeclared runtime dependencies prevent import dbgpt.core after a documented install |
langchain-aws |
real ValkeyVectorStore on GLIDE |
from_texts() raises — check_index_exists catches the wrong exception type; unfixed in a released version ~6 months |
langchain4j-valkey |
io.valkey:valkey-glide directly |
published pom declares glide with an unresolvable ${os.detected.classifier}, so consumers get the native-less jar and fail on first call |
Deliberately excluded from these findings: anything that is our problem (catalog wording, install fields) and anything the project documents by design.
One further removal, on a rule rather than a defect
localai — its Valkey support is real and first class (go.mod requires valkey-io/valkey-go), MIT, actively maintained. Nothing is wrong with the project. But its Valkey backend is not in the default image: it is a separately published gallery artifact, so using it is a two-step operation, and installCommand holds one string. Every candidate value was tested and none delivers the advertised capability — docker run localai/localai gets the product without the backend. Rather than add a schema field or ship a misleading one-liner, the entry comes out. It qualifies again if the backend ships in the default image.
Additions (8)
All functionally verified; each has a trail.
| Entry | Evidence | Integration |
|---|---|---|
litellm |
Tier 1 — FT._LIST → its index, FT.INFO → VECTOR dim 8 COSINE |
2nd class, and deliberately so: its own docstring explains that RedisVL cannot drive valkey-search, so they wrote a Valkey-specific backend that bypasses it |
langbot |
Tier 1 — KNN ordering verified arithmetically | 1st class, glide's native ft namespace |
agno |
Tier 1 on both surfaces, tested on two servers | 1st class, valkey-glide-sync |
langflow |
Tier 1 — components driven from the published wheel | mixed: vector store 1st class via glide, chat memory 2nd class via redis-py |
semantic-router |
Tier 2 — FT.CREATE vector lifted verbatim from source, accepted by a live server |
1st class, valkey-glide/go/v2 |
valkey-mcp-server |
operator-attested | 1st class, built on GLIDE |
valkey-message-queue-starter |
operator-attested | 1st class, sole datastore dep is @valkey/valkey-glide |
semantic-router is named vLLM Semantic Router, not "vLLM" — see above.
Corrections to retained entries (12)
Each was found by testing, not by reading:
sidekiq— description said "for Rails applications". Upstream says any Ruby app, and this was disproved functionally by running a worker with no Rails present. Repository also movedmperham/sidekiq→sidekiq/sidekiq.valkey-py— feature flags110000001→111000101. Two false negatives proven against a live server: pubsub state restoration and client-side caching both work.valkey-admin— described as a "desktop app". It is web-based.rq— wrong SPDX licence identifier; repository and description corrected.spring-data-valkey— had noinstallCommand. Its coordinate is a three-segment vendor namespace (io.valkey.springframework.data) that could not have been guessed.- Install commands on 5 entries — each tested from a clean environment. Several installed the project but left it unable to reach Valkey at all; one silently omitted the components entirely, giving no error to search for.
valkey-glide-c.json→valkey-glide-csharp.json— the#was lost in slugification, so the slug read as the language C.
Module requirements are now disclosed, and scoped correctly. Where an entry has two Valkey surfaces and only one needs a module, the qualifier sits mid-sentence next to that surface rather than at the end of the sentence where it would claim both. Two entries were wrong in exactly that way and previously contradicted their own upstream docs, which correctly say plain Valkey is enough.
Question for @jbrinkman — server modules
This branch contains no entries for the Valkey server modules: valkey-search, valkey-json, valkey-bloom, valkey-ldap, valkey-bundle, valkeymodule-rs. They were present in the source data this catalog was built from, and this PR does not add them back — we'd rather ask than assume.
Was that deliberate scoping, or a side effect of the clients + integrations restructure? A server module is neither a client nor an integration, so it may simply have had nowhere to go.
Flagging it because the modules are load-bearing for this very page: during verification, most AI/RAG entries would not function at all on a stock Valkey server — they need valkey-search and/or valkey-json, which is what valkey-bundle provides. Several failed silently, returning 0 or [] rather than erroring.
So the catalog lists integrations that depend on components the catalog itself doesn't mention. Options: add the modules here (a third category, or inside integrations), keep the disclosure in entry descriptions only, cover it in page copy, or point elsewhere if modules are catalogued somewhere better. Happy to follow whichever you prefer.
Two smaller things in the same area, both left for you:
- The guide's tag list has drifted from the data. Three documented tags now have no members —
Proxies & gateways,Data movement,Observability & testing— because this audit removed their only occupants. Two tags in active use are undocumented:ClientsandServer modules, and the guide states that clients do not use tags while all 12 client entries carry one. - Two entries advertise documentation that is broken upstream: one URL 404s, and one project's GitHub homepage field points at a parked for-sale domain. Both are theirs to fix; flagging in case you'd rather report them together.
Verification
manifest.json parses, and its entry list matches the files on disk exactly — 34 = 12 clients + 22 integrations — with no orphaned references in either direction. Every entry file parses. Every description is within the guide's 200-character limit. isFirstParty is present on all 34.
|
One question regarding my previous comment above that supports detail only: The 6 server-module entries aren't on this branch: Most of the AI entries need UPDATE: No, they should not be added |
Applies the outcome of content audit AEA-691 to the entry data on this
branch. Data-only: no template, style, or page-copy changes.
Disqualified (17):
- No first-class Valkey integration to fix (9): celery, kombu, resque,
hangfire, redli, webdis, vllm, openmemory-javascript-sdk,
trino-connector. These work only via RESP compatibility, depend on a
Redis client, and name Valkey nowhere in code, CI, docs or changelog.
- Whole project stale or abandoned (5): tinywebdis, medis, predixy,
php-resque, walrus. Not just the Valkey parts, so no fix could land.
- Audience (2): valkey-test-framework, valkey-perf-benchmark. Both serve
people developing Valkey itself rather than people building on it.
- Licence (1): phpredis. PHP-3.01 is not OSI-approved.
Remediable (4) - removed now, reinstatement documented:
- recall: README install command at line 294 installs nothing
- db-gpt: 3 undeclared runtime deps break `import dbgpt.core`
- langchain-aws: from_texts() raises; wrong exception type caught
- langchain4j-valkey: published pom's unresolvable
${os.detected.classifier} yields a native-less glide jar
These have genuine first-class Valkey integrations on official Valkey
clients and are actively maintained, but the support they advertise is
broken or incomplete as shipped. Each should return once a fix ships in
a released version.
Verification: 19 functional runs against live Valkey in isolated
containers, cross-checked server-side; full-tree source inspection with
`git log -S` history search; every decision ratified by hand against the
raw audit trails.
manifest.json updated to match; 48 -> 27 entries (12 clients, 15
integrations), validated against files on disk in both directions.
Signed-off-by: Jonathan Neufeld <jonathan.neufeld@improving.com>
`Only open-source licenses are accepted` was immediately followed by a clause admitting proprietary and source-available licences case by case, so the first sentence claimed an absoluteness the second withdrew. Reframed as a requirement with a bounded exception, which is the intent: an open-source licence is required, and other licences are considered only by exception where the tool provides significant community value. No change to the substantive policy or to the community-value bar. Found by content audit AEA-691 (recorded as P7). Signed-off-by: Jonathan Neufeld <jonathan.neufeld@improving.com>
Follow-up to the deletion commit on this branch. Two kinds of change: FIELD CORRECTIONS to 11 existing entries, each backed by a functional audit trail: - Sidekiq: description said "for Rails applications" (wrong - upstream says any Ruby app, and this was disproved functionally by running a worker without Rails); repository moved mperham/sidekiq -> sidekiq/sidekiq - Rq: licence was the wrong SPDX id; repository and description corrected - valkey-py features: 110000001 -> 111000101 (two false negatives proven against a live server - pubsub_state_restoration and client_side_caching) - iovalkey features: corrected after direct measurement - huey, Valkey Admin, Cognee, Haystack, PraisonAI: description fixes - Valkey Admin: "desktop app" -> "web interface" (upstream is web-based) - CocoIndex, PraisonAI, Spring Data Valkey: installCommand corrected; Spring Data Valkey had none, and its coordinate is a three-segment vendor namespace (io.valkey.springframework.data) 7 NEW ENTRIES added to integrations, all functionally verified: - LiteLLM, LangBot, Agno, Langflow, LocalAI - requested by @jbrinkman. Four are Tier 1 (exercised against a live Valkey); LocalAI is Tier 3 (first-class valkey-go dependency proven from go.mod, runtime not executed - its Go build failed on an unrelated dependency). - Valkey MCP Server, Valkey Message Queue Starter - operator-attested. Each install command was tested from a clean environment; several were wrong in ways that left users with no Valkey support at all. NOT included, deliberately: the 6 server-module entries (valkey-search, valkey-json, valkey-bloom, valkey-ldap, valkey-bundle, valkeymodule-rs). They are absent from this branch entirely and we could not tell whether that was deliberate scoping in the clients+integrations restructure or a side effect. Flagging rather than re-adding them. 27 + 7 = 34 here; our audit set is 40, and those 6 are the difference. vLLM remains cut. The original basis was wrong (it was audited against vllm-project/vllm), but the correct finding supports the same outcome: the Valkey work lives in vllm-project/semantic-router, a separate Go product with its own release train, so an entry named "vLLM" would point readers at a repository that genuinely has no Valkey support. Signed-off-by: Jonathan Neufeld <jonathan.neufeld@improving.com>
Field edits, each decided on evidence recorded in the audit trail: - huey installCommand -> "pip install huey valkey-glide-sync". huey reaches Valkey two ways: valkey-glide-sync (first class, but undocumented upstream and with real gaps - blocking ops rejected, priorities NotImplementedError) and huey[redis] (documented, and upstream's install doc even names Valkey). Chose the GLIDE route because this entry's description says it is "built on the official Valkey GLIDE client", so a redis-py install line would contradict the copy. - LiteLLM and LocalAI retagged to "Inference & serving". LiteLLM is an LLM API gateway that was filed under Agent frameworks; LocalAI is a self-hosted inference server that was filed under RAG & retrieval. - valkey-glide-c.json renamed to valkey-glide-csharp.json. The '#' was lost in slugification, so the slug read as the language C. Pure rename, content hash unchanged; the manifest was the only reference. Also fixes a mistake of mine from the previous commit (992f368): the 7 entries added there were missing "isFirstParty", which all 27 pre-existing entries carry. All 7 are third-party, so all are set to false, and the field is now present on 34/34 entries. Separately, a key-reordering step in this change had dropped isFirstParty from huey.json; that is restored, and entries are now rewritten preserving their original key order. Not included: valkey-search and valkey-ldap "documentation" URLs were also set (https://valkey.io/topics/search/ and /topics/ldap/, both verified 200), but those two entries are among the 6 server-module entries absent from this branch, so the change has nowhere to land here. valkey-json and valkey-bloom stay unset - their topics pages 404. Signed-off-by: Jonathan Neufeld <jonathan.neufeld@improving.com>
Ruling: no new fields on entry JSON, and an entry that can't be described within the existing schema doesn't ship. LocalAI advertises a Valkey vector backend that is not part of the default image. backend/index.yaml publishes it as a separate OCI artifact resolved through LocalAI's backend gallery, so using it is a two-step operation. Every candidate value for installCommand was checked and none of them delivers the advertised capability: - "docker run localai/localai" installs the product but not the valkey-store backend, so it points users at something that won't work as described - the backend image itself is not a command a user runs; it is pulled by the gallery installCommand can hold one string, so there is nowhere truthful to put "then install the valkey-store backend". Rather than add a field or ship a misleading one-liner, the entry comes out. Every other entry with a null installCommand was re-checked against the same test - does the null hide a requirement, or is there simply nothing to install? All the others are honest nulls: valkey-cli ships with the server, valkey-container is itself an image, valkey-helm and valkey-operator are deployed rather than installed, Valkey Admin is a console you run, valkey-skills has no runtime artifact. LocalAI was the only one concealing a requirement. Valkey Message Queue Starter was reviewed under the same rule and stays: its "pnpm create next-app --example ..." line is long but is a single valid command, which is a different thing from unexpressible. Nothing is wrong with LocalAI itself. Its Valkey support is first class and proven from source (go.mod requires valkey-io/valkey-go), it is MIT and actively maintained. It qualifies again if the backend ever ships in the default image, or if a prerequisites field is introduced later. Integrations 22 -> 21. Signed-off-by: Jonathan Neufeld <jonathan.neufeld@improving.com>
The field was described in one sentence, which left three things unstated that reviewers were having to infer: - it only makes sense next to "documentation": null; a note beside a populated URL explains nothing - a useful note says what was looked for, what exists instead, and when it was checked, in the form "(checked YYYY-MM-DD)". Without a date the note stops being trustworthy once docs sites move - an unverified candidate URL must be named as unverified and must stay out of the documentation field That last point is not hypothetical. One entry's note recorded an unconfirmed <project>.io reference; the domain turned out to be a parked for-sale page with no documentation on it. Saying so in docsNote is what kept it out of documentation, which is exactly what the field is for. Also states plainly that docsNote does not satisfy the documentation expectation in the review checklist - it records a gap honestly so a reviewer can tell a researched null from a skipped one - and that the field is never rendered on the card, so it can be candid. Verified: no template references it. Examples are taken from entries already in the catalog. Signed-off-by: Jonathan Neufeld <jonathan.neufeld@improving.com>
Not part of PR valkey-io#602. This commit lives only on the fork's `preview` branch, on top of fix/ai-libraries-595, and is re-applied after every change there. The workflow builds the pushed commit the way zola-deploy.yml builds valkey.io and deploys it to https://danielfrankcom.github.io/valkey-io.github.io/. adapt-build.py moves the site under that path, removes Google Tag Manager, Osano and the Scarf pixel, and adds a robots noindex tag to every page. Signed-off-by: Daniel Frankcom <frankcom@amazon.com>
Not part of PR valkey-io#602. This commit lives only on the fork's `preview` branch, on top of fix/ai-libraries-595, and is re-applied after every change there. The workflow builds the pushed commit the way zola-deploy.yml builds valkey.io and deploys it to https://danielfrankcom.github.io/valkey-io.github.io/. adapt-build.py moves the site under that path, removes Google Tag Manager, Osano and the Scarf pixel, and adds a robots noindex tag to every page. Signed-off-by: Daniel Frankcom <frankcom@amazon.com>
Not part of PR valkey-io#602. This commit lives only on the fork's `preview` branch, on top of fix/ai-libraries-595, and is re-applied after every change there. The workflow builds the pushed commit the way zola-deploy.yml builds valkey.io and deploys it to https://danielfrankcom.github.io/valkey-io.github.io/. adapt-build.py moves the site under that path, removes Google Tag Manager, Osano and the Scarf pixel, and adds a robots noindex tag to every page. Signed-off-by: Daniel Frankcom <frankcom@amazon.com>
Not part of PR valkey-io#602. This commit lives only on the fork's `preview` branch, on top of fix/ai-libraries-595, and is re-applied after every change there. The workflow builds the pushed commit the way zola-deploy.yml builds valkey.io and deploys it to https://danielfrankcom.github.io/valkey-io.github.io/. adapt-build.py moves the site under that path, removes Google Tag Manager, Osano and the Scarf pixel, and adds a robots noindex tag to every page. Signed-off-by: Daniel Frankcom <frankcom@amazon.com>
Not part of PR valkey-io#602. This commit lives only on the fork's `preview` branch, on top of fix/ai-libraries-595, and is re-applied after every change there. The workflow builds the pushed commit the way zola-deploy.yml builds valkey.io and deploys it to https://danielfrankcom.github.io/valkey-io.github.io/. adapt-build.py moves the site under that path, removes Google Tag Manager, Osano and the Scarf pixel, and adds a robots noindex tag to every page. Signed-off-by: Daniel Frankcom <frankcom@amazon.com>
Signed-off-by: Joe Brinkman <joe.brinkman@improving.com>
Signed-off-by: Daniel Frankcom <frankcom@amazon.com>
Signed-off-by: Daniel Frankcom <frankcom@amazon.com>
Signed-off-by: Daniel Frankcom <frankcom@amazon.com>
Signed-off-by: Daniel Frankcom <frankcom@amazon.com>
Signed-off-by: Daniel Frankcom <frankcom@amazon.com>
Signed-off-by: Daniel Frankcom <frankcom@amazon.com>
Signed-off-by: Daniel Frankcom <frankcom@amazon.com>
Signed-off-by: Daniel Frankcom <frankcom@amazon.com>
Signed-off-by: Daniel Frankcom <frankcom@amazon.com>
|
@stockholmux Could you take a look at this PR again? Substantial iteration has occurred |
Signed-off-by: Daniel Frankcom <frankcom@amazon.com>
jbrinkman
left a comment
jbrinkman
left a comment
There was a problem hiding this comment.
Reviewed the full catalog change (Clients + Integrations data-driven pages). This is clean, well-documented work — careful progressive enhancement, accessibility, whitespace control, and build-time validation that fails on bad entries. I verified the features bit-string split(pat="") | nth(n=idx+1) indexing by reproducing it in Zola (the leading empty string makes idx+1 the correct offset), and CI is green (build + DCO). No blocking concerns — LGTM. A few non-blocking notes below, plus one process item: the PR description still describes the earlier AI-page/build-ai approach rather than the catalog that actually shipped — worth refreshing before merge.
| "persistent_connection_pool" | ||
| ] | ||
| title = "Clients" | ||
| template = "libraries.html" |
There was a problem hiding this comment.
Repointing the clients page to libraries.html orphans the pre-existing templates/client-list.html (not touched by this PR — it still exists at head and nothing renders it now). The old wiring it depended on also goes unused by the clients page: config.toml's client_json_path = "../build-clients/" and the build-clients symlink. Nothing breaks (the init script still creates that symlink for topics/commands), so this is non-blocking — but consider deleting client-list.html and dropping the now-dead client_json_path, here or in a quick follow-up, so there aren't two competing client templates.
There was a problem hiding this comment.
The client-list.html, its helper template, and the client_json_path setting should all be gone now (1d22e5e), so there's only one client template left.
| "repository": "https://github.com/vllm-project/semantic-router", | ||
| "documentation": "https://vllm-sr.ai", | ||
| "isFirstParty": false, | ||
| "installCommand": null, |
There was a problem hiding this comment.
nit: this is the only entry that sets installCommand to null rather than omitting the key. The template handles null fine (the {% if entry.installCommand %} guard renders no copy box), but for consistency with the other no-install entries (valkey-helm, valkey-skills just omit the field) and the submission guide's optional-field convention, consider dropping the installCommand key here.
| {% set_global tcount = tcount + 1 %} | ||
| {% endif %} | ||
| {% endfor %} | ||
| {% if client_count > 0 and tcount * 10 >= client_count * 9 %} |
There was a problem hiding this comment.
The feature-suppression rule here (a feature supported by ≥90% of clients is hidden from every card's feature list AND the legend) is reasonable for surfacing differentiators, but it's undocumented and data-dependent: with 13 clients the cutoff is 12/13, so adding or removing one client can make a feature appear/disappear site-wide with no code change. Worth a sentence in the submission guide so a contributor who sets a bit and then doesn't see it on the card isn't confused — and consider whether a near-universal feature vanishing from the legend (not just the cards) is the intended behavior.
There was a problem hiding this comment.
The rule now only hides features where either every client or no client has the feature (d8e4537). I think this make sense since the features are there as differentiators between cards, so if everything/nothing has a feature it is not a valuable signal. This should resolve the behavior your commented on as there is no changing threshold that could be impacted by one addition.
|
|
||
| // --------------------------------------------------------------------------- | ||
| // Compact header | ||
| // --------------------------------------------------------------------------- |
There was a problem hiding this comment.
nit: the // Compact header banner comment is duplicated — once here above .kind-switch and again above .catalog-header — the first looks like a leftover from before the kind-switch section was added. Separately (not line-specific): this file introduces its own hex palette ($cat-surface: #fff, $cat-fg, …) rather than reusing existing site color variables, and the comments note several equal $background-darker/$text-light. Fine for a light-only site, but it duplicates tokens so a future color change won't reach this file; consider reusing the existing variables where they match exactly.
There was a problem hiding this comment.
The header has been removed when the pages were split. I also reused existing color palettes where they lined up, though there were some colors that didn't so those have been left.
Signed-off-by: Daniel Frankcom <frankcom@amazon.com>
Signed-off-by: Daniel Frankcom <frankcom@amazon.com>
Signed-off-by: Daniel Frankcom <frankcom@amazon.com>
Signed-off-by: Daniel Frankcom <frankcom@amazon.com>
Signed-off-by: Daniel Frankcom <frankcom@amazon.com>
Signed-off-by: Daniel Frankcom <frankcom@amazon.com>
Signed-off-by: Daniel Frankcom <frankcom@amazon.com>
Signed-off-by: Daniel Frankcom <frankcom@amazon.com>
Signed-off-by: Daniel Frankcom <frankcom@amazon.com>
Signed-off-by: Daniel Frankcom <frankcom@amazon.com>
This branch has not been deployed
8 participants
Add AI Libraries page to website
Description
This PR implements a comprehensive AI Libraries page on valkey.io to showcase AI/ML frameworks and libraries that support Valkey for caching, vector storage, and memory management. The page mirrors the existing Client Libraries page structure and displays 14 AI libraries organized by programming language.
Related Issue
Fixes #595
Dependencies
The valkey-doc PR must be merged first as it adds the new
valkey_usesfield and improved descriptions to the AI library JSON files that this website template consumes.Changes
Build System
build-aisymlinkai_json_path = "../build-ai/"configuration../valkey-doc/aiparameterbuild-aito ignore generated symlinksContent & Templates
recommended_ai_pathsai_json_path()helper macroDocumentation
New Page Structure
The AI Libraries page displays for each library:
Libraries are organized by language:
Example Output
Testing
Local Testing Results
Screenshots
(Add screenshots of the rendered AI Libraries page after pushing)
Checklist
Analytics Support
The page includes the standard Google Tag Manager (GTM) integration (
GTM-MFFCB7SR) that allows the Valkey team to:GTM administrators can configure link tracking to see click-through rates to individual library repositories.
Notes for Reviewers
Template Design: The
ai-list.htmltemplate is intentionally simplified compared toclient-list.html- it doesn't include a feature comparison table since AI libraries have different integration patterns (vector store vs caching vs memory management)Field Ordering: The Description and Valkey Uses fields appear between Repo and Installation to provide immediate context about what the library does and how it uses Valkey before showing installation instructions
Whitespace Control: Template uses
{%-and-%}for whitespace control to prevent excessive blank lines in the generated HTMLBuild Process: The init script creates a symlink (
build-ai -> ../valkey-doc/ai) so the website can access the JSON files from the valkey-doc repositoryFuture Enhancements
Potential improvements for future PRs:
Page URL after merge: https://valkey.io/ai/