[DO NOT MERGE] Add integration tests for Android resource processing with aapt and aapt2 #5222
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Without |
|
jin
changed the title
bazel-io
pushed a commit
that referenced
this pull request
May 22, 2018
Currently, if there are non-suppressed errors during aapt2 processing, Bazel does not print them. This helps with debugging #5222 With this, I get: ``` ERROR: /usr/local/google/home/jingwen/code/android_scratch_project/examples/android/java/bazel/BUILD:16:1: Processing Android resources for //examples/android/java/bazel:hello_world failed (Exit 1) May 21, 2018 5:31:01 PM com.google.devtools.build.android.ResourceProcessorBusyBox main SEVERE: java.io.IOException: Is a directory Target //examples/android/java/bazel:hello_world failed to build ``` instead of just: ``` ERROR: /usr/local/google/home/jingwen/code/android_scratch_project/examples/android/java/bazel/BUILD:16:1: Processing Android resources for //examples/android/java/bazel:hello_world failed (Exit 1) Target //examples/android/java/bazel:hello_world failed to build ``` RELNOTES: None. PiperOrigin-RevId: 197493881
|
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. |
|
CLAs look good, thanks! |
RELNOTES: None. PiperOrigin-RevId: 205665675
RELNOTES: None PiperOrigin-RevId: 205668909
On two fronts: First, it should follow standard command line semantics. Second, it should work as intended: --noblock_for_lock means the client will not wait for another command to finish, but will exit eagerly. It can be useful for preventing hanging in applications that are non-interactively calling bazel. It should have standard startup-option semantics: the default value is accepted as a no-op or can be provided to override a previous value. The next issue involves 2 different locks - the client lock, and the server-side command lock. This duality exists because we would like, one day, to be able to run certain commands, like info or help, at the same time, so multiple commands would need specialized locks that allow some duality but blocks others. This can only be done at the server level, so as soon as the client gets the "we're connected" grpc message from the server, it releases the client lock and lets the server manage multiple requests. There are basically 3 possible states that are relevant to this option: 1) no other client is active, so no one holds the client lock or the command lock - the server can be used, shutdown or started as needed. - no blocking, but no need to block, either, so we're safe 2) another client (client1) holds the lock, but it is currently using a server that we want to reuse. If client1 still holds the client lock, we fail fast. Same thing if client1 is holding the server-side lock: we will exit gracefully when the BlazeCommandDispatcher responds with a failure. 3) client1 holds the lock but its server cannot be reused. (batch clients also fall into this category, as there is no server to reuse - but in this case, the client lock is still in play). However, for server mode, this is broken - the following happens: - Server is occupied with client1's request, holds the command lock - client2 wants to restart the server, so sends the old server a "shutdown" command - the BlazeCommandDispatcher says - nuh-uh, this is busy, and you said you didn't want to wait for the lock - client2 absorbs this response - waits (blocks...) - for a minute - then force shuts-down the old server. So we had 2 problems - we block, and we shutdown a server that we truly intended to keep going. Now, if the server responds saying another action is using it, the client will exit correctly, and leave the old server to do its thing. RELNOTES: None. PiperOrigin-RevId: 205671817
PiperOrigin-RevId: 205682761
--output graph`. Implementation: AIUI, currently the "edges' conditions" are lost [1] when the larger graph is initially constructed. It now does a second pass over dependency subgraph to find all the conditional edges and annotates them in dot output. This can be easily extended in other forms of output, but for now it only annotates edges in dot output. [1]: https://github.com/bazelbuild/bazel/blob/32e9fee4e2192a340d0b1823538bf8e9fdf92b65/src/main/java/com/google/devtools/build/lib/query2/output/OutputFormatter.java#L745-L770 PiperOrigin-RevId: 205685823
…ce_library is available This way users of the Skylark API don't see this feature expanded. RELNOTES: None. PiperOrigin-RevId: 205704719
…ation in a very specific window of time inbetween enqueueing one top-level node for evaluation and checking if another top-level node is done. See the added unit test for details. RELNOTES: None PiperOrigin-RevId: 205718683
PiperOrigin-RevId: 205718853
PiperOrigin-RevId: 205729963
PiperOrigin-RevId: 205751282
…enerated source are generated. PiperOrigin-RevId: 205756917
Each FileSystem instance has a digest function, but the getDigest and getHashDigest functions also accepted their own custom parameter functions. We only support 1 hash per filesystem instance, these parameters are redundant. RELNOTES: None. PiperOrigin-RevId: 205758571
The conversion approach we were previously using is not stable - the resulting offsets can differ based on what other things are going on on the same machine at the same time. By using an interface and passing it to the relevant places (and only computing the offset once), we ensure that all conversions are consistent with each other. PiperOrigin-RevId: 205787309
Fixes bazelbuild#5599 PiperOrigin-RevId: 205794997
DeletePath and CreateJunction are now even more tolerant with errors, particularly the class of errors where access is denied. Also in this change: - remove DeletePathResult::kParentMissing, as this case is handled by CreateFileW's error handling later - do not error-check CreateDirectoryW; if failed, just proceed as if the directory already existed - print more debugging info where possible Change-Id: I1162dae2c6b7524f14d8892047f9eb51831470dd Closes bazelbuild#5611. Change-Id: I78fe6aed6d0b120815339c0923c8a903990921d9 PiperOrigin-RevId: 205796307
… as we treat java_proto_library. RELNOTES: None PiperOrigin-RevId: 205812269
Also simplify LoadingPhaseCompleteEvent, and SkyframeExecutor, and remove LoadingCallback, which is unnecessary now that we only have a single implementation (previously LoadingPhaseRunner). This also removes some of the excessive Skyframe calls introduced by bazelbuild@1067310, and prepares for interleaving target pattern eval and loading. PiperOrigin-RevId: 205813197
jin
removed request for
a team,
vladmos,
dmaclach,
laurentlb,
philwo,
sergiocampama,
hlopko,
allevato,
brandjon,
buchgr,
DavidGoldman,
lberki,
dslomov,
dkelmer,
ahumesky,
scentini,
c-parsons,
kevin1e100,
oquenchil,
ola-rozenfeld and
tualeron
|
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. |
luca-digrazia
pushed a commit
to luca-digrazia/DatasetCommitsDiffSearch
that referenced
this pull request
Sep 4, 2022
Currently, if there are non-suppressed errors during aapt2 processing, Bazel does not print them.
This helps with debugging bazelbuild/bazel#5222
With this, I get:
```
ERROR: /usr/local/google/home/jingwen/code/android_scratch_project/examples/android/java/bazel/BUILD:16:1: Processing Android resources for //examples/android/java/bazel:hello_world failed (Exit 1)
May 21, 2018 5:31:01 PM com.google.devtools.build.android.ResourceProcessorBusyBox main
SEVERE: java.io.IOException: Is a directory
Target //examples/android/java/bazel:hello_world failed to build
```
instead of just:
```
ERROR: /usr/local/google/home/jingwen/code/android_scratch_project/examples/android/java/bazel/BUILD:16:1: Processing Android resources for //examples/android/java/bazel:hello_world failed (Exit 1)
Target //examples/android/java/bazel:hello_world failed to build
```
RELNOTES: None.
PiperOrigin-RevId: 197493881
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is still a WIP, please do not approve/merge.
Adding tests to see an expected failure for aapt2 on presubmit.
See #5214 for details.