Attributes & Semantic Roles

Every rule call in a BUILD file takes a set of named arguments — these are the rule's attributes¹. The name attribute identifies the target; beyond that, the most important beginner distinction is between build-time inputs, target dependencies, runtime files, and execution-time arguments.

java_binary(
    name = "server",
    srcs = ["Main.java"],
    deps = [":lib"],
    data = ["config.yaml"],
    args = ["--port", "8080"],
)

Three generic dependency roles appear across most rule families: srcs, deps, and data². Executable rules often add args as a separate execution-time attribute³. They look like simple lists, but each one tells Bazel something different about how the value is consumed.

srcs — Compile-Time Inputs

Files consumed directly by the rule's build action². For a java_library, these are the .java files that the compiler reads. For a genrule, they are the input files that the generation command processes.

java_library(
    name = "lib",
    srcs = ["Lib.java"],
)

srcs typically contains source files owned by the same package — the app/BUILD.bazel in the target-patterns snippet shows this pattern. If the rule needs files from another package, those files must be explicitly shared (via 0.2.7 exports_files() or a rule target in the other package).

deps — Library Dependencies

References to other targets that provide compiled code, headers, or modules^2,3. Where srcs points at raw files, deps points at other targets — the output of another rule becomes an input to this one.

java_binary(
    name = "server",
    srcs = ["Main.java"],
    deps = [":lib"],
)

The distinction matters for dependency tracking. When a file in srcs changes, Bazel knows this target's own build inputs changed. When a target in deps changes, Bazel knows the dependency graph downstream may need rebuilding.

deps must list direct dependencies only — the targets this code actually imports or links against⁴. Relying on transitive dependencies (a target your dep happens to pull in) creates fragile builds that break when someone refactors an intermediate library⁴.

data — Runtime Files

Files needed when the binary or test runs, not when it compiles^2,5. Configuration files, test fixtures, certificates, lookup tables — anything the program opens or reads at execution time.

sh_test(
    name = "regtest",
    srcs = ["regtest.sh"],
    data = [
        "//data:file1.txt",
        "//data:file2.txt",
    ],
)

Bazel sandboxes test execution: only files listed in data (or transitively via dependencies) are available in the test's working directory^2,5. A test that reads a file not declared in data may appear to work in an ad hoc local run, but it will fail once Bazel enforces the runfiles boundary in a sandboxed or remote environment.

Files from data are collected into a runfiles tree — a directory next to the binary that makes runtime files available at predictable paths^5,6. The details of how bazel run assembles and uses the runfiles tree are covered in 1.1.2 bazel run & Runfiles.

args — Execution-Time Arguments

Many executable rules expose an args attribute for values passed on the command line when the program or test starts³. Unlike srcs, deps, and data, args does not declare another build dependency edge — it provides string values for execution.

java_test(
    name = "integration_test",
    srcs = ["IntegrationTest.java"],
    args = ["--env", "staging"],
)

Many rules also have additional attributes specific to their purpose — main_class for java_binary, copts for cc_library, stamp for binaries. args is a common part of the execution interface for binaries and tests, while srcs, deps, and data are the more general roles you will see across rule families^2,3.

Roles Are Not Interchangeable

Each attribute triggers different behavior in Bazel's build and execution pipeline. Confusing them causes subtle problems:

• Runtime file in srcs instead of data — Bazel now treats that file as a build-time input instead of runtime state. That can invalidate build actions when the file changes, and it does not communicate the program's runtime needs clearly.
• Missing from deps — the build may succeed if a transitive dependency happens to provide the symbol, but a future refactor of that intermediate target will break the build unexpectedly⁴.
• Missing from data — the test passes locally but fails under sandboxing or on CI, because the file is not in the runfiles tree⁵.