Streetcomplete: F-Droid Gradle config

[michaelblyons]

The F-Droid build for v25.1 is failing, and although the _current_ message is like #2118 (could not bring up vm 'builder_default'), there are indications in the build history that the VM did come up sometimes, but the build failed with some kind of Gradle signing problem.

If it's a problem on F-Droid's end, feel free to comment and close. But if it's on SC's end, I don't think the build will ever complete; you'll just go back and forth between the signing error and the VM unable to rouse.

Error message reproduced below:

== Installed Android Tools ==

2020-10-28 11:38:11,094 INFO: Creating log directory
2020-10-28 11:38:11,094 INFO: Creating temporary directory
2020-10-28 11:38:11,094 INFO: Creating output directory
2020-10-28 11:38:14,476 INFO: Using git version 2.11.0
2020-10-28 11:38:14,476 INFO: Building version 25.1 (2501) of de.westnordost.streetcomplete
2020-10-28 11:38:17,911 INFO: Getting source for revision v25.1
2020-10-28 11:38:20,669 INFO: Creating local.properties file at build/de.westnordost.streetcomplete/local.properties
2020-10-28 11:38:20,670 INFO: Creating local.properties file at build/de.westnordost.streetcomplete/app/local.properties
2020-10-28 11:38:20,691 INFO: Cleaned build.gradle.kts of keysigning configs at build/de.westnordost.streetcomplete/app/build.gradle.kts
2020-10-28 11:38:20,711 INFO: Cleaning Gradle project...
2020-10-28 11:39:41,112 ERROR: Could not build app de.westnordost.streetcomplete: Error cleaning de.westnordost.streetcomplete:25.1
==== detail begin ====
Found 6.6 via distributionUrl
Downloading missing gradle version 6.6
/home/vagrant/.cache/fdroidserver/gradle-6.6-bin.zip: OK
Running /opt/gradle/versions/6.6/bin/gradle clean

Welcome to Gradle 6.6!

Here are the highlights of this release:
 - Experimental build configuration caching
 - Built-in conventions for handling credentials
 - Java compilation supports --release flag

For more details see https://docs.gradle.org/6.6/release-notes.html

To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: https://docs.gradle.org/6.6/userguide/gradle_daemon.html.
Daemon will be stopped at the end of the build stopping after processing

> Task :buildSrc:compileKotlin
The `kotlin-dsl` plugin applied to project ':buildSrc' enables experimental Kotlin compiler features. For more information see https://docs.gradle.org/6.6/userguide/kotlin_dsl.html#sec:kotlin-dsl_plugin
w: /home/vagrant/build/de.westnordost.streetcomplete/buildSrc/src/main/java/GenerateMetadataByCountry.kt: (39, 59): Unchecked cast: Any! to Map<String, Any>
w: /home/vagrant/build/de.westnordost.streetcomplete/buildSrc/src/main/java/UpdatePresetsTask.kt: (50, 83): Unchecked cast: Any to JsonArray<JsonObject>

> Task :buildSrc:compileJava NO-SOURCE
> Task :buildSrc:compileGroovy NO-SOURCE
> Task :buildSrc:pluginDescriptors
> Task :buildSrc:processResources NO-SOURCE
> Task :buildSrc:classes UP-TO-DATE
> Task :buildSrc:inspectClassesForKotlinIC

> Task :buildSrc:jar
:jar: No valid plugin descriptors were found in META-INF/gradle-plugins

> Task :buildSrc:assemble
> Task :buildSrc:compileTestKotlin NO-SOURCE
> Task :buildSrc:pluginUnderTestMetadata
> Task :buildSrc:compileTestJava NO-SOURCE
> Task :buildSrc:compileTestGroovy NO-SOURCE
> Task :buildSrc:processTestResources NO-SOURCE
> Task :buildSrc:testClasses UP-TO-DATE
> Task :buildSrc:test NO-SOURCE
> Task :buildSrc:validatePlugins
> Task :buildSrc:check
> Task :buildSrc:build

> Configure project :app
e: /home/vagrant/build/de.westnordost.streetcomplete/app/build.gradle.kts:65:5: Unresolved reference: releaseSigningConfig
e: /home/vagrant/build/de.westnordost.streetcomplete/app/build.gradle.kts:66:5: Unresolved reference: releaseSigningConfig
e: /home/vagrant/build/de.westnordost.streetcomplete/app/build.gradle.kts:67:5: Unresolved reference: releaseSigningConfig
e: /home/vagrant/build/de.westnordost.streetcomplete/app/build.gradle.kts:68:5: Unresolved reference: releaseSigningConfig

FAILURE: Build failed with an exception.

* Where:
Build file '/home/vagrant/build/de.westnordost.streetcomplete/app/build.gradle.kts' line: 65

* What went wrong:
Script compilation errors:

  Line 65:     releaseSigningConfig.storeFile = file(props.getProperty("storeFile"))
               ^ Unresolved reference: releaseSigningConfig

  Line 66:     releaseSigningConfig.storePassword = props.getProperty("storePassword")
               ^ Unresolved reference: releaseSigningConfig

  Line 67:     releaseSigningConfig.keyAlias = props.getProperty("keyAlias")
               ^ Unresolved reference: releaseSigningConfig

  Line 68:     releaseSigningConfig.keyPassword = props.getProperty("keyPassword")
               ^ Unresolved reference: releaseSigningConfig

4 errors

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 1m 17s
==== detail end ====

[westnordost]

Yes, signing problems are F-Droid's problem

[michaelblyons]

Created issue #841 in GitLab.

[matkoniecz]

now at https://gitlab.com/fdroid/fdroiddata/-/issues/2205

[Bubu]

Yes, signing problems are F-Droid's problem

@westnordost yes and no. Fdroid expects to build an unsigned apk. For this all signing stuff is stripped from gradle files, which usually works in 99% of cases.

Not sure exactly what is going wrong here but it can either be fixed here or patched in the fdroid build recipe.

[smichel17]

Is it a result of switching to a kotlin gradle script? (fa4405e66e0125c91f7539a88d363ad8554e047f)

edit: shouldn't be, from a quick skim of https://gitlab.com/fdroid/fdroidserver/-/issues/613

edit2: also 24.1 was successfully built using the kts script. Continuing to dig.

[smichel17]

The particular lines which are causing an issue have not been updated since the last successful build, and none of the lines which have changed look like they should affect this.

[Strubbl]

@Bubu writes at gitlab:

This is something that needs to be fixed in the streetcomplete build recipe.
Builds need to produce an unsigned apk, which f-droid will sign separately afterwards.

so we have a Chicken or the egg problem here?

[matkoniecz]

Yes, signing problems are F-Droid's problem

@westnordost yes and no. Fdroid expects to build an unsigned apk. For this all signing stuff is stripped from gradle files, which usually works in 99% of cases.

If F-Droid expectation mismatch what SC is doing and there is no clear info what should be changed, then it is problem on F-Droid side. And it should be probably fixed in F-Droid signing stuff stripping step, not in SC build script - but I have no idea even about where code for that is located as it was not mentioned in error logs.

so we have a Chicken or the egg problem here?

no, if F-droid is unable to deal with something due to their unique build system it is possible to

• have F-droid maintaining patch applying change to SC (some apps have quite significant patches applied to them, not sure how exactly it is done)
• F-droid maintainers (or someone else) can submit a pull request to SC changing build script in way that helps F-droid without harming StreetComplete (no idea at all what exactly should be done to make F-droid happy)
• F-droid maintainers (or someone else) can explain what and how is causing problems by improving and/or linking F-Droid docs (F-droid build infrastructure is full of mysteriously failing builds happening without any explanation - not sure is it caused by underfunded infrastructure[0] or by bugs in F-Droid build system or by something else)

[0] In such cases error message really should include a donation request

[michaelblyons]

Build succeeded! I don't fully understand the commit that fixed it, but my interpretation is that someone else's package may have been making global Gradle changes.

[Bubu]

On November 1, 2020 12:58:08 AM GMT+01:00, Michael [e-mail] wrote:

Build succeeded! I don't fully understand the commit that fixed it, but my interpretation is that someone else's package may have been making global Gradle changes.

That wasn't really the commit that fixed it. (It's probably one earlier.)