bazelbuild/bazel

Surface diagnostics for non-reproducible repo rules

Open

#28499 opened on Feb 2, 2026

View on GitHub
 (2 comments) (0 reactions) (0 assignees)Java (25,384 stars) (4,465 forks)batch import
P2help wantedteam-ExternalDepstype: feature request

Description

Description of the feature request:

It's very helpful for a repo rule to mark itself as reproducible = True (assuming it is!) as that allows it to participate in both the local and remote repo contents cache. However, it's very easy for rule authors to forget to do that.

It would be nice to surface repository rules that forget to explicitly set the reproducible bit (i.e. encourage setting either reproducible = True or reproducible = False explicitly).

Some idea we discussed in https://bazelbuild.slack.com/archives/CA31HN1T3/p1769937819949869

  • Always warn if not set
  • Provide a bazel flag such as --extensions_of_unknown_reproducibility=error|warn|ignore so users can control the behavior and apply patches/send PRs to rulesets to improve the ecosystem

@fmeum

Which category does this issue belong to?

No response

What underlying problem are you trying to solve with this feature?

No response

Which operating system are you running Bazel on?

No response

What is the output of bazel info release?

No response

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

Contributor guide

Tech stack
java
Domain
build systemtoolingdeveloper experience
Issue type
feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-2 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
fresh
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
mostly clear
Prerequisites
understanding of Bazel's repository rulesfamiliarity with Bazel's flag system
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
40
Research direction
Review the Slack discussion linked in the issue for context. Investigate how existing Bazel flags like incompatible * are implemented, particularly around repository rules. Look at the Starlark rule definition and the Java code that handles the reproducible attribute. The goal is to add a new flag (e.g., extensions of unknown reproducibility) that can warn or error when a repository rule does not explicitly set reproducible. Consider adding the diagnostic in the repository rule loading phase.