Azure-pipelines-tasks: Docker task for Tag image is failing for version 1.154.2

Created on 1 Aug 2019  Â·  10Comments  Â·  Source: microsoft/azure-pipelines-tasks

Note

Issues in this repo are for tracking bugs, feature requests and questions for the tasks in this repo

For a list:
https://github.com/Microsoft/azure-pipelines-tasks/tree/master/Tasks

If you have an issue or request for the Azure Pipelines service, use developer community instead:

https://developercommunity.visualstudio.com/spaces/21/index.html )

Required Information

Entering this information will route you directly to the right team and expedite traction.

Question, Bug, or Feature?
Type: Bug

Enter Task Name: Docker Task (Tag)

list here (V# not needed):
https://github.com/Microsoft/azure-pipelines-tasks/tree/master/Tasks

Environment

  • Server - Azure Pipelines or TFS on-premises?

  • Agent - Hosted or Private:

    • If using Hosted agent, provide agent queue name:

    • If using private agent, provide the OS of the machine running the agent and the agent version:

Issue Description

Docker tag fails for version 1.154.2
It appears that there is a recent change in the way the option for Qualifying an image name with the registry name works. That seems to be suspected cause.

Task logs

[debug]Tagging image */MyOrg/api-reference-data-v1:29 with */MyOrg/api-reference-data-v1:29.

[debug]DOCKER_HOST=undefined

[debug]exec tool: /bin/docker

[debug]Arguments:

[debug] tag

[debug] */MyOrg/api-reference-data-v1:29

[debug] */MyOrg/api-reference-data-v1:29

[command]/bin/docker tag /MyOrg/api-reference-data-v1:29 */MyOrg/api-reference-data-v1:29
Error response from daemon: no such id: *
*/MyOrg/api-reference-data-v1:29

Troubleshooting

Checkout how to troubleshoot failures and collect debug logs: https://docs.microsoft.com/en-us/vsts/build-release/actions/troubleshooting

Error logs

[Insert error from the logs here for a quick overview]

Release bug

All 10 comments

Set ' Qualify image name ' to true when building the image and try again.

Have tried that option. It doesn't work.

On Thu, 1 Aug. 2019, 2:18 pm Deepak Sattiraju, notifications@github.com
wrote:

Set ' Qualify image name ' to true when building the image and try again.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/azure-pipelines-tasks/issues/11044?email_source=notifications&email_token=AAVKC2LAJZESIHHGTAXJIMLQCJPX5A5CNFSM4IILUH52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3JIDSI#issuecomment-517112265,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAVKC2OSEFPFF6OMDITLEG3QCJPX5ANCNFSM4IILUH5Q
.

Have you supplied the imageName parameter in the build step?

Yes. I am using the following as Image name to tie it to the build: $(
Build.Repository.Name):$(Build.BuildNumber)

Just to add, there was no change done to the pipeline for few weeks. The
builds started failing recently.

On Thu, Aug 1, 2019 at 3:17 PM Deepak Sattiraju notifications@github.com
wrote:

Have you supplied the imageName parameter in the build step?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/azure-pipelines-tasks/issues/11044?email_source=notifications&email_token=AAVKC2MM3AFTZ73GWBRSDY3QCJWU3A5CNFSM4IILUH52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3JKW7Q#issuecomment-517122942,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAVKC2MII5HMEOBUKPIPJ5LQCJWU3ANCNFSM4IILUH5Q
.

--
aKs

We have recently changed the way the docker tag works for consistency. Earlier the source tag wasn't getting qualified but it does now.
So, you basically have to set qualify image name in the build step and tag step to true if you want to qualify image name overall.

Would you be willing to share a snapshot of your pipeline definition here? If it has some sensitive data, feel free to initiate a thread on [email protected]

I am sending you JSON for the Docker tag task (and not the full pipeline).
This may help:

{
"environment": {

  },
  "displayName": "Tag Docker Image",
  "alwaysRun": false,
  "continueOnError": false,
  "condition": "succeeded()",
  "enabled": true,
  "timeoutInMinutes": 0,
  "inputs": {
    "containerregistrytype": "Azure Container Registry",
    "dockerRegistryEndpoint": "",
    "azureSubscriptionEndpoint": "6ed33b18-a255-4b90-8cbb-xxxxxxxxx",
    "azureContainerRegistry": "removed_xxx.azurecr.io",
    "command": "Tag image",
    "dockerFile": "**\/Dockerfile",
    "arguments": "",
    "pushMultipleImages": "false",
    "tagMultipleImages": "false",
    "imageName": "$(Build.Repository.Name):$(Build.BuildNumber)",
    "imageNamesPath": "",
    "qualifyImageName": "true",
    "includeSourceTags": "false",
    "includeLatestTag": "false",
    "addDefaultLabels": "true",
    "useDefaultContext": "true",
    "buildContext": "",
    "imageDigestFile": "",
    "containerName": "",
    "ports": "",
    "volumes": "",
    "envVars": "",
    "workingDirectory": "",
    "entrypointOverride": "",
    "containerCommand": "",
    "runInBackground": "true",
    "restartPolicy": "no",
    "maxRestartRetries": "",
    "dockerHostEndpoint": "",
    "enforceDockerNamingConvention": "true",
    "memoryLimit": ""
  },

On Thu, Aug 1, 2019 at 3:30 PM Deepak Sattiraju notifications@github.com
wrote:

We have recently changed the way the docker tag works for consistency.
Earlier the source tag wasn't getting qualified but it does now.
So, you basically have to set qualify image name in the build step and tag
step to true if you want to qualify image name overall.

Would you be willing to share a snapshot of your pipeline definition here?
If it has some sensitive data, feel free to initiate a thread on
[email protected]

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/azure-pipelines-tasks/issues/11044?email_source=notifications&email_token=AAVKC2L6IDAB7242FWLUICLQCJYGJA5CNFSM4IILUH52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3JLNGY#issuecomment-517125787,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAVKC2PZTVSO6HGHJE5H7C3QCJYGJANCNFSM4IILUH5Q
.

--
aKs

Could you send a snapshot of your build step too

This change has broken our build pipelines too. A prior build process builds and tags images locally, and we then used this task later to tag the image with the appropriate repo.

The assumption behind the vX.* versioning in devops is that non-major versions won't change the behaviour of the tasks, otherwise nothing can be relied upon.

Perhaps a better way to handle this would be to add a new option defaulting to false to allow the source to be qualified too?

Apologies for introducing this breaking change.
As per your suggestion

Perhaps a better way to handle this would be to add a new option defaulting to false to allow the source to be qualified too?

I have raised a PR (https://github.com/microsoft/azure-pipelines-tasks/pull/11055) addressing the same and will hotfix it today.

This fix has been hotfixed. Please verify your changes and feel free to reopen this issue accordingly.

Was this page helpful?
0 / 5 - 0 ratings