Skip to content

bug: index bcr_staging modules in the registry frontend - #9

Merged
asymingt merged 1 commit into
mainfrom
asymingt/make-sure-bcr-staging-modules-are-indexed
Oct 30, 2026
Merged

asymingt merged 1 commit into
mainfrom
asymingt/make-sure-bcr-staging-modules-are-indexed

Conversation

@asymingt

Copy link
Copy Markdown
Contributor

Modules under bcr_staging/modules in ros-central-registry are published into the same registry as modules/ (see the "Assemble site" workflow step), but the frontend index never included them:

  • The gazelle extension built the module_registry rule from the subdirs of /modules only, so bcr_staging modules were walked but never linked into the registry's deps.
  • The submodule was sparse-checked-out to modules alone, so bcr_staging/ was not even on disk when bazel run //:bcr ran in CI.

Fix both:

  • Add a repeatable --extra-modules-dir flag to //language/bcr. The module_registry rule now merges module names from every extra dir (deduped; the primary modules/ copy wins on conflict). The bulk git log commit preload and overlay lookup use the real on-disk location instead of a hardcoded modules/ prefix.
  • Pass --extra-modules-dir=bcr_staging/modules in //:bcr and include bcr_staging/modules in the Makefile / .gitmodules sparse-checkout.

Also add ModuleVersion.registry_path (the version's directory relative to the registry repo root, e.g. "bcr_staging/modules/imgui/1.0"), populated by the gazelle extension via a new module_version attr and moduleversioncompiler flag. The UI uses it for overlay/patch "view on GitHub" links and raw-file fetches, which previously assumed modules// and would 404 for staging modules.

Fixes: #8

Modules under bcr_staging/modules in ros-central-registry are published
into the same registry as modules/ (see the "Assemble site" workflow
step), but the frontend index never included them:

- The gazelle extension built the module_registry rule from the subdirs
  of <registry-root>/modules only, so bcr_staging modules were walked
  but never linked into the registry's deps.
- The submodule was sparse-checked-out to `modules` alone, so
  bcr_staging/ was not even on disk when `bazel run //:bcr` ran in CI.

Fix both:

- Add a repeatable --extra-modules-dir flag to //language/bcr. The
  module_registry rule now merges module names from every extra dir
  (deduped; the primary modules/ copy wins on conflict). The bulk
  `git log` commit preload and overlay lookup use the real on-disk
  location instead of a hardcoded modules/ prefix.
- Pass --extra-modules-dir=bcr_staging/modules in //:bcr and include
  bcr_staging/modules in the Makefile / .gitmodules sparse-checkout.

Also add ModuleVersion.registry_path (the version's directory relative
to the registry repo root, e.g. "bcr_staging/modules/imgui/1.0"),
populated by the gazelle extension via a new module_version attr and
moduleversioncompiler flag. The UI uses it for overlay/patch "view on
GitHub" links and raw-file fetches, which previously assumed
modules/<name>/<version> and would 404 for staging modules.

Signed-off-by: Andrew Symington <simmers@google.com>
@asymingt
asymingt force-pushed the asymingt/make-sure-bcr-staging-modules-are-indexed branch from 6dbbdd5 to 38191e8 Compare October 30, 2026 19:58
@asymingt asymingt changed the title Index bcr_staging modules in the registry frontend bug: index bcr_staging modules in the registry frontend Oct 30, 2026
@asymingt
asymingt merged commit 426ebdc into main Oct 30, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

The bcr_staging modules aren't included in the index

1 participant