Add range matchers for site matrix vector store filtering

[bep]

Fixes #14359

[gemini-code-assist]

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

[bep]

@jmooring If you could have a look/test this one and see if you agree.

I have updated your demo in this branch bep/hugo-testing@f5f30ee

Note that without end ranges, the mount order is important (higher up is weightier, also see my fix in #14405).

[Copilot]

Pull request overview

This PR adds range matcher support for site matrix vector store filtering, allowing users to filter versions, languages, and roles using comparison operators (>=, <=, >, <) in addition to the existing glob patterns. This enables more precise control over which versions should include specific content.

Changes:

• Added range operator parsing and predicate logic to support version/language/role filtering with comparison operators
• Modified interface signatures across the codebase to use IndexString instead of raw strings for predicates
• Changed ResolveIndex methods from panicking to returning -1 for not-found cases
• Added comprehensive test coverage for range matchers with various combinations

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
common/predicate/predicate.go	Adds IndexString type, cutRangeOp function, and NewIndexStringPredicateFromGlobsAndRanges function to support range-based filtering
common/predicate/rangeop_test.go	Unit tests for cutRangeOp function
common/predicate/predicate_test.go	Comprehensive integration tests for range matchers with various patterns
langs/config.go	Updates IndexMatch signature and ResolveIndex to return -1 instead of panicking
hugolib/versions/versions.go	Updates IndexMatch signature and ResolveIndex to return -1 instead of panicking
hugolib/roles/roles.go	Updates IndexMatch signature and ResolveIndex to return -1 instead of panicking
hugolib/sitesmatrix/vectorstores.go	Updates filter creation to use new range-aware predicate function and simplifies iteration logic
hugolib/sitesmatrix/sitematrix_integration_test.go	Adds integration test demonstrating range matcher functionality with real Hugo site builds

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jmooring]

@jmooring If you could have a look/test this one and see if you agree.

Just seeing this now. I'll take it for a spin later today.

[jmooring]

I worked with the example site from https://discourse.gohugo.io/t/is-there-an-example-of-how-to-use-the-new-multidimensional-content-model/56516/4.

1. If I understand the changes in your branch, for a site to "back fill" for from earlier versions, we always need mount the most recent first, then the next most recent, etc. And you cannot deviate from this mount order. Please verify. I'm fine with the way it's working.

2. As a follow-up to the question above, is the mount order important for "back filling" translations as well? I have not yet tried to create a multi-version multilingual site, so I'm not quite sure what that would look like yet.

3. In the example site, we removed the "average" function in v0.3.0 and later. In your branch you handled that in v0.1.0, specifying versions: < v0.3.0. Instead of modifying the earlier version that I really don't want to touch, I set versions: < v0.3.0 in the v0.3.0 version of average.md and that worked great. Same effect, just different editing/authoring process.

4. I did something stupid that took me way to long to find: versions: < = v0.2.0. Notice the space between < and =. Can we validate the range operators to prevent dumb mistakes, and to flag things like versions: <= foo bar v0.2.0.

5. Finally, in your branch you ordered the versions from latest to earliest:

   [versions]
     [versions.'v0.4.0']
     [versions.'v0.3.0']
     [versions.'v0.2.0']
     [versions.'v0.1.0']

   I assume you did that for symmetrical presentation with the mounts, not because we need to. I tested with this and it worked fine:

   [versions]
     [versions.'v0.1.0']
     [versions.'v0.2.0']
     [versions.'v0.3.0']
     [versions.'v0.4.0']

In the future we might consider == and != operators as well. Yes, there's alternate syntax for doing those things, but when I wanted to add something only for v0.3.0 (e.g., an announcement) the == syntax was the first thing that came to mind.

[bep]

1. I think there are several ways to do this, but this was the obvious setup for me in your example. To recap: When a content path, e.g. docs/functions/mean, has multiple variants for the same version (is e.g. mounted twice for v2.0.0), we need a way to pick one of them for a given version. Simplified, front matter takes precedence, then file mounts from top down. The file mount merge logic is logically largely the same as < v0.153.0; the setup in your demo mimics how we did "language backfills" back in the days. So, if you don't want to rely on file mount order, you need to either be more specific in the sites.matrix.versions (add an end range?) or add some front matter/cascade filters. Not sure.
2. Yes; versions and roles all work the same, but should be easier to reason about. What I suspect the end user will get wrong is that the range queries matches the indices in the languages slice and not the strings, but that wouldn't be useful; now I can apply some content to Scandinavian languages by doing languages = ["<= no", ">= dk"] or something.
3. You're right, that's logically the same, and obviously a better way to do it practically.
4. I'll add some validation, see below.
5. I just reordered. these to match the default versions sort order (if weight is not set), but that has no effect for the end result, just cosmetic.

Thanks for this thorough rundown, much appreciated.

• Can we validate the range operators to prevent dumb mistakes, and to flag things like versions: <= foo bar v0.2.0 <- but note that "< = v0.2.0" is a valid (but odd) Glob pattern, so the validation logic isn't obvious.

[jmooring]

LGTM