Unified Language User Guides
iCR User Guide 4.2
iCR User Guide 4.2
  • Table of contents
    • Introduction
    • Overview
    • Authorizing Access to Your Source Code
      • Authenticating GitHub Access with a Cloud-Based VCS Repository Service
        • Authenticating GitHub Access with a Private VCS Repository
      • Authenticating GitLab Access with a Cloud-Based VCS Repository
        • Authenticating GitLab Access with a Private VCS Repository
      • Authenticating Bitbucket Access with a Cloud-Based VCS Repository
    • Using the Navigator
      • Connecting to the Navigator
      • Setting your User Password
      • The Navigator top banner
      • The Analysis Engine status
      • Selecting Your Source Code
        • Using a cloud-based VCS
        • Selecting your branch
        • Using a private VCS
        • Using a local project
        • Limiting the files to be analyzed
      • Integrating with your bug tracking system
        • Integrating with Jira - Define Your Project
        • Integrating with Jira - Authorizing Access for iCR
        • Integrating with Jira - Connecting with iCR
    • Using the Analysis Engine
      • Initiating an analysis
      • Monitoring the analysis
      • Interrupting the analysis
    • Reviewing your results
    • When you are complete
    • Integrating iCR Into Your CI/CD Workflows
      • Jenkins Workflow
        • Installing the plugin
        • Configuring the plugin
          • Creating a Personal Access Token
          • Copying Your Repository's URL
        • Viewing the Results
      • GitHub Actions Workflow
        • Workflow Overview
        • Preparing and Registering the Docker Image
        • Adding a Workflow to a Repository
        • Preparing the GitHub Workflow
          • Environment Variables
          • User Supplied Secrets
          • Setting the User Defined Secrets Values
        • Executing the Workflow
      • GitLab Workflow
        • Workflow Overview
        • Preparing the Docker Image
        • Configuring the GitLab Script variables
          • Environment Variables
          • User Supplied Variables
          • Creating a Personal Access Token
          • Setting the User Defined Variable Values
        • Executing the Workflow
      • Multiple Workflows
    • Appendix – Language Specific Fixer Lists
    • Appendix – Example Summary Report
    • Appendix - Sample Bug Listing
    • Appendix - Getting a BitBucket App Password for JENKINS
Powered by GitBook
On this page
  1. Table of contents
  2. Integrating iCR Into Your CI/CD Workflows
  3. GitLab Workflow

Preparing the Docker Image

PreviousWorkflow OverviewNextConfiguring the GitLab Script variables

Last updated 10 months ago

To control a CI/CD workflow, GitLab supports adding custom functionality to the workflow via containers. The container needs to be registered in the GitLab container registry for each project repository that wished to be invoked via a CI/CD workflow. iCR takes advantage of that to implement its integration into GitLab CI/CD via its which is a Docker image.

This Docker component MUST be registered from within the project repository for which a CI/CD workflow is desired. If you have multiple projects that wish to use iCR in a workflow, follow these steps for EACH repository. Since the CI/CD directory is included in the iCR product package and is created when the package is unzipped, these steps will assume access to the machine where the package was installed.

Included in the iCR package is a script named prep-container.sh. This script is used to prepare the provided iCR GitLab component for use with GitLab CI/CD. To prepare the component for use with GitLab, enter the command below from the CI/CD directory where the package was unzipped as this is where the Docker image is located:

./prep-container gitlab <username> <authentication-token> <repository-name> [<enterprise-URL>]

Where <username> is the name of the user who owns the repository to be analyzed and <repository-name> is the name of the repository. Note that the <username> and <repository-name> MUST be lowercase to satisfy the registry naming conventions. If the user is planning on pulling the source code from a GitLab Enterprise server, then the URL of the Enterprise server must be specified using <enterprise-URL>.

Staying with the examples used in the User Guide for Private Platforms, and assuming a cloud-based VCS, the command would look like:

./prep-container gitlab or-testuser baritone

This command causes the GitLab component named icr-gitlab, to be inserted into Docker with the name that is required by the GitLab registry. The output looks like:

21639b09744f: Loading layer [==================================================>] 65.51MB/65.51MB
2eb7a73e8a16: Loading layer [==================================================>] 376.5MB/376.5MB
80e6bf4bc2fd: Loading layer [==================================================>] 420.9MB/420.9MB
Loaded image: icr-gitlab:latest
Untagged: icr-gitlab:latest

The Docker image name will look like:

REPOSITORY                                             TAG             IMAGE ID         CREATED        SIZE
registry.gitlab.com/or-testuser/baritone/icr-gitlab    latest          0ac5980f86c5     7 months ago   858MB

Now we can register the container with the GitLab registry.

supplied GitLab component