Update run.bzl

[dieend]

What is the current behavior?

container_run_and_extract is intentionally non-hermetic, because docker isn't sandboxed and may read arbitrary files. It can't be correctly invalidated from the cache, because some of the dependencies cannot be declared.

What is the new behavior?

Rules now accept extra dependency

[google-cla]

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 with @googlebot 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.

[dieend]

@googlebot I signed it!

[sluongng]

I am a bit confused with this PR: there is a clear lack of context in the PR description and the commit messages are also lacking in term of quality.

I would suggest at minimum linking PR with an issue stating the problem?

[alexeagle]

@sluongng I agree, this is one of those no-time-for-maintainership issues where the code change is pretty clear but everything else about the PR needs work. I can choose between merging it or teaching the contributor, but probably not both

[alexeagle]

sorry I was a bit defensive there. Thanks for pointing this out @sluongng - next time I won't be so permissive with merging.

[sluongng]

@alexeagle all is good. I know it takes a lot of effort being a maintainer and I know many bazelbuild projects are still in an early stage, process may be unclear.

There will always be a tradeoff between maintainability and speed but I have no clue where to draw the line for these projects.

I usually have to read HEAD of 'master/main' branch of these projects to find whether they are suitable to update our internal tracking. When a PR comes with unclear context, it might takes a bit of extra time and effort to digest.

Thanks for keeping the project fresh 🤝

[alexeagle]

I updated the original comment to reflect my understanding of the issue, so at least anyone arriving here from release notes or commit history can understand it better.

[dieend]

Sorry for not providing enough context. I was planning to update the PR description after further testing internally and didn't expect it's merged pretty soon.

Thank you for improving the PR description 🙏