By Jaws Deploy team · Updated

Integrating GitLab CI

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

Search guides... Ctrl K

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.

// .gitlab-ci.yml fragment

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.