tools/bazel.rc uses removed option --experimental_local_disk_cache

[dslomov]

This fails on Bazel CI: https://buildkite.com/bazel/bazel-with-downstream-projects-bazel/builds/232#1cd8b9e4-c91f-4152-9c39-53b6e8a8032b

[dslomov]

@aehlig could you take a look, please? Thanks!

[buchgr]

It's a simple rename. We graduated them from experimental. The two flags have been merged into one and the one flag is now called --disk_cache.

[ittaiz]

@buchgr is it supported in 0.11.1?

[buchgr]

No it's not. It will be supported starting with 0.14.0. Does rules_scala require 0.11.1?

[ittaiz]

No but we're trying to support as far back as we can.
@johnynek following our discussion about supporting bazel's latest features we need to create a branch saying 0.11.1 from master and then update master to support the new flag. Any objections?

[promiseofcake]

In this case would the 0.11.1 branch continue to receive upstream patches from master, or would it be a point-in-time release to support 0.11.1?

[ittaiz]

We actually had a (side) discussion about this [here] (#430 (comment)) where @johnynek said we'll try to send patches but this is more on a good will basis. Honestly I think it won't be easy.
Our thoughts are mainly that Bazel is still evolving very fast and supporting older versions have big costs.
What do you think?

[promiseofcake]

@ittaiz, I agree. I also think that due to:

• Bazel is evolving quickly
• There is no way to pin a rules_scala dependency to a floating master

it is in everyones best interest to not get too comfortable being pinned to a specific Bazel release. So for me even a tag and then breaking changes moving forward would be fine.

Internally we got stuck and comfortable on an old Bazel release that ended up being a large effort to move off of, so I am all for remaining agile now and trying to move with the releases until Bazel reaches a "stable" milestone.

[dslomov]

What is the right action here? Should I send a PR to rename this to --disk_cache?
(note that tool/bazelrc only affects rules_scala on CI, really)

[johnynek]

I think the right action is to make sure we keep the travis CI green and the buildkite. There are many tests we don’t have expressed as bazel tests (e.g. reproducibility tests)

[dslomov]

@buchgr suggested we remove tools/bazel.rc from rules_scala completely. It only affects rules_scala developers and messes up with CI.

[buchgr]

@johnynek is the intention for the disk cache to be used on Travis?

@dslomov #502

[dslomov]

@buchgr thanks for pointing me to #502 - I think it is useful to reference the bug the PR fixes from its description.

[ittaiz]

Sorry for not picking it up before. I’ll do it before Monday (hopefully tonight)

…

On Thu, 17 May 2018 at 12:11 Dmitry Lomov ***@***.***> wrote: @buchgr <https://github.com/buchgr> thanks for pointing me to #502 <#502> - I think it is useful to reference the bug the PR fixes from its description. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#498 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUIF7E--CjZY4JR_nA0tBWGzdgOCpNmks5tzT7AgaJpZM4T9llx> .

[katre]

This failed again in the latest nightly. Are we not using the latest version?
Logs: https://buildkite.com/bazel/bazel-with-downstream-projects-bazel/builds/243#6b56bca4-57aa-4912-88d0-f886b9003ade

[ittaiz]

That's one option but from this log it seems we are:

Fetching rules_scala sources | 20s
-- | --
  |  
  |  
  | git clone --recurse-submodules --reference /var/lib/bazelbuild https://github.com/bazelbuild/rules_scala.git /var/lib/buildkite-agent/builds/buildkite-worker-ubuntu1404-java8-9d00-1/bazel-downstream-projects/rules_scala
  | Cloning into '/var/lib/buildkite-agent/builds/buildkite-worker-ubuntu1404-java8-9d00-1/bazel-downstream-projects/rules_scala'...

I think @buchgr might be able to help since I suspect it's something with the presubmit file.
#495 as well as #504 should have both fixed this but didn't.
@buchgr can you please assist?