# Integrating GitLab CI

Source: https://www.jawsdeploy.net/guides/integrating-gitlab

A small `deploy` stage that hands off the build artefact and version to Jaws Deploy after tests pass.

GitLab CI integrates with Jaws Deploy the same way as any other CI tool: a final stage calls the REST API or PowerShell SDK to create a release. Pipeline variables are stored in GitLab's CI/CD settings as masked variables.

## A dedicated deploy stage after build and test

Add `JAWS_API_LOGIN` (the service account ID) and `JAWS_API_PASSWORD` (the API key) as masked variables in **Settings -> CI/CD -> Variables**.

```
stages:
  - build
  - test
  - release

create_release:
  stage: release
  image: mcr.microsoft.com/powershell:latest
  script:
    - |
      pwsh -Command '
        Import-Module ./JawsDeploySdk.psm1   # github.com/JawsDeploy/powershell-sdk
        New-JawsRelease `
            -projectId       "<project id>" `
            -version         "1.0.$env:CI_PIPELINE_IID" `
            -packageVersions @{ "Checkout.Web" = "1.0.$env:CI_PIPELINE_IID" }
      '
  only:
    - main
```

## Versioning conventions that work well

`$CI_PIPELINE_IID` is the simplest version source - monotonic and unique within the project. If you tag releases, `$CI_COMMIT_TAG` is cleaner. For SemVer schemes, build the version from a base in the repo plus the pipeline ID as the build metadata segment.

> **// One job, multiple projects - If your repo builds several deployable units, create one Jaws Deploy release per unit.**
> 
> Use a script that iterates over the project list and calls `New-JawsRelease` for each, or model the GitLab job as a matrix across the project names. Either way: one Jaws Deploy release per deployable unit, not one per repo.