iCR Workflow Integration Guide
WebTry iCR
CI/CD Workflow 3.0
CI/CD Workflow 3.0
  • Table of contents
    • Introduction
    • 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 A - Getting a BitBucket App Password for JENKINS
Powered by GitBook
On this page

Was this helpful?

  1. Table of contents
  2. GitLab Workflow

Workflow Overview

PreviousGitLab WorkflowNextPreparing the Docker Image

Last updated 1 year ago

Was this helpful?

Adding a CI/CD capability into a project repository requires connecting a workflow yml script created and managed in GitLab with the iCR server offering the analysis. It is assumed that there is a DevOps engineer or someone with equivalent skill, who is already familiar with GitLab CI/CD and who will prepare iCR for integration into GitLab CI/CD. The diagram below will be used as the reference for the steps.

Step 1. GitLab CI/CD employs a framework where customizable functionality can be added in a number of different ways. One of those ways is to implement behavior as a Docker image that can be executed by GitLab. This image, supplied by OpenRefactory, communicates securely with the iCR Navigator to identify and manage the automated workflow. The first step is to and register it with GitLab.

Step 2. Once the Docker image is ready, it needs to be registered that wants to use it.

Step 4. When the pipeline is executed, the gitlab-ci.yml script is run. The Navigator will be requested to start an analysis using information provided from the script variables.

Step 5. The Navigator will use that information to determine the correct branch to be analyzed. The Navigator will automatically fetch the source code from the configured GitLab repository and initiate an analysis.

Step 6. Once the analysis completes, the user is notified via an email message. The email is sent to the address defined by one of the variables from Step 3. An email address MUST be provided so that iCR has a way of not only signaling completion, but also a way of communicating any errors that may have occurred.

Step 7. Once notified that analysis is complete and that results are available, the user may login directly to the iCR server which ran the analysis. From that login, the user can enter the Reviewer to process results in exactly the same manner as described in the User Guide for Private Platforms.

Step 3. With the image registered, the DevOps engineer creates the required gitlab-ci.yml file in the repository. This is what will cause iCR to be triggered. The script is used to provide the iCR server with necessary details about the project. In the case of GitLab, environment variables along with some the arguments to the trigger.

User supplied variables specify
prepare the Docker image
within each project repository