Gradle plugin

[trevjonez]

Any plans for a gradle plugin or would you be interested in discussing dsl design for one?

[artem-zinnatullin]

We don't have engineering resources to work on something we don't use ourselves right now, so it'll be great to follow same pattern Spoon and Spoon Gradle Plugin maintained separately by the community.

However we can participate in DSL design and refer to it from our README!

[trevjonez]

So initially my thought is that I would start by just creating a ComposerTask that would allow for not much more than just using gradle config rather than bash scripts to make your config declarative. This also means people can do only this amount of work if that is what they want.

task customTaskName(type: ComposerTask) {
  apk 'app/build/outputs/apk/example-debug.apk'
  test-apk 'build/outputs/apk/example-debug-androidTest.apk'
  test-package 'com.example.test'
  test-runner 'com.example.test.ExampleTestRunner'
  shard true
  output-directory 'artifacts/composer-output'
  instrumentation-arguments key1: 'value1', key2: 'value2'
  verbose-output false
}

From there I would like to see a plugin that hooks into the AGP in order to automatically create and configure instances of composer tasks.

apply plugin: 'composer'

composer {
  variants "redDebug" // optional, include task for each variant if none specified here
  instrumentation-arguments key1: 'value1', key2: 'value2'  //optional args that apply to all created tasks
  configs { //Named domain object container
    redDebug {
        apk 'app/build/outputs/apk/example-debug.apk' //optional override default inferred from AGP
        test-apk 'build/outputs/apk/example-debug-androidTest.apk' //optional override default inferred from AGP
        test-package 'com.example.test' //optional override default inferred from AGP
        test-runner 'com.example.test.ExampleTestRunner' //optional override default inferred from AGP
        shard true //optional
        output-directory 'artifacts/composer-output' //optional override default inferred from AGP
        instrumentation-arguments key1: 'value1', key2: 'value2'  //optional args. probably main/only use case for these config dsl blocks
        verbose-output false //optional
    }
  }
}

Task name created would be something like testRedDebugComposer
tasks created by the plugin can automatically depend on the appropriate apk assemble tasks as well.

more typical use case would look like:

apply plugin: 'composer'

composer {
  variants "redDebug"

  configs {
    redDebug {
        instrumentation-arguments key1: 'value1', key2: 'value2'
    }
  }
}

all around it should be a fairly simple project to put together since this repo has already done all the hard work.

[artem-zinnatullin]

Plan looks pretty solid!

One of the things that would be great to do is to map Composer options to the Gradle Plugin as close to their original names as possible, i.e. --output-directory → outputDirectory (unfortunately you can't use - in Groovy property name). You're already doing this in your example, but I just wanted to point that explicitly, because any changes in option names will create questions from users.

When/if you start the work, please leave a comment here with a link to the repo so we could follow progress, if you want you can add us: @yunikkk, @ming13 and me as code reviewers to the Pull Requests :)

[trevjonez]

good catch on the - copy paste ftw. Plan is to get the repo and plugin/test skeleton setup tonight. fingers crossed.

[trevjonez]

starting to layout some code now: https://github.com/trevjonez/composer-gradle-plugin

[trevjonez]

As I am finally getting some unit tests ran against my mavenLocal of #81 I am finding that you can not configure environment variables which is a limitation of the gradle test kit. Might I recommend/request allowing configuration of ANDROID_HOME as an optional CLI param?

[trevjonez]

Just published an initial pre-release.
https://github.com/trevjonez/composer-gradle-plugin
https://jitpack.io/#trevjonez/composer-gradle-plugin/0.1.0

[artem-zinnatullin]

Looks great! I like how you've organized the code and that it's not Groovy :)

Also great that you're adding Composer to project dependencies so it'll be cached properly by Gradle.

I guess we should start publishing non-fat jar for that btw? Currently Composer is shipped as fat jar with all dependencies bundled inside the jar for cli invocations.

[trevjonez]

You might do a different distribution so that gradle can do its magic like you are saying, but it would be nothing more than a cache optimization. If you go that route that is where you might considering making this project more library like with an extra wrapper that exposes it as a command line app?

I already integrated the plugin into my work project which revealed a few bumps. After taking care of those I am already on 0.1.2 but smooth sailing after those changes were made.

My consumption of composer for that project is now reduced to basically

apply plugin: 'composer'
composer {
  instrumentationArgument('notAnnotation', 'com.xxx.yyy.ScreenshotTest')
}

and I can just invoke ./gradlew app:testCiDebugComposer to run my suite of non screenshotTests.

Then I created a custom ComposerTask that I redirected my config for screenshotTests to use. That way I can add in the instrumentationArgument('annotation', 'com.xxx.yyy.ScreenshotTest') as appropriate.

At some point I want to create a new system for screenshot tests. that facebook lib works but has some seriously rough edges and is basically unmaintained. Not to mention it looks like it was written by a non android/java person for android people to use. smells like a
summer intern project imo. anyway it will probably have some things modeled on what you have done with this project and the gojuno dependencies