tags >= 2022.03.1 breaks `gradlew` on android-machine

[rynkowsg]

The old image 2022.01.1 works just fine:

executor: { name: android/android-machine, resource-class: xlarge, tag: 2022.01.1 }

but when you update it to 2022.03.1 or 2022.04.1:

executor: { name: android/android-machine, resource-class: xlarge, tag: 2022.03.1 }

we get:

Error: Could not find or load main class org.gradle.wrapper.GradleWrapperMain
Caused by: java.lang.ClassNotFoundException: org.gradle.wrapper.GradleWrapperMain

Screenshot:

Sample job: https://app.circleci.com/pipelines/github/chargedupteam/servedup-android/917/workflows/1d0f543f-738a-463c-a9f8-5981a9fbff87/jobs/1566

[JalexChen]

hi @rynkowsg - i'm not able to replicate this issue using both the 2022.01.1 image vs the 2022.04.1 image on a sample android project and it seems to be working as intended. however, i believe the problem stems from the gradle wrapper not having been built, configured, or the .jar file isn't found before running ./gradlew. functionally, there haven't been any changes to the gradle install, or perhaps it might be a change due to versioning and i'll be looking into that a bit more.

A couple of things from looking at the configuration:

• can you confirm the directory you are working out of for the specified job contains the gradlew file?
• would you be able to try out gradle wrapper --gradle-version=7.4.2 to rebuild the wrapper before using ./gradlew?

[rynkowsg]

@JalexChen Ok, ok, so our project is a bit unusually configured. All non-text files we store using Git LFS, including the gradle's wrapper jar. The problem might be in my custom checkout, where I install Git LFS if it doesn't exist.

When I compared successful job on 2022.01.1 with failing job on 2022.03.1, it looks like on the failing the Git LFS exists, but it doesn't fetch LFS files on checkout as it used to do when git-lfs was installed.

It might be a bug in my checkout code. Possibly git-lfs needs to be initialized in the repo directory. I will have a look at it on Monday.

[rynkowsg]

It turned out that I needed to manually initialize LFS (git lfs install) and pull files (git lfs pull).

Previously, when I was installing git-lfs on my own, these steps were not necessary. Not sure where the change in behaviour comes from, still, it is nice that you provide it git-lfs by default now.

What would even nicer is if you added Git LFS support to your checkout command.

Thanks for the assistance. I'm closing the issue now.