From devops-azure-devops
Generates Azure DevOps tasks for Docker image push to Azure Container Registry (ACR) or AWS Elastic Container Registry (ECR).
How this skill is triggered — by the user, by Claude, or both
Slash command
/devops-azure-devops:registry-pushThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Produces the Azure DevOps `DockerBuildPush` stage tasks for pushing a Docker image to a container registry. Registry type is resolved from `registry.type` in `.devops-agent.json` or prompted when unset. Supported targets: **ACR** and **ECR**.
Produces the Azure DevOps DockerBuildPush stage tasks for pushing a Docker image to a container registry. Registry type is resolved from registry.type in .devops-agent.json or prompted when unset. Supported targets: ACR and ECR.
All generated registry push steps apply two tags:
$(Build.BuildId) — immutable, unique per buildlatest — floating tag always pointing to the most recent successful buildtags: |
$(tag)
latest
$(tag) is mapped to $(Build.BuildId) in the pipeline-level variables block.
Use the Docker@2 task with the buildAndPush command and an ACR service connection.
ACRServiceConnection (configurable) created in the ADO project settings under Service Connections.AcrPush role on the registry.- stage: DockerBuildPush
displayName: 'Docker Build & Push (ACR)'
dependsOn:
- UnitTest
- SonarScan
- SnykScan
jobs:
- job: Docker
pool:
name: 'OrgLinuxPool'
steps:
- task: Docker@2
displayName: 'Build and push to ACR'
inputs:
containerRegistry: 'ACRServiceConnection'
repository: '$(imageName)'
command: 'buildAndPush'
Dockerfile: '**/Dockerfile'
tags: |
$(tag)
latest
variables:
registry: 'yourorg.azurecr.io'
imageName: '$(Build.Repository.Name)'
tag: '$(Build.BuildId)'
The Docker@2 task with buildAndPush uses containerRegistry to resolve the full image path: <registry>/<repository>:<tag>. The registry variable is only needed if constructing image references manually elsewhere in the pipeline.
Use the AWSShellScript@1 task (AWS Toolkit for Azure DevOps extension) to authenticate with ECR using aws ecr get-login-password, then build and push with the Docker CLI.
AWSServiceConnection (configurable) in ADO project settings.ecr:GetAuthorizationToken, ecr:BatchCheckLayerAvailability, ecr:PutImage, ecr:InitiateLayerUpload, ecr:UploadLayerPart, and ecr:CompleteLayerUpload permissions.- stage: DockerBuildPush
displayName: 'Docker Build & Push (ECR)'
dependsOn:
- UnitTest
- SonarScan
- SnykScan
jobs:
- job: Docker
pool:
name: 'OrgLinuxPool'
steps:
- task: AWSShellScript@1
displayName: 'Build and push to ECR'
inputs:
awsCredentials: 'AWSServiceConnection'
regionName: '$(awsRegion)'
scriptType: 'inline'
inlineScript: |
aws ecr get-login-password --region $(awsRegion) \
| docker login --username AWS --password-stdin $(ecrRegistry)
docker build -t $(ecrRegistry)/$(imageName):$(tag) .
docker tag $(ecrRegistry)/$(imageName):$(tag) $(ecrRegistry)/$(imageName):latest
docker push $(ecrRegistry)/$(imageName):$(tag)
docker push $(ecrRegistry)/$(imageName):latest
variables:
awsRegion: 'us-east-1'
ecrRegistry: '123456789012.dkr.ecr.us-east-1.amazonaws.com'
imageName: '$(Build.Repository.Name)'
tag: '$(Build.BuildId)'
Replace awsRegion and ecrRegistry with the actual values. Store the ECR registry URL in a variable group rather than hardcoding it in the pipeline YAML.
The skill reads registry.type from .devops-agent.json:
registry.type | Generated tasks |
|---|---|
acr | Docker@2 with buildAndPush |
ecr | AWSShellScript@1 with inline ECR login + docker push |
| (unset) | Prompt the user to choose ACR or ECR before generating |
The service connection name defaults are overridable:
{
"registry": {
"type": "acr",
"serviceConnection": "MyCustomACRConnection"
}
}
AWSShellScript@1 with an AWS service connection for ECR.--password to docker login directly in scripts. Always pipe from aws ecr get-login-password or equivalent.ecrRegistry and awsRegion in a variable group, not hardcoded in YAML, so they can be rotated without a code change.Guides completion of development work by verifying tests, detecting environment, and presenting structured options for merge, PR, or cleanup.
Enforces test-driven development: write failing test first, then minimal code to pass. Use when implementing features or bugfixes.
Guides creation and editing of skills using test-driven development with pressure scenarios and subagents to verify agent compliance.
npx claudepluginhub gagandeepp/software-agent-teams --plugin devops-azure-devops