Support running without command file about bazel-tools HOT 5 CLOSED

I don't see how being able to pass commands via command line changes anything? It will still not be possible to specify labels like //.../vendor/...:%go_test.

from bazel-tools.

Why cannot you put all your delete //services/myservice/vendor/...:%go_test commands into a file?

from bazel-tools.

@ash2k Doing so would require us to continually keep our commands file updated with all the paths we wanted buildozer to manage. That's a lot of paths owned by a lot of teams so I think that pattern would break down pretty fast.

You're correct that the wildcard //.../vendor/...:%go_test still won't work when passed as an argument to buildozer directly, but supporting arguments in addition to the commands file would allow us to keep our current pattern, but using bazel run rather than an external buildozer binary.

i.e. Today our documentation instructs engineers to run the following to update their BUILD files for whatever path of the monorepo they're working on:

$ bazel run //:gazelle -- fix services/myservice
$ buildozer delete //services/myservice/vendor/...:%go_test

I'd like to be able to simply change that documentation to be:

$ bazel run //:gazelle -- fix services/myservice
$ bazel run //:buildozer -- delete //services/myservice/vendor/...:%go_test

I feel that this is a more sustainable/maintainable pattern than having a large group of people maintain a buildozer commands file and run buildozer against the entire monorepo regularly.

from bazel-tools.

Ok, I understand your use case now, thank you. Feel free to submit a PR (don't forget to sign the CLA).
However, if I were you, I'd instead do these two things:

• Open an issue (or a PR) with buildozer to add support for label wildcards like what you need //.../vendor/...:%go_test
• Instead of recommending engineers to run buildozer delete //services/myservice/vendor/...:%go_test add a bazel target that generates the commands file with directories that you want fixed. Use something like find . -type d -name vendor in the script. And then have the buildozer rule depend on that generated commands file. That way your engineers would not need to maintain that pattern per service and only run bazel run //:buildozer to fix all vendor folders. This may require some experimentation with glob() to declare dependencies of that generator rule... I'm not 100% it will work nicely, but worth a try.

from bazel-tools.

I think this was implemented in #107.

from bazel-tools.