1# leaf
2
3>The code comments in this package are intended to be the most up-to-date detailed implementation documentation. This README only provides a high-level summary of this tool's behavior and how to use it.
4
5Builds only a leaf instead of the whole Bazel plant, based on your branch.
6A Go binary that drives our Bazel-based CI.
7
8## Usage
9
10For complete usage information, run `bazel run hack/build/ci/leaf -- --help`.
11
12A `just` wrapper is provided for convenience: `just ci`.
13
14## Behavior
15
16For the provided Git commit range:
17
180. Retrieves all changed files using `git diff` (`ci.getDiffFiles`)
190. Queries Bazel for each file in the diff.
20 - If the Go dependency file has changed (`tools/deps/go.bzl`),
21 that file's diff is parsed to determine which Go modules have changed.
22 These Go modules are then added to the queries used to determine impacted
23 test and build targets.
240. Queries Bazel for all targets which depend on the result of the file queries
25 performed in the previous step.
26
27OR
28
29For the provided list of files:
30
310. Queries Bazel for all targets which depend on the set of provided files
32
33>Note: Committing the changed files and pushing them to a Git remote is out of scope for this tool and should be handled with a CI script or otherwise.
34
35## Future Improvements
36
37- Provide a mechanism for components to declare their own name, so that it is not tied to the image name. This will be necessary when components begin to have more than one image. There are two possible ways to implement this that I am aware of:
38 - A `.component` file in the root of the component. When `container_push` targets are identified, the CI tool can walk directories upwards until it finds one. If one isn't found, the image isn't related to a component and can be left out of the remainder of the build steps.
39 - Use Bazel tags to identify component names on each `container_push` target.View as plain text