Your ALOps license¶
Every ALOps task — Azure DevOps or GitHub Actions, v1 through v3 — needs a license. The License Key is on your ALOps invoice; if you don't have one, start here.
The license is read from an environment variable. Both platforms accept it under either of these names:
alops-licenseid(the original convention)ALOPS_LICENSEID(the GitHub-Actions-friendly form)
You only need to supply it under one name. Pick the form natural to your platform and stick with it.
Azure DevOps¶
The recommended setup is a library variable group:
- In your AzDO project, open Pipelines → Library.
- Click + Variable group.
- Name it
ALOps License. - Add a variable
alops-licenseidand set its value to the License Key. - Click the lock icon to mark it as a secret.
- Save.
Then reference the group from your pipeline:
variables:
- group: 'ALOps License'
steps:
- task: ALOpsInfo@3
# the alops-licenseid variable is now exposed to every step
For tighter control, link the variable group to Azure Key Vault instead of inlining the value. AzDO will fetch the secret from the vault per pipeline run.
# Library → Variable groups → New → "Link secrets from an Azure key vault as variables"
variables:
- group: 'ALOps License (KV)'
The pipeline variable name must be exactly alops-licenseid for ALOps to find it.
GitHub Actions¶
The recommended setup is a repository secret:
- In your repo, open Settings → Secrets and variables → Actions.
- Click New repository secret.
- Name:
ALOPS_LICENSEID. Value: the License Key. - Save.
Then reference it in your workflow's env: block — at job scope so every step sees it:
jobs:
build:
runs-on: windows-latest
env:
ALOPS_LICENSEID: ${{ secrets.ALOPS_LICENSEID }}
steps:
- uses: actions/checkout@v4
- uses: HodorNV/ALOps-V3/alops-info@v3 # <!-- TODO: confirm action repo path -->
For organization-wide use:
- Org → Settings → Secrets and variables → Actions → New organization secret.
- Name
ALOPS_LICENSEID, set value, scope to the repos that need it. - Drop the per-repo secret. Workflows still see
${{ secrets.ALOPS_LICENSEID }}because organization secrets are inherited.
For Azure Key Vault integration on GitHub Actions, the typical pattern is the Azure/get-keyvault-secrets action upstream of the ALOps step:
- uses: Azure/login@v2
with:
creds: ${{ secrets.AZURE_CREDENTIALS }}
- name: Read license from Key Vault
id: kv
uses: Azure/get-keyvault-secrets@v1
with:
keyvault: 'my-keyvault'
secrets: 'alops-licenseid'
- uses: HodorNV/ALOps-V3/alops-info@v3 # <!-- TODO: confirm action repo path -->
env:
ALOPS_LICENSEID: ${{ steps.kv.outputs.alops-licenseid }}
Verifying the license is picked up¶
Run any ALOps task with ALOpsInfo@3 (AzDO) or alops-info (GitHub Actions). The diagnostic output prints the resolved license tier near the top of the log. A misconfigured license shows up as a clear error, not a silent fail.