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.
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
This article contains Affiliate Links. If you purchase anything after clicking an affiliate link, I may receive some compensation.
If you want to learn Android, here you have some recommended books
Comments
Post a Comment