Automating Build and Release Processes with GitHub Actions

Whether we’re coding solo or with a team, cutting down on repetitive tasks can make a big difference. That’s where GitHub Actions comes in.

GitHub Actions is a tool that helps automate tasks in our code repository. From running tests to deploying apps, it’s like having a virtual assistant for our coding projects.

In this article, I’ll show you how to use GitHub Actions to automate building and releasing a mobile app. By the end, we’ll know how to set up workflows that compile code, create release files, and update our app.

Let’s Start

First, create a .github directory followed by a workflows directory. Then create a main.yml file inside the directory like the image above. Then copy and paste the below actions inside the main.yml file.

on:
  pull_request:
    branches:
      - main
      - master
  push:
    branches:
      - main
      - master
name: "Build & Release"
jobs:
  build:
    name: Build & Release
    runs-on: macos-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions/setup-java@v1
        with:
          java-version: '12.x'
      - uses: subosito/flutter-action@v1
        with:
          flutter-version: '3.16.0'
      - run: flutter pub get
      - run: flutter build apk --release
      - run: |
          flutter build ios --no-codesign
          cd build/ios/iphoneos
          mkdir Payload
          cd Payload
          ln -s ../Runner.app
          cd ..
          zip -r app.ipa Payload
      - name: Push to Releases
        uses: ncipollo/release-action@v1
        with:
          artifacts: "build/app/outputs/apk/release/*,build/ios/iphoneos/app.ipa"
          tag: v1.0.${{ github.run_number }}
          token: ${{ secrets.TOKEN }}


# push to master, main
# pull request on main master

Explanation

Let’s break down the above actions step by step:

on:
  pull_request:
    branches:
      - main
      - master
  push:
    branches:
      - main
      - master

This section defines the triggers for the workflow. The workflow will run on pull requests targeting the `main` or `master` branches (you can put any other branches based on your preferences), as well as on pushes to the `main` or `master` branches.

name: "Build & Release"

This sets the name of the workflow to “Build & Release”.

jobs:
 build:
 name: Build & Release
 runs-on: macos-latest, ubuntu-latest, windows-latest

Defines a job named “build”. This job runs on macOS (`macos-latest`) and will handle the build and release process.

    steps:
      - uses: actions/checkout@v1

Checks out the repository’s code at the commit or pull request that triggered the workflow.

      - uses: actions/setup-java@v1
        with:
          java-version: '12.x'

Sets up Java with version 12.x.

      - uses: subosito/flutter-action@v1
        with:
          flutter-version: '3.16.0'

Sets up Flutter with version 3.16.0.

      - run: flutter pub get

Runs `flutter pub get` to fetch dependencies.

      - run: flutter build apk --release

Builds the Android APK file in release mode.

      - run: |
          flutter build ios --no-codesign
          cd build/ios/iphoneos
          mkdir Payload
          cd Payload
          ln -s ../Runner.app
          cd ..
          zip -r app.ipa Payload

Builds the iOS application and creates an IPA (iOS App Store Package) file. It’s doing some additional steps like creating necessary directories and symlinking Runner.app.

      - name: Push to Releases
        uses: ncipollo/release-action@v1
        with:
          artifacts: "build/app/outputs/apk/release/*,build/ios/iphoneos/app.ipa"
          tag: v1.0.${{ github.run_number }}
          token: ${{ secrets.TOKEN }}

This step pushes the built artifacts (APK and IPA files) to a release. It uses the `ncipollo/release-action` action to handle the release process. The `tag` parameter generates a tag based on the workflow’s run number. The token is fetched from GitHub secrets and presumably used for authentication to push the release.

Finally, the comments `# push to master, main` and `# pull request on the main and master` provide some additional context about when the workflow should run based on branch events.

Outcome

Open the GitHub repo where we have implemented the above actions.

click on the action item.

status: pending

Build & Release: It Is the job name in our main.yml file

testing and build: The action flow is named after the last commit message we have pushed to our repository.

After successfully building the action flow, the status will look like this (see image below).

Click on the action. You will be able to see a proper view of the action flow.

If we take a look at your repository, we will notice a release tag has been created with a version number (See image below)

v1.0.13 is the latest release for me.

The following screen appears if we click on the release tag or the version number.

And We are done.

You will find the project with the GitHub repo here.

Stackademic 🎓

Thank you for reading until the end. Before you go:

• Please consider clapping and following the writer! 👏
• Follow us X | LinkedIn | YouTube | Discord
• Visit our other platforms: In Plain English | CoFeed | Venture | Cubed
• Tired of blogging platforms that force you to deal with algorithmic content? Try Differ
• More content at Stackademic.com