A way to see warnings from cached builds

[tha...@lucidchart.com]

I would like to see warnings from cached builds, so that I can later go back and remove them. In particular I may have a project that currently has too many warnings to treat warnings as errors, but later I want to go back to fix all the warnings, so I can enable fatal warnings for a rule.

I see two ways this could be achieved:

1. Persist the standard error and possibly standard output from build commands, I think this is the ideal.
2. Have a mechanism to force a rebuild of a target for the purposes of getting the stderr/stdout output again

As far as I know bazel doesn't have a mechanism to do either of these.

[o...@wix.com]

+1 on that

Last answer I got regarding this was here:

https://stackoverflow.com/questions/44872490/see-compilation-warnings-on-cached-bazel-targets

[George Gensure]

What is the level of caching that you are referring to? Buildfarm remote caching, at least, retains stdout and stderr for bazel as a client to print out on action cache hit.

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/f5c34082-e4d3-40f0-9203-2dbd634249b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[tha...@lucidchart.com]

It's especially a problem with local caching, since CI services will probably keep stderr/stdout.

Although, since bazel doesn't currently have a solution for using local caching with remote caching as a fallback, we actually use remote caching, but pointing to a local nginx server that first looks on disk, and then falls back to an actual remote cache.

[Jakob Buchgraber]

On Thu, Sep 13, 2018 at 9:06 PM <tha...@lucidchart.com> wrote:

Although, since bazel doesn't currently have a solution for using local caching with remote caching as a fallback, we actually use remote caching, but pointing to a local nginx server that first looks on disk, and then falls back to an actual remote cache.

I would be very interested in why it's necessary for you to use local + remote caching.

[Jakob Buchgraber]

On Thu, Sep 13, 2018 at 9:06 PM <tha...@lucidchart.com> wrote:

It's especially a problem with local caching, since CI services will probably keep stderr/stdout.

You mean --disk_cache? This should also retain stdout/stderr.

[tha...@lucidchart.com]

Really? How would one access that?

[Jakob Buchgraber]

On Thu, Sep 13, 2018 at 9:42 PM <tha...@lucidchart.com> wrote:

Really? How would one access that?

Yep. It depends on what you mean by access this? It's stored in a protobuf

file in the disk cache directory for each action. If you use Bazel it will be

displayed in Bazel's UI.