In this second post, I will create a new workflow for master branch, so we can send a debug apk artifact to GitHub and use it for internal testing.
If you are looking for an introduction to GitHub Actions and the first example of this series of publications here is the link.
Create workflow file
Create the file
.github/workflows/android-master.yml with the following content:
name: Android Master Branch CI on: push: branches: - 'master' jobs: test: name: Run Unit Tests runs-on: ubuntu-18.04 steps: - uses: actions/checkout@v1 - name: set up JDK 1.8 uses: actions/setup-java@v1 with: java-version: 1.8 - name: Unit tests run: bash ./gradlew test --stacktrace apk: name: Generate APK runs-on: ubuntu-18.04 steps: - uses: actions/checkout@v1 - name: set up JDK 1.8 uses: actions/setup-java@v1 with: java-version: 1.8 - name: Build debug APK run: bash ./gradlew assembleDebug --stacktrace - name: Upload APK uses: actions/upload-artifact@v1 with: name: app path: app/build/outputs/apk/debug/app-debug.apk
Understanding the workflow
name: Android Master Branch CI
The firts part is the name of the workflow.
on: push: branches: - 'master'
In this section, we can define over which branch and event this workflow will be executed. For this example, the workflow will be executed on master branch for push event, what means when a pull request is merged to master.
Then, moving forward to
jobs section you can see that it has two of them. First,
test, is the same as in previous example, so I will skip explanation.
apk, is a new one and its main purpose is to build an Android application into APK, so it can be installed on mobile device.
As in the first job, we define the
name and on which virtual machine this job should ran (
apk: name: Generate APK runs-on: ubuntu-18.04
Then there are the steps. First two are the same as in
test job, we allow workflow to access files in the repository and set JDK version.
A third job is a new one, but similar to the last from
test. This time we are not running the
test Gradle task, but
assembleDebug which will result with built Android APK file.
- name: Build debug APK run: bash ./gradlew assembleDebug --stacktrace
The last step ensures that the built APK file will be persisted(not removed) after workflow finishes. In the
with element we indicate which file(in path) should be saved. GitHub calls such persisted files artifacts.
- name: Upload APK uses: actions/upload-artifact@v1 with: name: app path: app/build/outputs/apk/debug/app-debug.apk
After this explanation, we are ready. The only missing thing is to create a branch, pull request and merge it, so the workflow can be triggered since the event is a push over master.
One important thing to see is that both jobs are running at the same time, in future posts I will explain how to chain jobs using
needs, so the result of one job can be used as an input or requirement of another job.
After a couple of minutes, we got a success result in both jobs. In addition, artifact apk file can be downloaded, an icon will show up right above the workflow console log.
In this part, I introduce a couple of new concepts and actions that can be used as steps, such as
actions/upload-artifact@v1 for example. In the next post I will integrate Firebase App Distribution in order to generate APK and send it to tester groups as soon as a pull request is merged, so internal testing can be done.