Lets build some Pipelines.

https://unsplash.com/photos/9AxFJaNySB8

Welcome to the last article in the series on mastering CI/CD from scratch for android devs. If you haven’t read the first two article, I recommend starting there before continuing with this one.

Lets analyse this a GitHub Action, it consists of three jobs: build, test, and deploy. Each job is defined in a separate section, and each job has a set of steps that are executed in order. The build job runs the ./gradlew build command, which builds the Android app. The test job runs the ./gradlew test command, which runs the app’s tests. The deploy job runs the ./gradlew deploy command, which deploys the app to a specified target, such as an app store or a device.

Recalling what we learned in the last article , it is now easier to understand how GitHub Actions work. In this example, we are using both our own custom action and a marketplace action (actions/checkout@v2), and we are using simple Gradle commands to build and test our Android app. The main difference is that these actions are now running on GitHub, rather than on our local machine.

Once you have this basic workflow set up, you can add additional steps to automate other tasks. For example, you can use the upload-artifact action to upload the built APK file to your repository, so it can be downloaded and installed on a device for testing. Here is how that would look:

Lets explore something new

Github Secrets:

One of the key features of GitHub Actions is the ability to use secrets. Secrets are encrypted values that you can use to store sensitive information, such as API keys, passwords, and tokens. In this guide, we will show you how to add secrets to your repository on GitHub and how to use them in your workflow files.”

1. Navigate to the Settings tab of your repository on GitHub.

2. In the left menu, click on the “Secrets” option.

1. Click on the “actions” button and then the new repositpry secret button.

1. Enter the name and value of your secret in the appropriate fields.
2. Click on the “Add secret” button to save the secret.
3. Repeat steps 3–5 for each secret you want to add to your repository.
4. In your workflow file, use the following syntax to access the value of a secret:

${{ secrets.SECRET_NAME }}

8. Replace SECRET_NAME with the name of the secret you want to access.

9. Save the changes to your workflow file and push the changes to your repository.

By following these steps, you can add secrets to your repository on GitHub and use them in your workflow files. This will allow you to access sensitive information in your workflow files without exposing it in your code or your repository, which can improve the security of your app and your codebase. By using secrets in your workflow files, you can create complex and secure pipelines for your apps on GitHub.

Automating Firebase App Distribution:

#upload qa flavour  apk to firebase app tester using github actions
name: Firebase App Tester QA
on:
  push:
    branches:
      - "QA"
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-java@v1
        with:
          java-version: 11
      - uses: actions/cache@v2
        with:
          path: ~/.gradle/caches
          key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*') }}
          restore-keys: |
            ${{ runner.os }}-gradle-
      - name: Build QA Flavour APK
        run: ./gradlew assembleQaDebug
      - name: Upload QA Flavour APK to Firebase App Tester
        uses: wzieba/Firebase-Distribution-Github-Action@v1
        with:
          appId: ${{ secrets.QA_APP_ID }}
          serviceCredentialsFileContent: ${{ secrets.CREDENTIAL_FILE_CONTENT }}
          groups: qa-internal
          releaseNotes: ${{ github.event.head_commit.message }}
          file: app/build/outputs/apk/qa/debug/app-qa-debug.apk

This is action automates the process of building and uploading an Android app to Firebase App Distribution. It is triggered whenever a push is made to the QA branch.

The Action consists of a single build job, which runs on an ubuntu-latest virtual machine provided by GitHub. The build job has several steps.

1. The first step uses the actions/checkout action to check out the code from the repository. This allows the Action to access the code and build the app.

- uses: actions/checkout@v2

2. The second step uses the actions/setup-java action to set up Java on the virtual machine. This is necessary because the Android app is built using Gradle, which requires Java. The java-version key specifies the version of Java to install, which is set to 11 in this example.

- uses: actions/setup-java@v1
  with:
    java-version: 11

3. The third step uses the actions/cache action to cache the Gradle dependencies. This can improve the performance of the build by allowing Gradle to use the cached dependencies instead of downloading them from the internet. The path key specifies the location of the cache, and the key and restore-keys keys are used to identify the cache and restore it if necessary.

- uses: actions/cache@v2
  with:
    path: ~/.gradle/caches
    key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*') }}
    restore-keys: |
      ${{ runner.os }}-gradle-

4. The fourth step runs the ./gradlew assembleQaDebug command, which builds the QA flavor of the app. This step uses the Gradle wrapper script (./gradlew) to run the assembleQaDebug task, which compiles the app and generates the APK file.

- name: Build QA Flavour APK
  run: ./gradlew assembleQaDebug

you can use different gradle commands to satisfy your needs apk/aab or debug/release.

5. In the final step this GitHub Action uses the wzieba/Firebase-Distribution-Github-Action action to upload the APK to Firebase App Distribution. This action requires two secrets: QA_APP_ID and CREDENTIAL_FILE_CONTENT.

Note : a detailed step wise instructions available in first article of this series

The QA_APP_ID secret is the ID of the app in Firebase. You can find this in the Firebase console by going to the “General” section of the “Project settings” page.

The CREDENTIAL_FILE_CONTENT secret is the content of the JSON file that contains the service account credentials for the Firebase project. You can download this file from the Firebase console by going to the “Service accounts” section of the “Settings” page and clicking on the “Generate new private key” button.

To use these secrets in the Action, you need to add them to the repository’s secrets. You can do this by going to the “Settings” page of the repository and clicking on the “Secrets” tab. Then, click on the “Add a new secret” button and enter the name and value of the secret.

Once the secrets are added, you can use them in the Action by referencing them using the ${{ secrets.<SECRET_NAME> }} syntax. For example, ${{ secrets.QA_APP_ID }} refers to the QA_APP_ID secret.

The groups key specifies the group(s) that the app will be uploaded to. You can specify multiple groups by separating them with commas. For example, groups: testers,alpha,beta will upload the app to the testers, alpha, and beta groups.

The releaseNotes key specifies the release notes for the app. This can be a static string or a reference to a dynamic value. In this example, the release notes are taken from the commit message of the push event that triggered the Action.

The file key specifies the location of the APK file relative to the repository root. This is the file that will be uploaded to Fire

- name: Upload QA Flavour APK to Firebase App Tester
  uses: wzieba/Firebase-Distribution-Github-Action@v1
  with:
    appId: ${{ secrets.QA_APP_ID }}
    serviceCredentialsFileContent: ${{ secrets.CREDENTIAL_FILE_CONTENT }}
    groups: qa-internal
    releaseNotes: ${{ github.event.head_commit.message }}
    file: app/build/outputs/apk/qa/debug/app-qa-debug.apk

Another example:

name: Upload App Bundle to Play Store
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-java@v1
        with:
          java-version: 1.8
      - uses: actions/cache@v2
        with:
          path: ~/.gradle/caches
          key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*') }}
          restore-keys: |
            ${{ runner.os }}-gradle-
      - name: Build App Bundle
        run: ./gradlew bundleRelease
      - name: Upload App Bundle to Play Store
        uses: r0adkll/upload-google-play@v2
        with:
          package-name: com.example.app
          release-status: completed
          service-account-json: ${{ secrets.GOOGLE_PLAY_SERVICE_ACCOUNT }}
          track: production
          app-bundle: app/build/outputs/bundle/release/app-release.aab
          release-notes-file: release-notes.txt

This is a GitHub Action that automates the process of building an Android app bundle and uploading it to the Google Play Store. It is triggered whenever a push is made to any branch in the repository.After discussing the previous action in depth I hope this is fairly understandable.

In conclusion, GitHub Actions is a powerful tool for automating processes in Android development. With its rich ecosystem of Marketplace actions, you can easily build complex workflows without having to write any code.

However, to make the most of GitHub Actions, it is important to understand the basics of how it works and how to use Marketplace actions. With this knowledge, you can quickly and easily create custom workflows to automate various tasks in your Android development process, such as building, testing, and deploying your app.

Overall, GitHub Actions is a valuable resource for Android developers looking to improve their workflow and make their development process more efficient and streamlined.

To stay updated on my latest posts and insights, follow me on LinkedIn and Twitter. I look forward to connecting with you!!

https://www.linkedin.com/in/kashif-mehmood-km

If you found this article helpful and would like to support my work, you can buy me a coffee by clicking on the button below. Thank you for your support!

Happy Coding ❤ ❤ ❤

This article was originally published on proandroiddev.com on December 12, 2022