Emerge receives builds created by your CI pipeline, along with additional metadata about where the build was generated. There are two kinds of uploads that are required: base builds and branch builds.
Configuring automatic uploads from CI requires 2 steps, commonly done in two separate pull requests:
- A first PR to configure uploading a base build (usually the default branch, e.g.
master). This will upload a base build upon merging this first PR, which future pull requests will use as the base to create a diff from!
- A second PR to configure uploading branch builds. Uploading branch builds is most commonly done from CI that is run on each pull request. This will create a diff against builds uploaded from your base branch, which we set up in step 1.
These are builds of your base branch, which will usually be the default branch, e.g.
master. For the integration to work, a build needs to be built from every commit pushed to the base branch. These fields are supported:
|Yes (should always be the name of your base branch)|
|No (defaults to |
These are builds originating from an open pull request. Once base builds are being sent to Emerge, you can add branch build uploads to get your first PR breakdown. These fields are supported:
|No (defaults to |
A base SHA must be included with branch builds, this ensures the correct build is used when generating your comparison.
buildType is an optional parameter that defaults to
release if not provided when uploading.
buildType is used to separate different types of uploads that might not be intended to be grouped together. Specifying a
buildType allows for viewing the dashboard pertaining to just builds matching the selected
As an example, let's say you want to track size changes for a specific APK you ship for x86 device architectures, then another APK that is the default
release build type. You would upload two builds to Emerge, one with the
buildType set to the name of that type, say
x86, and the other build you don't specify
buildType. This would result in a single Emerge dashboard with a dropdown for
buildTypes, allowing you to see size trends only for each respective type.
baseSha parameters are used to provide Emerge information about the position of your build within your version control system structure.
sha field should be the commit SHA that your upload was built from. Essentially, it represents the HEAD position for the build, whether the build is on main or a branch.
baseSha field is used specifically for branch builds. This field represents point in your git tree that your branch was created from. In essence, the
baseSha allows Emerge to identify all the changes on a branch. The
baseSha should remain the same for all builds on a branch, at least until the branch is rebased.
baseSha values should correspond to what your Version Control System uses. Providing a shortened value will result in errors, preventing Emerge from interacting with your VCS.
Emerge supports the following artifacts uploaded for size analysis.
|Android App bundle||Android|
|Zipped APK(s) with proguard mappings|
Note: We require one APK (the primary APK if uploading multiple APKs) to be named
|Zipped AAB with optional test APK||Android|
Note: fastlane will zip artifacts by default if uploading through the Emerge fastlane plugin.
Emerge supports deobfuscating builds obfuscated with Dexguard. Depending on your Dexguard configuration, you might need to provide different mapping files with your Emerge upload. Contact your Emerge team representative for more details specific to your configuration.
Updated 3 months ago