Remove //third_party/gflags

[aiuto]

It is unused.
See https://github.com/bazelbuild/bazel/pull/11201I

[meteorcloudy]

This change is breaking downstream projects that depend on rules_docker.

https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1527

I think the problematic dependency comes from:
https://github.com/bazelbuild/rules_docker/blob/f7e6d6f28ac9f9e92d8b875426233031c5c5257c/container/BUILD#L46

[aiuto]

Someone will have to update docker before the next major Bazel release.
I'll take a look at it, but maybe they will notice and fix first.

bazelbuild/rules_docker#1533

[meteorcloudy]

@aiuto Thanks! But until the issue is fixed in rules_docker and all downstream projects migrate to the new rules_docker version, our downstream will stay red. Do you think it makes sense to rollback this change first and roll-forward after the migration?

[aiuto]

We should let downstream projects stay red and potentially block new bazel releases on that.

[meteorcloudy]

That will shadow other potential breakages that could have been caught by CI.

[aiuto]

I think that if people want to stay on Bazel at head, they have to be prepared for breakages. This is the kind of change that no amount of incompatible flags will smooth the transition. You either have to update everything or you do not. Better to pull of the bandaid at head, where there is no promise than defer this forever. FWIW: rules_docker fixed this quickly, bazelbuild/rules_docker#1533

…

On Mon, Jun 15, 2020 at 10:45 AM Yun Peng ***@***.***> wrote: That will shadow other potential breakages that could have been caught by CI. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#11564 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXHHHABRRZWNPL2NO4UY5DRWYXYBANCNFSM4NYSIIVQ> .

[meteorcloudy]

Cool! As long as people fixing the issue fast, I'm OK with it. I'm just afraid keeping the CI red will cause it hard to debug the causes of failures later.