CI/CD with GitHub Actions helps you automatically build, test, and deliver your Android app. It saves time and reduces mistakes by doing these steps for you.
CI/CD with GitHub Actions in Android Kotlin
name: Android CI/CD
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Set up JDK 17
uses: actions/setup-java@v3
with:
distribution: 'temurin'
java-version: '17'
- name: Build with Gradle
run: ./gradlew build
- name: Run tests
run: ./gradlew testThe on section tells when the workflow runs, like on code changes.
The jobs section defines steps like building and testing your app.
on:
push:
branches: [ main ]jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3- name: Build with Gradle
run: ./gradlew assembleDebug- name: Run unit tests run: ./gradlew test
This GitHub Actions workflow runs when you push code to the main branch. It checks out your code, sets up Java 17, builds your Android app using Gradle, and runs tests.
name: Android CI/CD
on:
push:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Set up JDK 17
uses: actions/setup-java@v3
with:
distribution: 'temurin'
java-version: '17'
- name: Build with Gradle
run: ./gradlew build
- name: Run tests
run: ./gradlew testMake sure your Android project has a working gradlew script in the root folder.
You can add more steps to upload build files or notify your team.
Use the runs-on setting to choose the operating system for your build.
GitHub Actions automates building and testing your Android app.
Workflows run on code changes to keep your app healthy.
Simple YAML files define what steps to run and when.
Practice
Solution
Step 1: Understand GitHub Actions role
GitHub Actions automates tasks like building and testing when code changes.Step 2: Identify the main benefit
This automation helps keep the app healthy without manual work.Final Answer:
To automate building and testing the app on code changes -> Option AQuick Check:
Automation = building and testing [OK]
- Thinking it writes code automatically
- Confusing manual deployment with automation
- Assuming it edits app files directly
Solution
Step 1: Recall GitHub Actions syntax for runner
The correct key isruns-onwith a hyphen.Step 2: Match the correct option
runs-on: ubuntu-latest usesruns-on: ubuntu-latest, which is valid syntax.Final Answer:
runs-on: ubuntu-latest -> Option AQuick Check:
Key is runs-on with hyphen [OK]
- Using underscore instead of hyphen
- Using 'runs' or 'run-on' keys incorrectly
- Confusing key names with similar words
steps:
- name: Build Debug APK
run: ./gradlew assembleDebugWhat will this step do when the workflow runs?
Solution
Step 1: Understand the Gradle command
./gradlew assembleDebugbuilds the debug APK of the app.Step 2: Identify the step action
The step runs this command, so it builds the debug version.Final Answer:
It runs the Gradle command to build the debug version of the app -> Option DQuick Check:
assembleDebug = build debug APK [OK]
- Confusing assembleDebug with deploy commands
- Thinking it runs tests only
- Assuming it cleans the project
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Build APK
run: gradlew assembleDebugWhy might this workflow fail during the build step?
Solution
Step 1: Check the build command syntax
The Gradle wrapper command needs './gradlew' to run the local script.Step 2: Identify the error cause
Missing './' causes 'gradlew' not found error, failing the build step.Final Answer:
Because the command should be './gradlew assembleDebug' with './' prefix -> Option BQuick Check:
Use './gradlew' to run Gradle wrapper [OK]
- Omitting './' before gradlew
- Thinking action version is invalid
- Misnaming 'runs-on' key
- Assuming job names are restricted
Solution
Step 1: Understand GitHub Actions triggers
Thepathsfilter runs workflow only if matching files change.Step 2: Match trigger to Kotlin files
on: push: paths: - '**/*.kt' triggers on push when any.ktfile changes, which is correct.Final Answer:
on: push: paths: - '**/*.kt' -> Option CQuick Check:
Use 'paths' to trigger on specific file changes [OK]
- Using 'paths-ignore' instead of 'paths'
- Triggering on branch only, not file changes
- Using schedule trigger for file changes
Ready to prove it?
Pass the test and this pattern moves unknown
