Circle CI + Android configuration tips

-

8 ideas to improve your Circle CI configuration on android projects

1. Define executors for each resource class

Sometimes you need to quickly change the resource class you use on your job’s executor. For example, you could need to do that to measure the performance impact or because you need more memory/CPU.

You can simplify those changes by defining one executor per resource class. Each executor could have for example custom GRADLE_OPTS defined.

references:
  android_config: &android_config
    working_directory: "/path"
    docker:
      - image: circleci/android:api-30
executors:
  android_executor_small:
    <<: *android_config
    resource_class: small
    GRADLE_OPTS: -Dorg.gradle.jvmargs="-Xmx2g -XX:MaxPermSize=2g"
  android_executor_medium:
    <<: *android_config
    resource_class: medium
    GRADLE_OPTS: -Dorg.gradle.jvmargs="-Xmx4g -XX:MaxPermSize=4g"
  android_executor_medium_plus:
    <<: *android_config
    resource_class: medium+
    GRADLE_OPTS: -Dorg.gradle.jvmargs="-Xmx6g -XX:MaxPermSize=6g"

2. Unify Gradle user home path between different docker images

Not all the docker images use the same default user home path. Then, the Gradle user's home path can change between jobs. This can cause problems when saving/restoring caches on jobs with different home paths.

Some docker images allow you to override the Gradle user's home path.

parameters:
  home:
    type: string
    default: /home/circleci
executors:
  basic_executor:
    working_directory: << pipeline.parameters.home >>/project
    resource_class: small
    docker:
      - image: cimg/base:stable
    environment:
      GRADLE_USER_HOME: << pipeline.parameters.home >>/.gradle

3. Cache versioning

Versioning each cache key could be useful in certain situations:

  • If you need to clean up your cache, you can easily do that by just incrementing the cache key version number.
  • If you need to change the cache content to something not backward compatible with the previous one, you can increment the cache key version number and avoid conflicts.
parameters:
  cacheKey:
    type: string
    default: v1-cache
...
- save_cache:
    key: << pipeline.parameters.cacheKey >>
    paths:
      - /path
- restore_cache:
    keys:
      - << pipeline.parameters.cacheKey >>

4. Job caches instead of attach to workspace

You can have only one workspace per workflow to persist your files. If you have multiple big files persisted by different jobs, the attach_workspace step could take time. Sometimes a job doesn’t need to attach all the files on the workspace.

To solve that problem, you can use multiple caches instead of the workspace. You just need to use the pipeline & workflow ids as part of the cache key.

parameters:
  jobCacheKey:
    type: string
    default: v1-jobcache
commands:
  save_job_cache:
    parameters:
      key:
        type: string
        default: ""
      path:
        type: string
        default: ""
    steps:
      - save_cache:
          key: << pipeline.parameters.jobCacheKey >>-<< parameters.key >>-<< pipeline.id >>-{{ .Environment.CIRCLE_WORKFLOW_ID }}
          paths:
            - << parameters.path >>
  restore_job_cache:
    parameters:
      key:
        type: string
        default: ""
    steps:
      - restore_cache:
          keys:
            - << pipeline.parameters.jobCacheKey >>-<< parameters.key >>-<< pipeline.id >>-{{ .Environment.CIRCLE_WORKFLOW_ID }}
            - << pipeline.parameters.jobCacheKey >>-<< parameters.key >>-<< pipeline.id >>

5. Store Junit Tests results

CircleCI collects test metadata from XML files and uses it to provide insights into your job.

Tests summary on CircleCI

To achieve that you just need to run the store_test_results step to upload the XML files after executing your Junit tests.

- run:
   name: Save test results
   command: |
     mkdir -p ~/test-results/junit/
     find . -type f -regex ".*/build/test-results/.*xml" -exec cp {} ~/test-results/junit/ \;
   when: always
- store_test_results:
    path: ~/test-results

6. Store Firebase Test Lab results

You can also see the Firebase Test Lab Tests summary in the same way you can see Junit Tests.

You will need to send the results-dir flag to the gcloud command, so the Firebase Test Lab device can store the XML with the test results on that directory.

Then you can download the XML with the results of the tests, using the gsutil command.

- run:
    name: Run Instrumentation tests
    command: |
      resultsDir="$(date -u +%F_%T.%3N)_app"
      mkdir -p "app/build/testlab"
      echo "${resultsDir}" >> app/build/testlab/resultsDir.txt

      gcloud firebase test android run 
        ... // YOUR SPECIFIC FLAGS HERE
        --results-dir=${resultsDir}
- run:
    name: Download test XML results
    command: |
      resultsDir=$(cat app/build/testlab/resultsDir.txt)
      gsutil cp gs://${BUCKET_NAME}/${resultsDir}/**/test_result_1.xml app/build/testlab
    when: always
- store_test_results:
    path: app/build/testlab

7. Switch to Gradle Binary Distribution

In your development environment, you would like to use the -all Gradle distribution on your gradle-wrapper.properties file, so your IDE has code-completion enabled and you can navigate to the Gradle source code.

But using -all increases your Gradle download times. So, using -bin in Circle CI is a better idea, because you don’t need the Gradle sources there.

The following step switches to Gradle Binary Distribution. It should be executed after the checkout step and before any Gradle execution.

- checkout
- run:
    name: Switch to Gradle Binary Distribution
    command: sed -i -e 's/-all.zip/-bin.zip/' gradle/wrapper/gradle-wrapper.properties

8. Verify the integrity of the Gradle Wrapper JAR

The Wrapper JAR is a binary file that will be executed on the computers of developers and build servers. As with all such files, you should be sure that it’s trustworthy before executing it. Since the Wrapper JAR is usually checked into a project’s version control system, there is the potential for a malicious actor to replace the original JAR with a modified one by submitting a pull request that seemingly only upgrades the Gradle version. Here you can find more official information about this topic.

The following step verifies the checksum of the Wrapper JAR to ensure that it has not been tampered. You should execute it on each workflow.

- run:
    name: Verify the integrity of the Gradle Wrapper JAR
    command: |
      cd gradle/wrapper
      gradleVersion=$(grep "distributionUrl" gradle-wrapper.properties | grep -Po "(\d+\.)+\d+")
      curl --location --output gradle-wrapper.jar.sha256 https://services.gradle.org/distributions/gradle-${gradleVersion}-wrapper.jar.sha256
      echo "  gradle-wrapper.jar" >> gradle-wrapper.jar.sha256
      sha256sum --check gradle-wrapper.jar.sha256

Comments

Post a Comment

Popular Posts

Versioning Android apps

-
Image
If you need to improve the versioning scheme of your android app, then you are reading the right story. Let’s discover together some good practices and their advantages. Semantic Versioning There is something in the software world called Semantic Versioning . It consists of a couple of conventions to assign version numbers to your software. You can (or maybe should) read all the details here . Basically, the idea is the following: Given a version number MAJOR.MINOR.PATCH, increment the:  MAJOR version when you make incompatible API changes,  MINOR version when you add functionality in a backwards-compatible manner, and  PATCH version when you make backwards-compatible bug fixes. As you can see, according to the previous definition, the MAJOR version on an android app doesn't make sense unless you have any kind of API to be consumed by other clients. If that’s the case, then you can use the pure Semantic Versioning definition. If not, you need to define when you should increment th
Read more

Say bye-bye to Android Jetifier

-
Image
6 steps to stop using Jetifier and increase your build speed Jetpack is a set of libraries, tools, and guidance to help you write high-quality apps more easily. Jetpack makes coding easier through best practices, limiting boilerplate code, and simplifying complex tasks. All with the goal of enabling you to focus on the code that you really care about. AndroidX is the package name for all the libraries within Jetpack. Think of AndroidX as the open-source project used to develop, test, version, and release Jetpack libraries. Back at I/O 2018, Google announced that Support Library would be refactored into the AndroidX namespace, which was completed with Support Library 28 and the announcement of AndroidX 1.0. Jetifier helps migrate third-party dependencies to use AndroidX. Jetifier will change the byte code of those dependencies to make them compatible with projects using AndroidX. Having Jetifier enabled on your project ( android.enableJetifier = true on your gradle.properties ) impa
Read more

Stop generating the BuildConfig on your Android modules

-
Image
This article will explain why I believe that generating the BuildConfig class for Android library modules is a bad idea. It’s important to highlight that I am not talking about the app module BuildConfig , I am talking about all the other BuildConfig files generated by each android module. First of all, I would like to clarify some terms, so you better understand this article: when I say debug code, I am talking about the code available on the local builds used by developers when they pick the debug variant. It is typically located at src/main & src/debug source sets. when I say release code, I am talking about the code distributed on your release APK/AAB. It means the release variant. It is typically located at src/main & src/release source sets. The Reasons These are the main reasons to disable BuildConfig.java generation: Generating the BuildConfig file for each module has a build speed penalty BuildConfig is generated as a Java file. But having a module with mi
Read more