-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
java_binary: No way to provide dynamic manifest file content #2009
Comments
I also can't find a way to do this, so I declare this a missing feature. @ulfjack : Can we add support for this feature? Summary: @davido wants to write workspace status data into the |
Fewer features is better. I think there are two alternatives here:
|
+1
How about adding another attribute
I don't know why that matters, could you explain? |
I'm not sure what the semantics of those values are. I am not sure that having different modes is necessary, and we need to talk about how we'd add the aforementioned values to the manifest in the first place.
The code in the deploy jar is the same as in the binary, just that the binary consists of many jar files. Ideally, we use the same mechanism in both cases, otherwise we'd need to detect if we're running from a deploy jar or not. I think it's more 'consistent' with how Java generally works to put the stamping information into the manifest instead of a separate .txt file, but it's not clear to me how that'd work for non-deploy jars. |
My proposal for the semantics is, if the value is
We could pack the same manifest file in both, no? I'm assuming we have control over what goes into the jar file. |
Extend workspace status script to scan plugins directory and generate git version for each of them in stable-status.txt file. This can be used in plugin build rule to include this as plugin version info. Given that there is no way to dynamically merge manifest file content in Bazel[1] in java_binary rule, we have two options: either manipulate the plugin artifact file by appending the generated plugin version in post java_binary step in the META-INF/MANIFEST.MF file, or add VERSION resource file in the plugin and route reading plugin version to this file. TEST PLAN: $ bazel build :gen_version $ cat bazel-out/stable-status.txt STABLE_BUILD_COMMIT-MESSAGE-LENGTH-VALIDATOR_LABEL v2.13.1-2-g76b9115 STABLE_BUILD_COOKBOOK-PLUGIN_LABEL v2.13.2-12-g0162fc1 STABLE_BUILD_DOWNLOAD-COMMANDS_LABEL v2.13.1-4-g6326db6 STABLE_BUILD_GERRIT_LABEL v2.13.2-1329-g7c5917b-dirty [...] [1] bazelbuild/bazel#2009 Change-Id: Ie900617e918246ebb54080517161021f3030fdab
It's not clear how the code finds the right manifest in the non-deploy case. I think we'd need to look at an example or two to figure out what the right semantics should be here. |
+1 to this issue. |
Any update? Interested in controlling the content of the manifest in the non-deploy use case, too. |
@iirina : What do you think of this feature request? |
Bazel stamp error message is very misleading and hard to track down and understand. A number of prerequisites must be met for the stamping machinery to work properly. Bazel's missing feature to dynamically construct MANIFEST.MF file and pass such file to java_binary rule contributes to this problem: [1]. To rectify, split the stamp information retrieval in its own rule. The reason for the failure is because bazel is using "set -o pipefail" for genrules. This particular option sets the exit code of a pipeline to that of the rightmost command to exit with a non-zero status, or to zero if all commands of the pipeline exit successfully. Given the self descriptive rule name: <plugin>__gen_stamp_info it is clear where to look for, in tools/workspace-status.sh command. Test Plan: 1. Apply this CL in bazlets repository 2. Clone reviewers plugin and switch to consume bazlets from local directory 3. Patch tools/workspace-status.sh file and replace this line: echo STABLE_BUILD_REVIEWERS_LABEL $(rev .) with: echo STABLE_BUILD_REVIEW_LABEL $(rev .) 4. Run bazel build :reviewers and notice that correct failing rule is now reported: $ bazel build reviewers INFO: Analysed target //:reviewers (0 packages loaded). INFO: Found 1 target... ERROR: /home/davido/projects/reviewers/BUILD:3:1: Executing genrule //:reviewers__gen_stamp_info failed (Exit 1) Target //:reviewers failed to build [1] bazelbuild/bazel#2009 Change-Id: Ia2ad7238f77cafb89fa822b78c5d658ccedc8d11
Bazel stamp error message is very misleading and hard to track down and understand. A number of prerequisites must be met for the stamping machinery to work properly. Bazel's missing feature to dynamically construct MANIFEST.MF file and pass such file to java_binary rule contributes to this problem: [1]. To rectify, split the stamp information retrieval in its own rule. The reason for the failure is because bazel is using "set -o pipefail" for genrules. This particular option sets the exit code of a pipeline to that of the rightmost command to exit with a non-zero status, or to zero if all commands of the pipeline exit successfully. Given the self descriptive rule name: <plugin>__gen_stamp_info it is clear where to look for, in tools/workspace-status.sh command. Test Plan: 1. Apply this CL in bazlets repository 2. Clone reviewers plugin and switch to consume bazlets from local directory 3. Patch tools/workspace-status.sh file and replace this line: echo STABLE_BUILD_REVIEWERS_LABEL $(rev .) with: echo STABLE_BUILD_REVIEW_LABEL $(rev .) 4. Run bazel build :reviewers and notice that correct failing rule is now reported: $ bazel build reviewers INFO: Analysed target //:reviewers (0 packages loaded). INFO: Found 1 target... ERROR: /home/davido/projects/reviewers/BUILD:3:1: Executing genrule //:reviewers__gen_stamp_info failed (Exit 1) Target //:reviewers failed to build [1] bazelbuild/bazel#2009 Change-Id: Ia2ad7238f77cafb89fa822b78c5d658ccedc8d11 (cherry picked from commit 4459b97)
Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so. |
@bazelbuild/triage not stale. |
There seems to be no way to provide dynamic content, like build info into
MANIFEST.MF
file injava_binary
rule. Only deploy_manifest_lines is supported, where only list of static strings can be provided.In Buck there is
manifest_file
attribute injava_binary
rule where a label can be provided.What people normally want to achieve is to add build version into manifest file. This can be done (since Bazel 0.3.2) with
--workspace_status_command=./tools/workspace-status.sh
option in.bazelrc
file and this genrule:However, unless I'm missing something obvious, there is no way to merge this version into
MANIFEST.MF
injava_binary
rule:gerrit_plugin_version.txt
is included in the root of the plugin JAR:With the above rules we have this content of
META-INF/MANIFEST.MF
:What I would like to be able to have instead, is:
The text was updated successfully, but these errors were encountered: