First you need to run echo "test" > /tmp/foo
.
Running bazel build @repo//...
will print "running repo rule".
Touching test_file
and then bazel build @repo//...
will not do anything; the repo rule is not rerun and the artifacts in @repo
are not rebuilt.
Modifying test_file
will cause the workspace rule to be rerun.
- if you make a change that yields a different BUILD.bazel file then artifacts will be rebuilt (i.e. changing the first line of
test_file
) - if you make a change that still yields the same BUILD.bazel file no actions will be run (i.e adding extra lines, whitespace to
test_file
)
Modifying this file (test.bzl) will cause the workspace rule to be re-run; same caveat around actions being re-run (only if the actions are different -- i.e. if the BUILD files are different).
Modifying /tmp/foo
will not cause the workspace rule to be re-run; it is not tracked by bazel.
This is all consistent with these docs:
repositories are re-fetched only if one of the following things changes:
- The parameters passed to the declaration of the repository in the
WORKSPACE
file.- The Starlark code comprising the implementation of the repository.
- The value of any environment variable declared with the
environ
attribute of therepository_rule
. The values of these environment variables can be hard-wired on the command line with the--action_env
flag (but this flag will invalidate every action of the build).
- note: there's also
--repo_env
- The content of any file passed to the
read()
,execute()
and similar methods ofrepository_ctx
which is referred to by a label (for example,//mypkg:label.txt
but notmypkg/label.txt
)- When
bazel sync
is executed.
Notes from another experiment: