Closed licaon-kter closed 1 year ago
Tagged 1.7.16+106 for fdroid build
Why is this reverted? https://monitor.f-droid.org/builds/log/com.jithware.brethap/108#site-footer
Why is this reverted? https://monitor.f-droid.org/builds/log/com.jithware.brethap/108#site-footer
This change: https://github.com/jithware/brethap/pull/98/files
causes this error: https://gitlab.com/fdroid/fdroiddata/-/jobs/4171315412#L1270
This reversion: https://github.com/jithware/brethap/commit/e4633cb7b3efac5f5511b496ce8ab55ee1fec02f
lead to a succesful build: https://gitlab.com/jithware/fdroiddata/-/pipelines/848428435
This file https://gitlab.com/fdroid/fdroiddata/-/blob/master/metadata/com.jithware.brethap.yml
should look like: https://gitlab.com/jithware/fdroiddata/-/blob/62740be33895aad739139fafb2a2f26598e1b6b1/metadata/com.jithware.brethap.yml
I believe the issue is with the prebuild:
addition
Referencing https://f-droid.org/docs/Build_Metadata_Reference/#build_prebuild
Note that nothing should be built during this prebuild phase - scanning of the code and building of the source tarball, for example, take place after this. For custom actions that actually build things or produce binaries, use ‘build’ instead.
Ok, so when do you scan the deps if they get pulled only in build
and bypass the scanner after prebuild
?
Scans in the past occurred during the build job. An example scan detection occurred when I added wear os support to brethap. I had to create a separate fdroid branch for fdroid builds which removes gms. See https://github.com/jithware/brethap/issues/60
Those are at the end of a build, for the APK, and only in the Gitlab CI (for now).
It's not certain that all pulled autoupdates are built by the CI or that a contributor reaches the failed CI job and disables it in time.
Other Flutter apps can be scanned (https://gitlab.com/fdroid/fdroiddata/-/blob/master/metadata/de.jbservices.nc_passwords_app.yml#L151) and have a newer AGP (https://gitlab.com/joleaf/nc-passwords-app/-/merge_requests/110)
causes this error: https://gitlab.com/fdroid/fdroiddata/-/jobs/4171315412#L1270
Yes and no
That CI builds multiple apps, in the same VM, so if one installs Java 17 then all the other apps that follow it will get build with that...
Hence my bet is that your cause and effect line of thinking is wrong. :)
As 104 built just fine with the AGP changes: https://gitlab.com/fdroid/fdroiddata/-/blob/master/metadata/com.jithware.brethap.yml?ref_type=heads#L764 right: https://f-droid.org/packages/com.jithware.brethap/ ?
Ok got it.
It's actually my fault.
I myself forgot that "That CI builds multiple apps, in the same VM, so if one installs Java 17 then all the other apps that follow it will get build with that..."
Then again, since I have no domain knowledge, the error was unknown to me, and I've put the burden on you @jithware and I've confused you too.
Locally, I've build 106 now, and builds fine.
I've added Java17 afterwards, and it failed as the CI did.
So, please put back the AGP fix and we'll reenable 108 and carry on :)
108 builds fine too, hence: https://gitlab.com/fdroid/fdroiddata/-/commit/0ee46a0bf64af83d2fa22af87b2c4f35155f2bad
https://issuetracker.google.com/issues/184872412 This is an issue of AGP 4.1. Updating AGP to 4.2 or above should fix it.