feat: add example with go proto codegen

[alexeagle]

This is a primary motivating use case for this ruleset.

Use case: developer changes foo.proto to remove a field. They either

1. don't update the foo.pb.go file in the source tree
2. they do update it but incorrectly (commonly an AI agent might do this)

Their editor doesn't show an issue in the Go code that uses the proto, but their Bazel tests will fail. Because we have flag //diff:validate_diffs set in .bazelrc, attempting to execute a test which depends on the protobuf file won't even build:

diff.bzl % bazel test examples:foo_usage_test
INFO: Analyzed target //examples:foo_usage_test (168 packages loaded, 12749 targets configured).
ERROR: /Users/alexeagle/Projects/diff.bzl/examples/BUILD:23:5: Action examples/bazel-out/darwin_arm64-fastbuild/bin/examples/go_codegen_diff.exit_code.valid failed: (Exit 1): bash failed: error executing Action command (from diff_rule rule target //examples:go_codegen_diff) /bin/bash -c ... (remaining 1 argument skipped)

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
        ERROR: diff command exited with non-zero status.

        To accept the diff, run:
        patch -d $(bazel info workspace) -p0 < $(bazel info bazel-bin)/examples/go_codegen_diff.patch

Target //examples:foo_usage_test failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 0.952s, Critical Path: 0.04s
INFO: 2 processes: 518 action cache hit, 2 internal.
ERROR: Build did NOT complete successfully
//examples:foo_usage_test                                       FAILED TO BUILD

If you now simply run the command printed, it works:

alexeagle@aspect-build diff.bzl % patch -d $(bazel info workspace) -p0 < $(bazel info bazel-bin)/examples/go_codegen_diff.patch
patching file 'examples/foo.pb.go'
alexeagle@aspect-build diff.bzl % bazel test examples:foo_usage_test                                                           
INFO: Analyzed target //examples:foo_usage_test (0 packages loaded, 0 targets configured).
INFO: Found 1 test target...
Target //examples:foo_usage_test up-to-date:
  bazel-bin/examples/foo_usage_test_/foo_usage_test
INFO: Elapsed time: 0.222s, Critical Path: 0.05s
INFO: 5 processes: 2 internal, 3 darwin-sandbox.
INFO: Build completed successfully, 5 total actions
//examples:foo_usage_test                                                PASSED in 0.0s

[thesayyn]

This will work perfectly with AXL, we already have retry and process bes events logic over there, looking at test.sh, it looks like almost the same layering logic as rules_lint.

[kormide]

(for my understanding) what case does this fix?

[alexeagle]

I believe it's when your current working directory is not the repository root.
perhaps it should be $(bazel info workspace) still, since there are multiple bin dirs under transitions

[kormide]

I hope this can't push to main ⚠️ . Is it necessary in addition to pull-requests: write?

[alexeagle]

I think so, because it needs to create a branch to hold the commits

[kormide]

I'm really hesitant about including this. There are going to be lots of test cases in this repo that produce patches but we don't necessarily want the build to fail and a patch to be auto applied.

I'm also concerned about the security implications of contents: write and I don't fully understand what capabilities it would give to someone submitting a PR from their fork. Do you know?

[kormide]

I think this might be best kept as a documented example of how you can use the diff output groups for automatic patching and not part of ci.

[kormide]

Will this capture and patch all diffs, even if we set validate = False because we didn't want the build to fail? Not every patch represents a build error, and some generated patches may be wrong (think a snapshot test that changed unexpectedly). Is there way we can separate diffs that we want to be automatically patched versus those we don't?