When credentials in netrc file are changed, bazel still uses the old ones.

[cattibrie]

Hey, I have an issue related to netrc file. When credentials in netrc file are changed, bazel still uses the old ones. Version of bezel 2.2.0.

Initial situation When building a file I got a 401 status code for some maven packages. Updated credentials in netrc files, but continued to get 401 status code.

A generated version of netrc file is created by bazel, e.g. /private/var/tmp/_bazel_etyurina//70547e7733fc96c4b2405a268b1d10f9/external/maven/netrc

After updating credential in actual netrc file the generated version of netrc it is not updated. But bazel continues to use generated version of netrc with wrong credentials.

Would be glad for explanation what I am doing wrong. If this is not the case, what changes need to be made to invalidate generated netrc file whenever actual one is updated?

[joprice]

I hit this when my netrc contained a comment, which caused the following error: "Unexpected token '#password' while reading netrc". I removed the comment, but the changes were not picked up. I had to manually delete the cache and repin to replace the file.

[rfan-debug]

Version 4.0.0 still has this problem.

[josephglanville]

Turns out this is actually a pretty serious annoyance because if you are using private repos and someone clones the workspace and does a build before setting up their netrc file they will end up with a cached empty file and fail the build with 401s when trying to fetch private jars.

[shs96c]

If you run a bazel shutdown and then attempt the build, am I correct in assuming that the credentials are properly handled?

And is this just for builds? Does the same problem occur when pinning dependencies?

I suspect that the problem is that the .netrc file is not a file that Bazel is tracking, so it has no idea that it's changed, and so isn't re-reading it. Finding out whether this happens will help narrow down whether this is a general bazel problem or something specific to rules_jvm_external

[josephglanville]

Yes this was running a build after a checkout with already pinned dependencies. I think it will be pretty easy for me to repro so I will see if bazel shutdown does the trick.

[josephglanville]

So I was able to trivially repro this by:

$ mv ~/.netrc ~/netrcbackup
$ rm -rf ~/.cache/bazel
$ bazel build //... # this fails with 401 as .netrc has been nuked
$ bazel shutdown
$ mv ~/netrcbackup ~/.netrc
$ bazel build //... # still fails
$ rm -rf ~/.cache/bazel
$ bazel build //... # succeeds

So Bazel shutdown wasn't successful in causing Bazel/rules_jvm_external to re-read the netrc file.

Is there a more selective way to blow away this cached value as a workaround until the underlying issue is fixed?