feedback-to-code/mozzarella huggingface dataset:
Repository: bazelbuild/bazel
Issue: Document --spawn_strategy=standalone for test
Labels: type: feature request
type: documentation (cleanup)
P4
category: sandboxing
good first issue

### Description of the problem / feature request / question:

`--spawn_strategy=standalone` actually disables sandboxing for tests. This is IMO not clear since the option  is documented under _BuildOptions_. Make it clear that it also applies for testing.


Issue comments:
@philwo can you take a look at this?
I would like to take this issue up.. 
@philwo, @iirina any progress on this yet?
@aljabrr I don't think anyone of us is working on it. Please feel free to send a patch via Gerrit. :)

The help string for that option is here:

https://github.com/bazelbuild/bazel/blob/94fbad5b230ae0c02a88100f1978d40d17d57b71/src/main/java/com/google/devtools/build/lib/bazel/rules/BazelRulesModule.java#L51

It is used to automatically build the documentation on the website, so just changing that string to a better explanation should be enough.

Pull request review comments:
Not only for tests, I would change this to:

'standalone' means run all of them locally without any kind of sandboxing
This is also wrong by now, it should read:

'sandboxed' means to run them in a sandboxed environment with limited privileges (details depend on platform support)
Thanks for the review. Updated.
Thanks for the review. Updated

Patch that resolved the issue:
diff --git a/src/main/java/com/google/devtools/build/lib/bazel/rules/BazelStrategyModule.java b/src/main/java/com/google/devtools/build/lib/bazel/rules/BazelStrategyModule.java
index 512b5c0f3b1c8f..cc72ec77ed19db 100644
--- a/src/main/java/com/google/devtools/build/lib/bazel/rules/BazelStrategyModule.java
+++ b/src/main/java/com/google/devtools/build/lib/bazel/rules/BazelStrategyModule.java
@@ -43,8 +43,8 @@ public static class BazelExecutionOptions extends OptionsBase {
       effectTags = {OptionEffectTag.UNKNOWN},
       help =
           "Specify how spawn actions are executed by default."
-              + "'standalone' means run all of them locally."
-              + "'sandboxed' means run them in namespaces based sandbox (available only on Linux)"
+              + "'standalone' means run all of them locally without any kind of sandboxing."
+              + "'sandboxed' means to run them in a sandboxed environment with limited privileges (details depend on platform support)"
     )
     public String spawnStrategy;
 


Test patch:
Repository: bazelbuild/bazel
Issue: Compile Bazel on Power8
Labels: type: bug
P2
platform: other

Hi!

I am trying to compile Bazel from source on a Power 8 machine.

Here's the error I get when launching "bash compile.sh"

🍃  Building Bazel from scratch.......
🍃  Building Bazel with Bazel.
ERROR: No toolchain found for cpu 'ppc'. Valid cpus are: [
  piii,
  armeabi-v7a,
  x64_windows_msvc,
  x64_windows_msys,
  s390x,
  ios_x86_64,
].
INFO: Elapsed time: 2.181s

ERROR: Could not build Bazel

The output from uname -a:

4.7.4-200.fc24.ppc64 #1 SMP Thu Sep 22 17:40:37 UTC 2016 ppc64 ppc64 ppc64 GNU/Linux

Do you have any idea of why I get this error?

Thank you


Issue comments:
I'm actually not sure why it doesn't pick this up automatically, but it seems to only be looking for crosstools in `@local_config_cc`, which doesn't contain a ppc crosstool (?).  You have to give the `--crosstool_top=//tools/cpp:default-toolchain` argument to make it look at //tools/cpp, which _does_ contain a ppc toolchain.

However, I'm not actually sure how to give extra arguments to the ./compile.sh script, so assigning to @damienmg for clarification on:

1. How to pass `--crosstool_top` into `./compile.sh`.
2. Why `@local_config_cc` doesn't contain the same toolchain as `@bazel_tools`.
3. Why they aren't both used to find toolchains.
I solved it making two small modifications:

1- added 
       default_toolchain {
  	  cpu: "ppc64"
  	  toolchain_identifier: "local_linux"
	}

   to tools/cpp/CROSSTOOL

2- in the file "tools/cpp/cc_configure.bzl" changed 

    "if result.stdout.strip() in ["power", "ppc64le", "ppc"]:"

    into

   "if result.stdout.strip() in ["power", "ppc64le", "ppc", "ppc64"]:"

I am not sure if both the modifications are actually necessary, but that's what I did and I successfully built bazel
@davideleoni90: would you be willing to send a PR with those modification? They looks reasonable to me.
(re-opened the bug because the code is not fixed)

Pull request review comments:
nit: add missing space after the comma.

Patch that resolved the issue:
diff --git a/tools/cpp/CROSSTOOL b/tools/cpp/CROSSTOOL
index bb22006090ab08..d70a6dcb604908 100644
--- a/tools/cpp/CROSSTOOL
+++ b/tools/cpp/CROSSTOOL
@@ -44,6 +44,11 @@ default_toolchain {
   toolchain_identifier: "local_linux"
 }
 
+default_toolchain {
+  cpu: "ppc64"
+  toolchain_identifier: "local_linux"
+}
+
 default_toolchain {
   cpu: "ios_x86_64"
   toolchain_identifier: "ios_x86_64"
diff --git a/tools/cpp/cc_configure.bzl b/tools/cpp/cc_configure.bzl
index 4f93195d26b999..ae87934b68ce49 100644
--- a/tools/cpp/cc_configure.bzl
+++ b/tools/cpp/cc_configure.bzl
@@ -161,7 +161,7 @@ def _get_cpu_value(repository_ctx):
     return "x64_windows"
   # Use uname to figure out whether we are on x86_32 or x86_64
   result = repository_ctx.execute(["uname", "-m"])
-  if result.stdout.strip() in ["power", "ppc64le", "ppc"]:
+  if result.stdout.strip() in ["power", "ppc64le", "ppc", "ppc64"]:
     return "ppc"
   if result.stdout.strip() in ["arm", "armv7l", "aarch64"]:
     return "arm"


Test patch:
Repository: bazelbuild/bazel
Issue: Docs describe nonexistent --local_genrule_timeout_seconds option
Labels: type: documentation (cleanup)
P2

### Description of the problem / feature request / question:

https://bazel.build/versions/master/docs/bazel-user-manual.html describes an option called `--local_genrule_timeout_seconds`, but I can't find any such option, or anything similar. Should this be removed from the docs?

Issue comments:
You're right, that's a holdover from the internal docs, and should be removed. Would you like to send a patch to remove it?

Pull request review comments:

Patch that resolved the issue:
diff --git a/site/docs/bazel-user-manual.html b/site/docs/bazel-user-manual.html
index f38f29f60e3f19..f16498cf2041f7 100644
--- a/site/docs/bazel-user-manual.html
+++ b/site/docs/bazel-user-manual.html
@@ -1824,9 +1824,6 @@ <h4 id='flag--genrule_strategy'><code class='flag'>--genrule_strategy <var>strat
 
 </ul>
 
-<h4 id='flag--local_genrule_timeout_seconds'><code class='flag'>--local_genrule_timeout_seconds <var>seconds</var></code></h4>
-<p>Sets a timeout value for local genrules with the given number of seconds.</p>
-
 <h4 id='flag--jobs'><code class='flag'>--jobs <var>n</var></code> (-j)</h4>
 <p>
   This option, which takes an integer argument, specifies a limit on


Test patch:
Repository: bazelbuild/bazel
Issue: Bazel analyze-profile crashes outside of a workspace
Labels: type: bug
P1
category: misc > misc

I think that's a recent regression.

Issue comments:
```
$ bazel analyze-profile profile
java.lang.NullPointerException
	at com.google.devtools.build.lib.runtime.commands.ProfileCommand.exec(ProfileCommand.java:251)
	at com.google.devtools.build.lib.runtime.BlazeCommandDispatcher.execExclusively(BlazeCommandDispatcher.java:552)
	at com.google.devtools.build.lib.runtime.BlazeCommandDispatcher.exec(BlazeCommandDispatcher.java:331)
	at com.google.devtools.build.lib.runtime.BlazeRuntime.batchMain(BlazeRuntime.java:760)
	at com.google.devtools.build.lib.runtime.BlazeRuntime.main(BlazeRuntime.java:552)
	at com.google.devtools.build.lib.bazel.BazelMain.main(BazelMain.java:57)
java.lang.NullPointerException
	at com.google.devtools.build.lib.runtime.commands.ProfileCommand.exec(ProfileCommand.java:251)
	at com.google.devtools.build.lib.runtime.BlazeCommandDispatcher.execExclusively(BlazeCommandDispatcher.java:552)
	at com.google.devtools.build.lib.runtime.BlazeCommandDispatcher.exec(BlazeCommandDispatcher.java:331)
	at com.google.devtools.build.lib.runtime.BlazeRuntime.batchMain(BlazeRuntime.java:760)
	at com.google.devtools.build.lib.runtime.BlazeRuntime.main(BlazeRuntime.java:552)
	at com.google.devtools.build.lib.bazel.BazelMain.main(BazelMain.java:57)
```

Pull request review comments:
There's no need to call new String() here. Just pass in "<workspace>".

Patch that resolved the issue:
diff --git a/src/main/java/com/google/devtools/build/lib/runtime/commands/ProfileCommand.java b/src/main/java/com/google/devtools/build/lib/runtime/commands/ProfileCommand.java
index f39f0054b35774..b9f2fd7eb35813 100644
--- a/src/main/java/com/google/devtools/build/lib/runtime/commands/ProfileCommand.java
+++ b/src/main/java/com/google/devtools/build/lib/runtime/commands/ProfileCommand.java
@@ -281,11 +281,18 @@ public BlazeCommandResult exec(final CommandEnvironment env, OptionsProvider opt
             PhaseSummaryStatistics phaseSummaryStatistics = new PhaseSummaryStatistics(info);
             EnumMap<ProfilePhase, PhaseStatistics> phaseStatistics =
                 new EnumMap<>(ProfilePhase.class);
+
+            Path workspace = env.getWorkspace();
             for (ProfilePhase phase : ProfilePhase.values()) {
               phaseStatistics.put(
                   phase,
                   new PhaseStatistics(
-                      phase, info, env.getWorkspace().getBaseName(), opts.vfsStatsLimit > 0));
+                      phase,
+                      info,
+                      (workspace == null
+                          ? "<workspace>"
+                          : workspace.getBaseName()),
+                      opts.vfsStatsLimit > 0));
             }
 
             CriticalPathStatistics critPathStats = new CriticalPathStatistics(info);


Test patch:
Repository: bazelbuild/bazel
Issue: Print buildozer command for "add the following deps" message
Labels: type: feature request
P3

Right now we print something like:

```
** Please add the following dependencies:
  //:C  to //:A
```

Now that buildozer is open sourced, it would be nice to give people a one-liner to run.

Issue comments:
+1!
On Wed, 28 Jun 2017 at 18:21 Kristina <notifications@github.com> wrote:

> Right now we print something like:
>
> ** Please add the following dependencies:
>   //:C  to //:A
>
> Now that buildozer is open sourced, it would be nice to give people a
> one-liner to run.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/bazelbuild/bazel/issues/3285>, or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABUIFxn0FL_wRhVUmDkFCrhFcJOiYPOdks5sIm9-gaJpZM4OIH7W>
> .
>

For future reference:
This seems to be the test: https://github.com/bazelbuild/bazel/blob/66437a0173488ca4e77aab8c41d5454871c8c6a2/src/test/shell/bazel/local_repository_test_jdk8.sh#L98
This seems to be the prod code:
https://github.com/bazelbuild/bazel/blob/66437a0173488ca4e77aab8c41d5454871c8c6a2/src/java_tools/buildjar/java/com/google/devtools/build/buildjar/javac/plugins/dependency/DependencyModule.java#L337

Pull request review comments:

Patch that resolved the issue:
diff --git a/src/java_tools/buildjar/java/com/google/devtools/build/buildjar/javac/plugins/dependency/DependencyModule.java b/src/java_tools/buildjar/java/com/google/devtools/build/buildjar/javac/plugins/dependency/DependencyModule.java
index 7d2ddb46b768c3..7167756fb9563f 100644
--- a/src/java_tools/buildjar/java/com/google/devtools/build/buildjar/javac/plugins/dependency/DependencyModule.java
+++ b/src/java_tools/buildjar/java/com/google/devtools/build/buildjar/javac/plugins/dependency/DependencyModule.java
@@ -334,7 +334,8 @@ public String get(Iterable<JarOwner> missing, String recipient, boolean useColor
         }
 
         return String.format(
-            "%s** Please add the following dependencies:%s\n  %s to %s\n\n",
+            "%1$s ** Please add the following dependencies:%2$s \n  %3$s to %4$s \n" +
+            "%1$s ** You can use the following buildozer command:%2$s \nbuildozer 'add deps %3$s' %4$s \n\n",
             useColor ? "\033[35m\033[1m" : "",
             useColor ? "\033[0m" : "",
             missingTargetsStr.toString(),


Test patch:
Repository: bazelbuild/bazel
Issue: Use a variable for latest Bazel version number in docs
Labels: type: feature request
type: documentation (cleanup)

Our install docs are often displaying the latest version number to download: http://docs.bazel.build/versions/master/install-ubuntu.html

Today, this is hardcoded in the text.
We should introduce a variable that is defined in one place and that we update when performing the release.
https://github.com/bazelbuild/bazel/blob/master/site/_config.yml is probably the place to put this variable.

Issue comments:
The install docs are now versioned, and I also don't see hardcoded Bazel version numbers in the installation instructions anymore.

https://docs.bazel.build/versions/0.20.0/install-windows.html
https://docs.bazel.build/versions/0.20.0/install-ubuntu.html

Pull request review comments:

Patch that resolved the issue:
diff --git a/scripts/docs/doc_versions.bzl b/scripts/docs/doc_versions.bzl
index 4e4b76a5ffc52e..09f2c80aacfdd9 100644
--- a/scripts/docs/doc_versions.bzl
+++ b/scripts/docs/doc_versions.bzl
@@ -22,6 +22,10 @@
 """This module contains the versions and hashes of Bazel's documentation tarballs."""
 
 DOC_VERSIONS = [
+    {
+        "version": "0.21.0",
+        "sha256": "23ec39c0138d358c544151e5c81586716d5d1c6124f10a742bead70516e6eb93",
+    },
     {
         "version": "0.20.0",
         "sha256": "bb79a63810bf1b0aa1f89bd3bbbeb4a547a30ab9af70c9be656cc6866f4b015b",
diff --git a/site/_config.yml b/site/_config.yml
index 00f82998f49c69..9e82fe02e149d8 100644
--- a/site/_config.yml
+++ b/site/_config.yml
@@ -15,6 +15,7 @@ version: "master"
 # This must be kept in sync with //site/script/docs:versions.bzl
 doc_versions:
   - master
+  - 0.21.0
   - 0.20.0
   - 0.19.2
   - 0.19.1


Test patch:
Repository: bazelbuild/bazel
Issue: Please let the Debian package depend on headless JDK
Labels: type: feature request
P3
category: misc > misc

The official Bazel packages for Debian/Ubuntu depend on `java8-sdk`, which usually resolves to `openjdk-8-jdk`. This is the full JDK including graphical toolkits, and it's fairly bulky when working within a Docker container:

```shell
$ apt-get install --no-install-recommends openjdk-8-jdk
[...]
Need to get 72.8 MB of archives.
After this operation, 384 MB of additional disk space will be used.
```

Since Bazel doesn't have a graphical component, it would be nice if it depended on `java8-sdk-headless`, which is less than half as big:

```shell
$ apt-get install --no-install-recommends openjdk-8-jdk-headless
[...]
Need to get 39.8 MB of archives.
After this operation, 155 MB of additional disk space will be used.
```

Issue comments:
Sounds like a good idea! @philwo , @aehlig : WDYT? 
@jmillikin-stripe Considering that java8-jdk-headless doesn't exist, should we then change the dependency list from:

> google-jdk | java8-jdk | java8-sdk | oracle-java8-installer

into:

> google-jdk | java8-sdk-headless | oracle-java8-installer

?

The java8-sdk-headless package seems to exist and do the job for Debian and Ubuntu:
https://packages.debian.org/sid/java8-sdk-headless
https://packages.ubuntu.com/zesty/java8-sdk-headless

Not sure why we even had the java8-jdk one in there.
`java8-jdk` exists in Debian: https://packages.debian.org/sid/java8-jdk

I'm slightly nervous about changing/removing virtual packages, because they can be mapped to different things on different systems. I think a safe, minimally-intrusive change would be to change the dep to:

`google-jdk | java8-sdk-headless | java8-jdk | java8-sdk | oracle-java8-installer`

That should prioritize the headless version if available, without breaking any existing dependency resolution on Dpkg-based non-Debian systems.
Gentle ping.

I could send a PR for this if you want, but someone in the Bazel side would still need to handle updating the Debian packages and such.
Note for future readers: the Debian package deps are duplicated, and need to be updated in both `debian/control` and `debian/BUILD`. See https://github.com/bazelbuild/bazel/pull/4686.

Pull request review comments:

Patch that resolved the issue:
diff --git a/scripts/packages/debian/control b/scripts/packages/debian/control
index 443240e5cafdec..fe428fce2eb50f 100644
--- a/scripts/packages/debian/control
+++ b/scripts/packages/debian/control
@@ -9,7 +9,7 @@ Package: bazel
 Section: contrib/devel
 Priority: optional
 Architecture: amd64
-Depends: google-jdk | java8-jdk | java8-sdk | oracle-java8-installer, g++, zlib1g-dev, bash-completion
+Depends: google-jdk | java8-sdk-headless | java8-jdk | java8-sdk | oracle-java8-installer, g++, zlib1g-dev, bash-completion
 Description: Bazel is a tool that automates software builds and tests.
  Supported build tasks include running compilers and linkers to produce
  executable programs and libraries, and assembling deployable packages


Test patch:
Repository: bazelbuild/bazel
Issue: CI: bazel-tests should add a Python 3.x configuration
Labels: type: feature request
P3
category: misc > testing

The current [bazel-tests CI job](https://github.com/bazelbuild/bazel/blob/master/scripts/ci/bazel-tests.json) does not run against a Python 3.x interpreter, so issues like #3816 happen.  We should add a configuration that does so, via the `--python_path` flag now, and perhaps via the `--python_top` flag later.

An alternative would be to add an ArchLinux configuration, which has `/usr/bin/python` point to a Python 3.x interpreter.


Issue comments:

Pull request review comments:
add "python_version": "3"
add "python_version": "2"
I recommend removing the non-linux configuration so you get a less noisy result. E.g. freebsd is a breakage at HEAD.
Added
Added
Done
I'm not sure what indentation it wants here.

Patch that resolved the issue:
diff --git a/scripts/ci/bazel-tests.json b/scripts/ci/bazel-tests.json
index 62af16f2da8a65..efd8bf1f11dc65 100644
--- a/scripts/ci/bazel-tests.json
+++ b/scripts/ci/bazel-tests.json
@@ -3,7 +3,17 @@
 [
     {
         "configurations": [
-            {"node": "linux-x86_64"},
+            {
+             "node": "linux-x86_64",
+              "python_version": "2"
+            },
+            {
+             "node": "linux-x86_64",
+             "python_version": "3",
+             "parameters": {
+                 "build_opts": ["--python_path=/usr/bin/python3"]
+             }
+            },
             {"node": "ubuntu_16.04-x86_64"}
         ],
         "parameters": {


Test patch:
Repository: bazelbuild/bazel
Issue: Improper formatting on aspects.html

https://docs.bazel.build/versions/master/skylark/aspects.html#advanced-example

![aspects](https://user-images.githubusercontent.com/15253456/33038876-eefb4f60-cdea-11e7-93c9-d8dc115cbe09.png)


Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/site/docs/skylark/aspects.md b/site/docs/skylark/aspects.md
index 4d32c73a707e83..fa80e5f08d9f58 100644
--- a/site/docs/skylark/aspects.md
+++ b/site/docs/skylark/aspects.md
@@ -176,6 +176,7 @@ It shows how to use a provider to return values, how to use parameters to pass
 an argument into an aspect implementation, and how to invoke an aspect from a rule.
 
 FileCount.bzl file:
+
 ```python
 FileCount = provider(
     fields = {
@@ -218,6 +219,7 @@ file_count_rule = rule(
 ```
 
 BUILD.bazel file:
+
 ```python
 load('//file_count.bzl', 'file_count_rule')
 


Test patch:
Repository: bazelbuild/bazel
Issue: Broken link in tutorial for 'C++ use cases'

The [C++ and Bazel](https://docs.bazel.build/versions/master/bazel-and-cpp.html) page has a bad link to https://docs.bazel.build/versions/master/tutorial/cpp-use-cases.html with text `C++ common use cases` under the `Working with Bazel` section.

This link should probably be to https://docs.bazel.build/versions/master/cpp-use-cases.html instead. The link to that page in the left-hand TOC sidebar resolves without issue.

Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/site/docs/bazel-and-cpp.md b/site/docs/bazel-and-cpp.md
index 84e9ed75493987..41083c7c4390f9 100644
--- a/site/docs/bazel-and-cpp.md
+++ b/site/docs/bazel-and-cpp.md
@@ -21,7 +21,7 @@ projects with Bazel.
 The following resources will help you work with Bazel on C++ projects:
 
 *  [Tutorial: Building a C++ project](tutorial/cpp.html)
-*  [C++ common use cases](tutorial/cpp-use-cases.html)
+*  [C++ common use cases](cpp-use-cases.html)
 *  [C/C++ rules](https://docs.bazel.build/versions/master/be/c-cpp.html)
 
 ## Best practices


Test patch:
Repository: bazelbuild/bazel
Issue: remote/bugs: some tests aren't cached remotely

These three tests aren't cached remotely on our CI.
```
//src/test/shell/bazel:bazel_determinism_test
//src/test/shell/bazel:bazel_bootstrap_distfile_test
//scripts/release:release_test
```

Need to investigate why this is the case.

cc: @ulfjack @philwo 



Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/src/main/java/com/google/devtools/build/lib/remote/RemoteSpawnCache.java b/src/main/java/com/google/devtools/build/lib/remote/RemoteSpawnCache.java
index 4ef09ad268f260..2da0cc1203d446 100644
--- a/src/main/java/com/google/devtools/build/lib/remote/RemoteSpawnCache.java
+++ b/src/main/java/com/google/devtools/build/lib/remote/RemoteSpawnCache.java
@@ -90,7 +90,7 @@ final class RemoteSpawnCache implements SpawnCache {
   @Override
   public CacheHandle lookup(Spawn spawn, SpawnExecutionContext context)
       throws InterruptedException, IOException, ExecException {
-    if (!Spawns.mayBeCached(spawn)) {
+    if (!Spawns.mayBeCached(spawn) || !Spawns.mayBeExecutedRemotely(spawn)) {
       return SpawnCache.NO_RESULT_NO_STORE;
     }
     boolean checkCache = options.remoteAcceptCached;


Test patch:
Repository: bazelbuild/bazel
Issue: remote/documentation: mention remote caching on CircleCI in the documentation

https://github.com/notnoopci/bazel-remote-proxy


Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/src/main/java/com/google/devtools/build/lib/remote/RemoteSpawnCache.java b/src/main/java/com/google/devtools/build/lib/remote/RemoteSpawnCache.java
index 4ef09ad268f260..2da0cc1203d446 100644
--- a/src/main/java/com/google/devtools/build/lib/remote/RemoteSpawnCache.java
+++ b/src/main/java/com/google/devtools/build/lib/remote/RemoteSpawnCache.java
@@ -90,7 +90,7 @@ final class RemoteSpawnCache implements SpawnCache {
   @Override
   public CacheHandle lookup(Spawn spawn, SpawnExecutionContext context)
       throws InterruptedException, IOException, ExecException {
-    if (!Spawns.mayBeCached(spawn)) {
+    if (!Spawns.mayBeCached(spawn) || !Spawns.mayBeExecutedRemotely(spawn)) {
       return SpawnCache.NO_RESULT_NO_STORE;
     }
     boolean checkCache = options.remoteAcceptCached;


Test patch: