Fixed
Status Update
Comments
cm...@google.com <cm...@google.com>
ga...@google.com <ga...@google.com>
hu...@google.com <hu...@google.com> #2
This was broken by 3bca759a5ff08352de831bb1e9b61b1ec2b3362d.
Fix (pending) is I2c2dc7b600603ee430fd0d91b23d52ea8aa29ca9.
Fix (pending) is I2c2dc7b600603ee430fd0d91b23d52ea8aa29ca9.
zs...@salesforce.com <zs...@salesforce.com> #3
Almost 2 months later and this is still broken
hu...@google.com <hu...@google.com> #4
Since there is no progression, I wanted to share our quick-fix for the issue.
#sdkmanager --package_file=${PATH_WORKSPACE}/packages
while read p; do echo "y" | sdkmanager "${p}"; done <${PATH_WORKSPACE}/packages
#sdkmanager --package_file=${PATH_WORKSPACE}/packages
while read p; do echo "y" | sdkmanager "${p}"; done <${PATH_WORKSPACE}/packages
ga...@google.com <ga...@google.com> #5
jb...@google.com What is the update on this?
hu...@google.com <hu...@google.com> #6
What is the status of this item?
za...@gmail.com <za...@gmail.com> #7
This has been fixed on master today (internal ref: ag/2945015) and will be available in the next SDK release.
hu...@google.com <hu...@google.com> #8
Any ETA on next release?
hu...@google.com <hu...@google.com> #9
Still broken and not updated? --package_file argument is not usable in it's current form on 26.1.1 straight from the developer site.
hu...@google.com <hu...@google.com> #10
Comfirmed that this seems to still be broken. Can we have an update please?
```
(15:58:11) C02W513SHTD8:files aso$ /opt/android-sdk-macosx/tools/bin/sdkmanager --version
26.1.1
(15:58:17) C02W513SHTD8:files aso$ /opt/android-sdk-macosx/tools/bin/sdkmanager --install --package_file=package_file
Warning: Unknown argument --package_file=package_file
```
```
(15:58:11) C02W513SHTD8:files aso$ /opt/android-sdk-macosx/tools/bin/sdkmanager --version
26.1.1
(15:58:17) C02W513SHTD8:files aso$ /opt/android-sdk-macosx/tools/bin/sdkmanager --install --package_file=package_file
Warning: Unknown argument --package_file=package_file
```
Description
DESCRIBE THE ISSUE IN DETAIL:
It appears that the
MergeFilesTask
has non-deterministic outputs, as it does not sort the files before merging their contents. This affects proguard file merging and baseline profile merging.STEPS TO REPRODUCE:
I noticed this while investigating some remote build cache fidelity issues. I see lint analysis tasks on consecutive builds across different machines result in cache misses despite being identical, and build scan comparisons reveal it's because library merged proguard rule contents are the same. I'm trying to confirm that this is due to inconsistent file ordering when merging via monkeypatch in our internal plugin.