bazelbuild / bazelbuild/rules_java

Unable to use stamp information in `java_binary`'s MANIFEST.MF

Abierto
#266 1 comentario 0 reacciones 0 asignados Ver en GitHub
P2
Lenguaje dominante
Starlark
Estrellas
103
Forks
102
Métricas de merge de PR
Sin PR fusionados en 30 d

Descripción

As far as I can tell, it currently isn't possible to use the output from `--workspace_status_command` in `java_*` rules. Specifically, it seems like a fairly common use-case (and coincidentally, what I'm currently trying to do 😉) would be to include some form of build information (revision / build date / whatever) in the `MANIFEST.MF` of a `.jar` file.

**Expected behaviour**: able to `--stamp` a `java_binary` with custom variables
**Actual behaviour**: unable to pass through any custom variables to `deploy_manifest_lines`
**Steps to reproduce**:

As a fairly trivial reproduction:

```starlark
# .bazelrc
common --stamp --workspace_status_command=/usr/bin/true --embed_label="Hello"
```

```starlark
# BUILD.bazel
java_binary(name = "test", ..., deploy_manifest_lines = [ "Custom-Label: {{BUILD_EMBED_LABEL}}" ])
```

Running `bazel build :test_deploy.jar && unzip -p bazel-bin/test_deploy.jar META-INF/MANIFEST.MF` outputs:

```
...
Custom-Label: {{BUILD_EMBED_LABEL}}
...
```

rather than the desired:
```
...
Custom-Label: Hello
...
```

**Extra information**

I'm not 100% sure if this has changed in newer versions of `rules_java` (having a quick glance at the source, it seemed not?) but at least as of v7.x the attribute for `deploy_manifest_lines` only accepts a `list` of strings, and states:

> The contents of this attribute are not subject to "Make variable" substitution.

It seems like there are maybe two related problems*, one is specific to `rules_java` and the other is a more general Bazel thing:

1. `java_binary` only accepts fixed strings for `deploy_manifest_lines`
2. Bazel does not provide _convenient_ access to workspace status vars in macros or custom rules.

From what I've seen in some other places (e.g. `rules_oci`) there's no good solution to (2), so the pattern seems to be to allow providing a single file to use, and then having a command that generates that file by also reading from the `bazel-out/stable-status.txt` and `bazel-out/volatile-status.txt` files, e.g.

```starlark
# BUILD.bazel
java_manifest(name = "manifest", lines = {"Custom-Label": "{{BUILD_EMBED_LABEL}}")
java_binary(name = "test", ..., deploy_manifest_lines = ":manifest")
```

`*` I imagine some people will argue this is a feature, but it doesn't feel like it from here!

If it's possible to do it without generating an intermediate file, that would be even better, but I suspect that won't be the case (at least without some major work to Bazel itself...)!

Guía de contribución

Abrir la guía de contribución

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.