Add client option to disable updating the mtime of the install_base

[rrbutani]

Currently if the --install_base path passed is not writeable by the user invoking Bazel, the Bazel client crashes¹, even if the path already contains a suitable extracted Bazel installation:

❯ bazel --install_base=/some/read/only/path/with/a/pre-existing/bazel/install version
FATAL: failed to set timestamp on '/some/read/only/path/with/a/pre-existing/bazel/install': (error: 30): Read-only file system

This happens because the Bazel client (unconditionally) attempts to update the mtime of this path:

bazel/src/main/cpp/blaze.cc

Lines 1010 to 1021 in a3c677d

	// Update the mtime of the install base so that cleanup tools can
	// find install bases that haven't been used for a long time
	std::unique_ptr<blaze_util::IFileMtime> mtime(
	blaze_util::CreateFileMtime());
	if (!mtime->SetToNow(blaze_util::Path(startup_options.install_base))) {
	string err = GetLastErrorString();
	BAZEL_DIE(blaze_exit_code::LOCAL_ENVIRONMENTAL_ERROR)
	<< "failed to set timestamp on '" << startup_options.install_base
	<< "': " << err;
	}
	}
	}

This PR gates this mtime update on a new client startup option: --update_install_base_mtime.

---

This commit:

• adds the update_install_base_mtime option to startup_options.cc and BlazeServerStartupOptions.java
• adds logic to src/main/cpp/blaze.cc to ensure that changes to this option do not cause server restarts
• updates bazel_startup_options_test.cc
• adds tests to client_test.sh that test that:
  • the install base mtime is updated when --update_install_base_mtime is passed (the default)
  • the install base mtime is not updated when --noupdate_install_base_mtime is passed
  • changes to --install_base_mtime do not cause server restarts

---

TODO:

• Both bazel_startup_options_test.cc and startup_options.cc describe a special procedure for updating startup flags:

  bazel/src/test/cpp/bazel_startup_options_test.cc

  Lines 92 to 94 in a3c677d

  	// IMPORTANT: Before modifying this test, please contact a Bazel core team
  	// member that knows the Google-internal procedure for adding/deprecating
  	// startup flags.

  bazel/src/main/cpp/startup_options.cc

  Lines 127 to 129 in a3c677d

  	// IMPORTANT: Before modifying the statements below please contact a Bazel
  	// core team member that knows the internal procedure for adding/deprecating
  	// startup flags.

Footnotes

1. Note that if you invoke Bazel again after this happens, it will successfully start up because the install symlink in the output base that inhibits the mtime update/install base check has already been created. ↩

[tjgq]

Do we really need a flag for this? Would it suffice to have the mtime call ignore EROFS (and possibly also EPERM, for good measure)? This seems to only matter for cleanup, so there's no build correctness at stake.

[rrbutani]

Do we really need a flag for this? Would it suffice to have the mtime call ignore EROFS (and possibly also EPERM, for good measure)? This seems to only matter for cleanup, so there's no build correctness at stake.

Sure, ignoring the error works just as well for my use case.

I'm not clear on what cleanup tooling the comment is referring to but regardless it does seem fairly unlikely that not erroring would break people's flows in a significant way.

---

As a counterpoint though: would we still want to emit a warning when the mtime update fails? If so, it'd be nice to have a flag to silence the warning...

(though, this — changes to the pair of install base, output base paths — happens infrequently enough that I'm willing to compromise on ^, especially if adding an extra startup flag will require an involved internal process or create extra work for the core team)

[rrbutani]

I also wasn't able to come up with a way to produce a read-only install base for use with the integration tests without privileges (whereas testing whether the mtime is updated is straightforward) but that matters less I suppose; if we switch to ignoring the error I assume we'd be okay not having a test for this particular thing.

[tjgq]

I wouldn't insist on having a test for the read-only case, and a warning seems unwarranted as well. This only affects the ability of external tooling to garbage collect old install bases, but if your install base is read-only, then it can't be garbage collected pretty much by definition :)

Would you like to either modify this PR, or send a separate one with the simpler change?

[rrbutani]

I wouldn't insist on having a test for the read-only case, and a warning seems unwarranted as well. This only affects the ability of external tooling to garbage collect old install bases, but if your install base is read-only, then it can't be garbage collected pretty much by definition :)

👍 Sounds good to me.

Would you like to either modify this PR, or send a separate one with the simpler change?

I'll open a separate PR later today.

[rrbutani]

Superseded by #20442.