In this article, we’ll explore some hidden features of Codemagic that can help you boost your productivity in building and releasing mobile apps.
Written by Chris Raastad
Magic actions
Codemagic Magic Actions are a unique way to save build minutes when performing App Store Connect post-processing actions. When uploading a build artifact to App Store Connect, there is a “Processing” state in TestFlight where Apple runs various security and compliance checks on your build. This can last from 30 seconds to 30 minutes or even more than an hour! In order to automate some operations, like uploading release notes or promoting a build to TestFlight beta, your CI/CD must wait for this processing state to complete. In all other CI/CD services, this wait time consumes precious build minutes, yikes!
Enter Magic Actions. Whenever an operation needs to run after the build is processed in TestFlight, Codemagic will detect this, and complete a build once the artifact is successfully uploaded. When the build is finished processing in App Store Connect, Codemagic will automatically perform the operation. It’s magic! Best of all, the wait consumes no build minutes. Take advantage of Magic Actions by uploading release notes to any Workflow Editor or codemagic.yaml workflow.
Linux build machines
Linux build machines allow you to supercharge your builds with the world’s most popular infrastructure operating system. Why Linux? As you may know, iOS requires you to build on a macOS machine, which is not designed for automation and CI/CD. With Linux machines, you can have a big boost in build speed for non-Apple platforms, particularly Android, in which we’ve seen up to 50% reduction in build time. You can also build Linux desktop and web. You can even build your non-mobile workflows with Codemagic, which our team uses internally for all of our infrastructure CI/CD.
Linux build machines are a paid feature that you will need to activate by enabling billing. Because of the availability of Linux infrastructure, the price per build minute is less than half of macOS build machines. To use Linux build machines, select Linux Standard or Premium VM in the Flutter workflow editor or specify the linux or linux_x2 instance type in your codemagic.yaml file.
Scheduled builds
Scheduled builds are a team feature allowing you to do just as the name says, schedule a build to run on a fixed schedule independent of any of the typical build triggers. You can configure the day(s) of the week and the time in UTC to run a build for a particular branch or workflow for both Flutter workflow editor or codemagic.yaml.
Why would you want this?
We found that many teams often run a weekly or nightly build to run a CI/CD job that doesn’t need to run on every commit or new pull request. For example, you could schedule a nightly build to run a lengthy integration test suite that might be too time-consuming to run for every commit. Or you could schedule a weekly build to automatically build and upload a new app version to TestFlight so your QA can have a fresh version in their inbox first thing Monday morning.
Log into your application build settings and check them out!
Gitflow Support with Git Branch and Tag patterns
Gitflow is a popular Git workflow used by mobile app development teams because it is designed around fixed release versions, which is exactly how mobile apps are released to users via the app stores. If your team is using Gitflow, Codemagic offers a convenient way to trigger builds by matching branch or tag names. This is useful for triggering builds that run a test suite when commits are pushed to specific branches, such as development or release, or for running a release build deploying to TestFlight when a tag is created for a new app release version.
The following example shows the Build Triggers configuration for a Flutter Workflow Editor workflow. Builds will be triggered for commits pushed to any branch starting with hotfix- and not for any branch starting with docs-. A build will be triggered for any commit where a tag is created starting with release-.
Check out the docs for how to configure build triggers with codemagic.yaml.
Monorepo Support with Conditional Build Triggers
Conditional build triggers allow you to take full control over which changes in which directories in your app’s repository will or will not trigger codemagic.yaml builds.
Why is this useful?
- If you have a monorepo, you can configure your workflows to only build when changes occur in a particular directory. This yaml sample will trigger builds for commits pushed to the repo with changes in the
org/team/my_appdirectory.
workflows:
build-my-app:
name: Build My App
triggering:
events:
- push
when:
changeset:
includes:
- 'org/team/my_app'
- If you have separate workflows for Android and iOS in the same repository, (i.e. for Flutter or React Native), you can configure the Android builds to run only for changes in the
android/directory and iOS build to run only for changes in theiOS/directory. This yaml sample will only trigger builds for commits pushed to the repo with changes in theandroid/directory.
workflows:
build-android:
name: Build Android
triggering:
events:
- push
when:
changeset:
includes:
- 'android/'
- You can exclude changes to trivial files, such as all files ending in
.mdor aREADME.mdfile, from triggering builds, saving you build minutes. This yaml sample will trigger a build for commits pushed to the repo with changes in the repo root directory except if the only files changed ended in.md.
workflows:
build-app:
name: Build App
triggering:
events:
- push
when:
changeset:
includes:
- '.'
excludes:
- '**/*.md'
- You can execute or skip specific build steps depending on changes of a certain file or directory. This yaml sample will only execute the “Build Android” build step when commits are pushed to the repo with changes in the
android/directory but not if the only files that changed ended in.md.
workflows:
build-android:
name: Build All
scripts:
- name: Build Android
script: ./gradlew assembleDebug
when:
changeset:
includes:
- 'android/'
excludes:
- '**/*.md'
Try out conditional build triggers and steps in your codemagic.yaml workflows to optimize your builds!
Global Environment Variables
With global environment variables you can manage all of your team’s codemagic.yaml secrets in one place! Gone are the days of encrypting each variable, pasting a long encryption string to a yaml file, and committing it to source control. You can now do everything in the Codemagic UI on the team settings page and remove duplication throughout all of your codemagic.yaml workflows.
Some key features of global variables and secrets:
Secure variables have a value hidden in logs and the Codemagic UI, which should definitely be used for any private keys or API tokens. Values not marked as secure are still stored securely in the Codemagic app, but the value will be visible to teammates in the logs and UI, which is helpful for values you want to see later, such as an app bundle ID or build flavor name.
A variable group defines a set of related variables imported together in a codemagic.yaml file. This means you can use variables in reusable scripts, but import different values for different groups with the same definition, for example, a “staging” and “production” variable group. You can read more about environment variable groups in the docs.
Application access allows you to define which various groups are usable in which of your teams’ applications, either all of them or some subset. This is useful if your organization needs fine control over variable visibility on a per-application basis.
Conclusion
We are always driving towards our users getting the best experience while using Codemagic CI/CD tool. Hopefully this article is helping you become even more productive. If you’re interested in further reading, then you might be interested in the following articles:
