# GitLab

![gitlab-logo-100.png](https://assets.relyanceuat.xyz/images/docs/13762905530637/13762796797581.png)
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.

![Step-2.png](https://assets.relyanceuat.xyz/images/docs/13762905530637/15210927173005.png)

See more info about the SCI commands **[here](#h_01GYWDTZ7NEGTVY2500D1N5TCV)**.

### Steps:

![GitlabSCI-1.png](https://assets.relyanceuat.xyz/images/docs/13762905530637/13770002252941.png)
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:
```yaml
# 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:
```yaml
# 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.

![GitlabSCI-2.png](https://assets.relyanceuat.xyz/images/docs/13762905530637/13770169913485.png)

### Appendix:

Source Code Integration **Step 2** info:

**Example Step 2 Command**

| 1 | docker pull  gcr.io/relyance-ext/compliance_inspector:release  && \ |
| --- | --- |
| 2 | docker run --rm -v `pwd`:/repo --env 'API_KEY= example :abcdefg0123456789abcdefg0123456789abcdefg'  gcr.io/relyance-ext/compliance_inspector:release |

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.

<!-- failure-modes:begin (generated from the integration catalog; do not hand-edit) -->

## 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.

<!-- failure-modes:end -->

<!-- auth-methods:begin (generated from the integration catalog; do not hand-edit) -->

## 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.

| Method | Required | Optional |
| --- | --- | --- |
| **Oauth2 / App Token** | `Client ID`, `Client Secret` (secret) | — |

<!-- auth-methods:end -->

<!-- terraform-examples:begin (generated from the integration catalog; do not hand-edit) -->

## Manage this integration with Terraform

Connections for this integration can be managed as code with the [Relyance Terraform provider](https://registry.terraform.io/providers/Relyance/relyance/latest). 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.

<!-- terraform-examples:end -->