[FR]: 'fixup' command

[alexeagle]

What is the current behavior?

Tools like compilers, formatters, linters, gazelle/buildifier, or "golden file tests" often propose a suggested fix. Currently developers have to find the message and do what it says. It can be hard because:

• the CI system is slow to report it
• there is no "just run this command to apply fix"
• the CI system makes it hard to find that command
• you have to reproduce the same failure locally first in order to get the matching fix offered, and for big tests that's just slow.

Describe the feature

bazel fixup as a new command, which is named after git commit --fixup HEAD

MVP (minimal viable product) should hook into Aspect Workflows and one particular tool, probably https://docs.aspect.build/rules/aspect_bazel_lib/docs/write_source_files/.

User story is:

"As a developer with a red PR, I see the CI system has proposed a mechanical fix for my write_source_files rule. I run bazel fixup. It queries remotely (with some assumptions about local username matching) to find the patch content on CI and fetch it. Assuming my git checkout is clean, it adds a fixup commit with the patch and re-pushes. My PR then turns green"

[qzmfranklin]

Help me understand this better.

I thought the mechanical fix should be either:

1. Direct result of running a command, e.g., clang-format, rustfmt, bazel build with a repin flag, etc.. In this case, no other actions are needed. The files are modified in-source.
2. Calling bazel build to build a new version of the golden file, and copy it from bazel-bin back to the source tree, and then chmod 644 on the copied file.

Per this understanding, I don't quite get why bazel fixup needs to query remotely. Also, what patch content needs to be fetched?

Thanks for helping me understand.

[qzmfranklin]

I see a different scenario:

gazelle with update-repos command could lead to merge conflicts in the .bzl file it writes to. In this case, the fix is rather tedious:

1. checkout branch A, and query branch B on what go packages it updated, perform the go get and gazelle update-repos on the same branch, and push to A.

If so, there has to be some contract between the remote (eg CI) and the bazel fixup command?

[alexeagle]

This proposal is largely thinking about the use case where you have a red status on CI and a message there that says "apply this patch to your sources". It's slow to re-run the tool that produced the patch. You really want CI to just supply the patch file itself as an artifact and be able to run patch on it automatically.