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

Mark JAWS_API_KEY as masked in Settings -> CI/CD -> Variables.

stages:
  - build
  - test
  - release

create_release:
  stage: release
  image: mcr.microsoft.com/powershell:latest
  script:
    - pwsh -c "Install-Module -Name JawsDeploy -Scope CurrentUser -Force"
    - pwsh -c "Connect-JawsDeploy -Url 'https://app.jawsdeploy.net' -ApiKey '$JAWS_API_KEY'"
    - pwsh -c "New-JawsDeployRelease -Workspace 'default' -Project 'checkout-service' -Version '$CI_PIPELINE_IID' -Packages @{ 'Checkout.Web' = '$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.