Bump GLQL packages and document multi-group/project scope
Goal
Ship multi-group and multi-project scope (group in (...) / project in (...) in analytics mode) to GitLab: bump the compiler packages to the release that contains both compiler MRs, and document the feature in the same MR. Part of &23512.
Bump
- Bump
gitlab_query_language(Gemfile) and@gitlab/query-language-rust(package.json) to the release cut after glql!497 (merged) and glql!498 (merged) have both merged. They must land in the same release: on the compile MR alone anorganization-rooted response fails at transform. - Nothing else is needed on the GitLab side: the feature is query syntax, so every consumer (markdown, wikis, dashboard panel YAML,
/api/v4/glqland the Data Analyst Agent) gets it with the bump. Both/api/glqland/api/v4/glqlexecute the compiled GraphQL as is and already set the current organization.
Docs (doc/user/glql/)
groupandprojectaccept a list in analytics mode:group in ("gitlab-org", "gitlab-com"),project in ("a/x", "b/y"), andgroup = "a" and project in ("a/x", "a/y")(projects under one group). Groups and projects listed together are a union.- Requires GitLab 19.3 or later. Pattern to follow: the pipelines analytics page states its 19.2 minimum.
- Limits: at most 20 groups and projects combined; paths are deduplicated case-insensitively; a list of one path behaves like
=. - Standard mode (issues, merge requests, ...) keeps taking a single
grouporproject; a list there is a compile error. - Access: every listed group or project is checked individually; one you cannot read fails the whole query with
The following sources are not accessible: <paths>. - Per-source pages: each analytics source page's "Allowed scopes" section gains the list forms (all analytics sources support them).
Source of truth for the rules: glql#151 (closed) and the MR descriptions; backend contract in #600674 (closed).
Not here
Wiring the dashboard group/project filters into group in (...) is control wiring, tracked under &22615 / glql#154.
Edited by 🤖 GitLab Bot 🤖