typelead/gradle-eta

build fails due to missing -PetaSendMetrics

joshsh opened this issue · 5 comments

I have created a gradle-eta build for my Haskell-based project so users don't have to install the Haskell Tool Stack; ideally, they just type ./gradlew run and a JVM build commences. However, new users are running into the following build failure:

Would you like to help us make Eta the fastest growing programming language,
and help pure functional programming become mainstream? (y/n)

Please re-run this command with:
 * `-PetaSendMetrics=true` for yes
 * `-PetaSendMetrics=false` for no.

This only needs to be done once.
        at com.typelead.gradle.eta.tasks.EtaSetupEnvironment.ensureTelemetryPreferencesAndUpdate(EtaSetupEnvironment.java:259)
        at com.typelead.gradle.eta.tasks.EtaSetupEnvironment.setupEnvironment(EtaSetupEnvironment.java:125)
        at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:46)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:39)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:26)
        at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:794)
        at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:761)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$1.run(ExecuteActionsTaskExecuter.java:124)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:317)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:309)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:185)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:97)
        at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:113)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:95)
        ... 29 more

I realize that users just need to run ./gradlew run -PetaSendMetrics=true or ./gradlew run -PetaSendMetrics=false once to get around the issue, but this is not immediately obvious. The best I can do is hard-code -PetaSendMetrics=false into a script.

Is it possible to default to not sending metrics, but include an info message that invites users to use -PetaSendMetrics=true on a subsequent run?

Note: this has also become a minor problem for templated, automated builds, where we have a fresh checkout on every execution, and expect to be able to simply ./gradlew clean release. Instead, the build job has to be customized to use -PetaSendMetrics=false (as the build does not succeed otherwise, and because the sending of metrics may be seen as a security concern).

@joshsh For your first post, maybe you can specify in your docs that users installing Eta for the first time should run using that extra flag?

For your second post: You can customize your build.gradle so that is checks the environment variables to detect whether it's running in CI, and if so, default to etaSendMetrics = false. Note that the etaSendMetrics = false is a valid command in the build.gradle file as well. The -P flag is just another way to do it without hardcoding it into the file.

I solved this problem by adding ext.etaSendMetrics = 'false' to my build.gradle file.
The plugin expects a String value. I got an error without the quotation marks.

@joshsh I gave this some thought and realized the main problem here is that this is treated as a build failure w/ an exception which gives a confusing message. Would it help instead if it just printed the message without so much noise?

@arminha I've filed #41 to account for your observation about string vs boolean.