How to use the Gitlab CI/CD feature

Overview

Is your application code stored in a Gitlab repository? Did you know that CAST Imaging on Cloud interfaces with Gitlab CI/CD external link so that you can run the entire code analysis workflow whenever you push or merge to your desired branch? This means that you can fully automate the analysis and generation of results in CAST Imaging on Cloud direct from your Gitlab repository.

How does it work?

CAST Imaging on Cloud requires that your application source code is stored in a Gitlab repository (public or private) and that you have access to Gitlab CI/CD external link in your Gitlab account. Following that, a dedicated .gitlab-ci.yml file must be present at the root of your repository, containing instructions that will define when the Gitlab CI/CD job is run, what it does and where the profiling and analysis results should be uploaded to. The job will use a dedicated Gitlab runner external link to perform the required actions.

Using the Gitlab Ci/CD feature effectively replaces the CAST Imaging Analyzer tool that you would normally download to your local machine to perform the required actions.

Prerequisites

  • A CAST Imaging on Cloud account
  • Source code stored in a Gitlab repository (public or private)
  • Access to Gitlab CI/CD external link - all Gitlab accounts (even those on the free tier) have access to Gitlab CI/CD and include a certain number of “compute” minutes, or you can use your own self-hosted “runner”

How does Gitlab charge for Gitlab CI/CD?

All Gitlab account tiers provide a number of Gitlab CI/CD “compute” minutes per month (see Gitlab pricing external link) to use Gitlab’s own “runners”:

  • the CAST Imaging on Cloud workflows will fail when all bundled minutes are used up and you will not be able to launch any new jobs until the compute minutes are reset, you subscribe to a paid tier, you purchase add-on compute minutes or you use your own self-hosted “runners”.

It is not possible to predict how many “compute” minutes your workflow for CAST Imaging on Cloud will use, but the larger the application, the longer it will take to complete. You should therefore ensure that you monitor your Gitlab CI/CD usage.

How to onboard an application using Gitlab CI/CD

Step 1 - Create the application in CAST Imaging on Cloud

In your CAST Imaging on Cloud account, click CI/CD Integration > Onboard application:

Name your application:

Then follow the instructions on screen:

Step 2 - Configure the Gitlab CI/CD repository variable

In your Gitlab account, navigate to the repository containing your application source code, then Settings > CI/CD > Variables > Add variables:

Create a new variable using the information provided to you in CAST Imaging on Cloud (this links your source code to the application in CAST Imaging on Cloud):

  • Type = Variable
  • Key = IMAGING_CLOUD_API_KEY
  • Value = as provided by CAST Imaging on Cloud

alt text

Step 3 - Create a .gitlab-ci.yml file at the root of your repository

Create a .gitlab-ci.yml at the root of your repository in the “main” or “master” branch (i.e. the default). Paste in the code provided in CAST Imaging on Cloud and commit your changes:

Committing this file will automatically trigger a Gitlab build which you can see in the Pipeline:

This workflow build will run the profiling and analysis steps and then upload the results into CAST Imaging on Cloud. When the workflow has completed, you can consult the results as normal in CAST Imaging on Cloud.

FAQ

How do I trigger a new Gitlab CI/CD build?

The .gitlab-ci.yml file is configured to trigger a new build whenever you push/merge into the main or master branch, therefore generating new results in CAST Imaging on Cloud:

  rules:
    - if: '$CI_COMMIT_BRANCH == "master" || $CI_COMMIT_BRANCH == "main"'
      when: always

You can change this behaviour if necessary by modifying the syntax as described in CI/CD YAML syntax reference external link.

What if my Gitlab CI/CD job exceeds the timeout?

By default all jobs have a 60 minute (1 hour) timeout - i.e. if the job exceeds this limit then it will be stopped by Gitlab and will fail. This can occur when you are attempting to onboard a very large application with millions of lines of code. You can increase this timeout up to 24 hours, see Set a limit for how long jobs can run external link. Beyond this, you will need to set up your own self-hosted runner and use it with the Gitlab CI/CD job - this runner will not be subject to the Gitlab CI/CD timeout. Please contact Technical Support if you need advice about this.

How do I redisplay the instructions in CAST Imaging on Cloud?

If you have navigated away from the instructions pop-up displayed in CAST Imaging on Cloud, you can redisplay using the Start analysis option: