Drop the foojay toolchain resolver so F-Droid can build - #29
Merged
Merged
Conversation
The draft ran ./gradlew itself from a build: command. That cannot work: F-Droid deletes gradle-wrapper.jar before building, since a binary blob in the source tree is exactly what it will not run, and the command also ran from app/ where gradlew is not. Uses the gradle: field so fdroidserver runs assembleRelease with its own Gradle, and gradleprops to pass VERSION_NAME. Targets v1.0.5, since v1.0.4 predates the foojay removal and its scanner error.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
The finding
Ran Hazel through F-Droid's own tooling (
fdroidserver2.4.5, on WSL). The build scanner refuses the whole thing:foojay-resolver-conventionresolves a Java toolchain by downloading a JDK from the Foojay API partway through the build. F-Droid rejects that on sight, and reasonably: a build that fetches its own compiler from a third party is not one anyone else can reproduce.Nothing in this project requests a toolchain. No
jvmToolchain(...), noJavaLanguageVersion. Java level is set throughsourceCompatibilityandjvmTarget, which the plugin has no part in. It came from the Android Studio template and has never done anything here.Removed.
:app:compileReleaseKotlinstill configures and builds; after this change the scanner passes and the build proceeds to compiling.Also in here
The recipe draft ran
./gradlewitself from abuild:command. That cannot work on F-Droid: it deletesgradle-wrapper.jarbefore building (seen in the log:Removing gradle-wrapper.jar at gradle/wrapper/gradle-wrapper.jar), and the command runs fromapp/wheregradlewdoes not exist. It now usesgradle:so fdroidserver runsassembleReleasewith its own Gradle, andgradlepropsto passVERSION_NAME.The recipe's
Changelogalso moves from/blob/main/to/blob/HEAD/, which is whatfdroid lintasks for. Lint is now clean, exit 0.What this means for submission
The recipe targets v1.0.5, which does not exist yet.
v1.0.4cannot be submitted to F-Droid: it predates this fix, so their scanner would reject it. The tag has to be cut after this merges.v1.0.4on GitHub is unaffected and stays as it is. It is a working release, just not one F-Droid can build.Verified along the way
fdroid lint com.hazel.androidcleanconfig/categories.yml;Downloadis a valid category and the best fitHAZEL_SIGNING_DIRunsigned fallback never comes up on their builders