Add no-remote-cache and no-remote-exec execution requirements

[SrodriguezO]

This resolves #7932

It introduces two new execution requirements:

• no-remote-exec: disallows remote execution without preventing remote caching
• no-remote-cache: disallows remote caching without preventing remote execution or local caching

The current behavior of no-remote and no-cache remain unchanged.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[SrodriguezO]

I'd like to add some tests around the new execution requirements before merging, but I figured I'd open the PR so it can start getting some feedback

[SrodriguezO]

@ishikhman when you get a minute could you look over this? It's fairly short, and I'd love some feedback :)

[SrodriguezO]

Finished adding tests and squashed commits

[ishikhman]

Thanks a lot for doing this change!

I keep thinking whether it makes sense to add no-remote-cache which behaves exactly the same as no-cache.. other than that - just a few notes from my side (will have another look next week, sorry for the delay)

[SrodriguezO]

Force-push was squashing commits and rebasing on master

[SrodriguezO]

Force push was squashing commits

[SrodriguezO]

@ishikhman @buchgr @ola-rozenfeld I think this is ready for final review :)

[ishikhman]

Perfect! Thanks a lot :)
just a few nit comments from me, otherwise LGTM

[SrodriguezO]

Force push was squashing commits

[SrodriguezO]

@buchgr @ola-rozenfeld could you review when you get a minute?

[ishikhman]

Sorry, missed the one use case in the initial review:
what if we have combined cache - remote (http for now) and local (disk) - AND no-remote-cache tag. For now, bazel would still be using both caches, but should use only disk cache in such a case.
I think we missed this use case. Could you please add test cases and maybe code changes for that?

[SrodriguezO]

Force-push was squashing commits and rebasing on master

[SrodriguezO]

Force-push was squashing commits and rebasing on master

[SrodriguezO]

Woops, I wasn't actually rebasing on master before because our fork was a bit out of date 😅

Synced our fork and rebased on master now.

[SrodriguezO]

@ishikhman could you review again when you get a chance?

Do we also need @buchgr and/or @ola-rozenfeld to review before merging?

[ishikhman]

LGTM, thanks a lot!
@SrodriguezO I'll try to merge it in the next days :)

FYI for the future PRs: please avoid force pushing, it makes changes a bit less obvious during code review ;) Everything will be merged as one commit in the end, with the message taken from the PR description.

[SrodriguezO]

Ah okay. Sorry about that. I'll avoid force pushes in the future. Thanks for the review!

[SrodriguezO]

@ishikhman what should I do about rebasing though?

For instance, the branch has a conflict, but to fix it I have to either rebase on master (which would require a force-push) or merge master in (which makes the git history a bit messy). Which path would you suggest?

Edit: In this particular case I was able to fix the conflict without merging master or rebasing because it was a very simple one, but my question stands for the general case :)

[ishikhman]

@ishikhman what should I do about rebasing though?

In this case I usually prefer rebasing to master, cause that won't produce additional commits like merge would do :)
Sorry, the phrasing of my initial advice was a bit confusing. What I meant is this: please avoid amends or any other changes to existing comments, because this makes it a bit harder to see what exactly was changed during the review. Rebasing to master is fine ;)

PS: merge is coming today.

[buchgr]

yay! great job both!

[SrodriguezO]

Sorry, the phrasing of my initial advice was a bit confusing. What I meant is this: please avoid amends or any other changes to existing comments, because this makes it a bit harder to see what exactly was changed during the review. Rebasing to master is fine ;)

I see; thanks for the advice! And thanks for all the feedback on the PR :)