GitLab

GitLab is an open source code repository and complete DevOps platform. It offers a location for online code storage and capabilities for issue tracking and CI/CD.

This how-to will provide a basic understanding of how add the Relyance Source Code inspector (SCI) into a typical build job.

Prerequisites:

1. A source code repository needs to be available.
2. The relyance.yaml file needs to be in the source code root directory.
3. Grab the command line code from Step 2 of the Relyance Source Code Integration settings from your Relyance instance.

See more info about the SCI commands here.

Steps:

1. Login to your Gitlab account.
2. Select your project from the front page.
3. Create a pipeline if necessary by going to the left-hand menu and selecting CI/CD-> Pipelines or edit an existing one by going to the left-hand menu and selecting CI/CD-> Editor.
4. Using the template below, update the pipeline:

# TODO: Update the docker pull command in the script section below. Recommend setting the ACCESS_TOKEN as an environment variable.

relyance-scan-job:
  image: docker:latest
  services:
    - docker:dind
  stage: test
  script:
    - echo "Running the Relyance Scan"
    - docker pull gcr.io/relyance-ext/compliance_inspector:release && docker run --rm -v `pwd`:/repo --env 'API_KEY=example:abcdefg0123456789abcdefg0123456789abcdefg' gcr.io/relyance-ext/compliance_inspector:release

This will run the Relyance scan during the test phase of each job. It is recommended to create a scheduled job instead. 5. To ensure this job is run on a schedule, add the following values:

# TODO: Update the docker pull command in the script section below. Recommend setting the ACCESS_TOKEN as an environment variable.

relyance-scan-job:
  image: docker:latest
  services:
    - docker:dind
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule" && $relyance_scan == "true"
  stage: test
  script:
    - echo "Running the Relyance Scan"
    - docker pull gcr.io/relyance-ext/compliance_inspector:release && docker run --rm -v `pwd`:/repo --env 'API_KEY=example:abcdefg0123456789abcdefg0123456789abcdefg' gcr.io/relyance-ext/compliance_inspector:release

6. You will also need to setup the schedule frequency. In the left-hand navigation menu, select CI/CD-> Schedules.
7. Click the New Schedule button.
8. Fill out the form with these values: Description: Provide a meaningful name (e.g. Relyance Scan) Interval Pattern: Specify the scan frequency Cron Timezone: Specify your timezone Target branch or Tag: It is suggested to scan against the production branch Variables: Create a variable to ensure this job runs specific to this scheduled job.

relyance_scan = true

9. Click the Save pipeline schedule button.
10. Test the newly created job by clicking the play triangle in the Schedules list.
11. To see your job progress by going to the left-hand menu and selecting CI/CD-> Jobs.
12. If there are no errors, you should start to see SCI results in your Relyance tenant.

Appendix:

Source Code Integration Step 2 info:

Example Step 2 Command

1. This command pulls the latest version of the Relyance Source Code Inspector.
2. This command initiates the Relyance Source Code Inspector within a local Docker container, establishing a shared folder and providing the necessary tenant API credentials.

If the connection reports Connected but returns nothing

These are the ways this integration comes back empty without reporting an error. Generated from the integration catalog, so it tracks what the connection actually asks for.

1. Authorised, then empty. The connection carries an authorisation, not a password: it stops returning data if the account that granted it loses access, its own permissions narrow, or the grant is revoked at the vendor. None of that reports an error here -- the connection keeps its last status until the next scan.
2. A credential rotated at the vendor is not picked up here. Client Secret is stored when you save the connection, so regenerating the value at the vendor breaks the next scan until it is re-pasted here. Recording the expiry on the connection means Relyance warns you before it lapses.

Authentication methods and fields

Pick one of these under Authentication Method on the connection wizard's Authentication step. This table is generated from the integration catalog, so it always matches what the form actually asks for.

Manage this integration with Terraform

Connections for this integration can be managed as code with the Relyance Terraform provider. Non-secret fields go in auth.params; secret fields go in auth.secrets_wo, which is write-only — never stored in Terraform state. Rotate secrets by bumping auth.secrets_wo_version.

The OAuth (browser authorization) method uses a browser authorization flow, so the connection is created in the Relyance app. Manage it in Terraform afterwards by importing it (terraform import relyance_integration_connection.example gitlab/<connection_id>) or reading it with the relyance_integration_connection data source.