Incorporating automatic app updates from GitLab

GitLab is a powerful system for continuous integration. Developers use GitLab to store, build, and test code. Organizations use GitLab to organize app development projects and deliver apps. The Blue Cedar Platform orchestrates workflows for post-development apps—adding no-code integrations, signing apps, publishing to distribution UEMs, and so on. Connecting GitLab to your Blue Cedar Platform workflows allows you to extend your CI/CD workflow—seamlessly move from the development and build processes on GitLab to providing updated app versions to the Blue Cedar workflows.

Here are the steps needed to set up the Blue Cedar Platform to import binaries from GitLab, detect if new app versions are available, and notify when a new version is updated and ready to upload.

How it works

Assumptions:

• You have access to a GitLab Community project (the cloud-based gitlab.com). (Blue Cedar Platform does not currently support GitLab Enterprise projects.)
• The GitLab project produces mobile app binaries (IPA or APK).

Setup:

• On the Blue Cedar Platform:
  • Enable the GitLab extension. This involves creating a configuration that knows your GitLab server URL and Group Name. From the specified group, choose which projects to monitor. See Extension - GitLab.
  • Create an app. When you create an app, you're creating an app container with an app name. Once the app is created and monitoring GitLab, the platform can add versions and updates directly from GitLab. You can also upload an app binary manually and monitor GitLab for updates. See Creating an app. 
  • Add an Import step, GitLab sub-step to your app's workflow. This activity connects the GitLab source project with the app destination on the Blue Cedar Platform. You can select whether to import automatically or just get notifications. See Import from GitLab.
• After setting up the extension on the platform, go back to GitLab to create a webhook. This webhook gives GitLab information about your Blue Cedar Platform organization and app so that GitHub can send an HTTP POST payload to the platform API with notifications of app updates. 

Next time a new release is built, GitLab sends a notification to your Blue Cedar Platform instance. These updates appear in these places:

• On the Dashboard > App Import widget. This widget lists all apps that have new versions (for all Import extensions) and how many new versions. You can click Import to choose which versions to import to which apps, or you can click through the available versions link to the App Import Versions list for more details. See Using the Dashboard bak.
• The App Import Versions list. This page shows details of all available new versions for the app. On this page you can choose to Import a version, or Import and immediately run the workflow on the new version. See About the App Versions pages.

Setting up the GitLab webhook

Webhooks allow you to trigger a URL when a new release becomes available in your GitLab project. This is how the Blue Cedar Platform can monitor the GitLab project configured for your app. When a new version of the app is released on GitLab, GitLab sends an HTTP POST payload to the webhook's configured URL on the platform. 

To set up a webhook, log into GitLab:

• Navigate to your project.
• Go to Settings > Webhooks.

Customize these fields on the Webhooks/Integrations page:

• URL: https://apibcprod.bluecedar.com/v2/secure_app_intake/webhooks/receivers 
• Secret Token: No Blue Cedar requirement
• Trigger:
  • Check "Release events"
  • Clear all other triggers
• SSL verification: Clear "Enable SSL verification"

After you add the webhook, you can create a new release and check that the new app binary shows up on the Blue Cedar Platform.

Notes about GitLab release assets

A GitLab release is a snapshot of the source, build output, artifacts, and other metadata associated with a released version of the code. You can add different types of assets to each release, such as source code and links.

• Blue Cedar only supports assets directly downloaded via https://gitlab.com/api. 
• If the assets are external to GitLab, they should be publicly available without any authentication.

The assets associated with a release are associated with a URL that is static for the project. This permanent URL is defined during link creation or updating. For example, the asset URL can be something like this:

https://gitlab.com/api/v4/projects/_projectId_/repository/files/_fileName_.apk/raw?ref=master

Each asset is created dynamically as a result of the release job, for example:

https://gitlab.com/api/v4/projects/_projectId_/jobs/artifacts/_version_/raw/target/_fileName_.ipa?job=release-job

For more information about GitLab releases and release assets, see https://docs.gitlab.com/ee/user/project/releases/.