Hi all 😀, do you know if there is a way to achieve exactly this specific case with Pulumi? https://docs.microsoft.com/en-us/azure/container-registry/container-registry-tutorial-quick-task What I want is to mimic the behavior of

az acr build --registry myRegistry --image hello:v1 .

With this specific command the local build context is directly uploaded to the registry and the build will be done by ACR. I see that we have https://www.pulumi.com/registry/packages/azure-native/api-docs/containerregistry/taskrun/ that can be configured with a

DockerBuildRequestArgs

like this

var buildContextArchive = new FileArchive(buildContext);
const string buyBuildTaskRunName = "buy-build-task-run";
var buyBuildTaskRun = new TaskRun(buyBuildTaskRunName, new TaskRunArgs
{
    TaskRunName = buyBuildTaskRunName,
    RegistryName = containerRegistry.Name,
    ResourceGroupName = resourceGroup.Name,
    ForceUpdateTag = buyImageNameFull,
    RunRequest = new DockerBuildRequestArgs
    {
        SourceLocation = "here I need the url after the uplaod of the local context",
        DockerFilePath = "Dockerfile.buy",
        ImageNames = 
        {
            buyImageNameFull
        },
        IsPushEnabled = true,
        NoCache = false,
        Type = "DockerBuildRequest",
        Platform = new PlatformPropertiesArgs
        {
            Architecture = "amd64",
            Os = "Linux"
        }
    }
});

but the problem is that

SourceLocation

must be a valid url so someway I need to uplaod the local context somewhere (doesn’t work with local hard drive paths). I do not want to point directly to the github repo url (imagine this inside an azure devops pipeline for example…the source code is local, already pulled by the pipeline)

I always thought tar and zip are somewhat interchangeable. If not, I guess you can create a tar file with a 3rd party utility function and then upload it with

FileAsset

Hi @tall-librarian-49374 at the end with a

.tar.gz

it works, trying with a .zip or just passing the content of a folder to the FileArchive it does not. Now I’m facing another error 😂, the build task runs successfully in azure container registry but seems there is something wrong in the

Feature#WaitForCompletion

. I get this error:

Future#WaitForCompletion: the number of retries has been exceeded: StatusCode=404 -- Original Error: Code="Creating" Message="The async operation failed." AdditionalInfo=[{"status":"Creating"}]

Seems something like this issue you found some time ago https://github.com/Azure/go-autorest/issues/596 I’m not able to find the specs about ACR task run here https://github.com/Azure/azure-rest-api-specs/blob/main/specification/containerreg[…]soft.ContainerRegistry/stable/2021-09-01/containerregistry.json

const string buyBuildTaskName = "buy-build-task";
var buyBuildTask = new ACR.Task(buyBuildTaskName, new TaskArgs
{
    TaskName = buyBuildTaskName,
    RegistryName = containerRegistry.Name,
    ResourceGroupName = resourceGroup.Name,
    Status = ACR.TaskStatus.Enabled,
    IsSystemTask = false,
    AgentConfiguration = new AgentPropertiesArgs
    {
        Cpu = 2
    },
    Identity = new IdentityPropertiesArgs
    {
        Type = ACR.ResourceIdentityType.SystemAssigned
    },
    Platform = new PlatformPropertiesArgs
    {
        Architecture = Architecture.Amd64,
        Os = OS.Linux
    },
    Step = new DockerBuildStepArgs
    {
        ContextPath = BuildContextBlobUrl,
        DockerFilePath = "Dockerfile.buy",
        ImageNames = 
        {
            BuyImageTag
        },
        IsPushEnabled = true,
        NoCache = false,
        Type = "Docker"
    }
});

const string buyBuildTaskRunName = "buy-build-task-run";
var buyBuildTaskRun = new TaskRun(buyBuildTaskRunName, new TaskRunArgs
{
    RegistryName = containerRegistry.Name,
    ResourceGroupName = resourceGroup.Name,
    ForceUpdateTag = "t2", //fake tag just to force the update
    RunRequest = new TaskRunRequestArgs
    {
        TaskId = buyBuildTask.Id,
        Type = "TaskRunRequest"
    }
});

The async operation failed

sounds like an Azure error. Any chance you can see its details in activity logs of the resource or resource group?

I try to check and I’ll let you know, the second time pulumi up runs everything seems then ok, it’s a first time failure on task run update

You could write verbose logs and find all HTTP requests and responses there if you want to understand exactly what is going on

like pulumi up --debug --logtostderr -v=9 ?? already tried without getting useful info

yes, this makes azure native log all http requests

Sorry @tall-librarian-49374 I’m not sure what I have to look at inside the log, it seems that a certain point it receives an Unknown error then the message is just what I already posted here Here attached the log

Could you try again with the

--logflow

flag?

cb1b is the run id of the task that succeeds but seems there is problem getting the result. The task requires more or less 1 minute to complete, the pulumi up takes more than 4 minutes, it retries to ask for the status until the max num of retries and then fails?

I don’t know how this can be solved other than changing the code TBH… Could you please file an issue for this?

ok, I do it just after the work

az acr build - I spent some time looking at this and I nearly got it but unfortunately hit a wall when tried to upload the blob part as pulumi blob doesn't let you pass in a SAS to auth to the ACR upload url

@tall-librarian-49374 if the one outlined is problem there is something that you can do at the provider level or it is completely in charge of the ARM specification team? @mysterious-mouse-98391 where do you want to upload the blob? I suppose that under the hood Azure Container Registry has it’s own storage to support things like

az acr build

or the new

az container app up

but I did not really understand how to do this using the pulumi azure provider. So I created a separate azure storage with a container and I upload the

.tar.gz

of the docker build context there. You can generate the SAS url of the blob and pass it to the task.

static Output<string> SignedBlobReadUrl(Storage.Blob blob, Storage.BlobContainer container, Storage.StorageAccount account, ResourceGroup resourceGroup)
{
    var serviceSasToken = Storage.ListStorageAccountServiceSAS.Invoke(new Storage.ListStorageAccountServiceSASInvokeArgs
    {
        AccountName = account.Name,
        Protocols = Storage.HttpProtocol.Https,
        SharedAccessStartTime = "2022-05-01",
        SharedAccessExpiryTime = "2022-12-31",
        Resource = Storage.SignedResource.C,
        ResourceGroupName = resourceGroup.Name,
        Permissions = Storage.Permissions.R,
        CanonicalizedResource = Output.Format($"/blob/{account.Name}/{container.Name}"),
        ContentType = "application/json",
        CacheControl = "max-age=5",
        ContentDisposition = "inline",
        ContentEncoding = "deflate",
    }).Apply(blobSAS => blobSAS.ServiceSasToken);

    return Output.Format($"https://{account.Name}.<http://blob.core.windows.net/{container.Name}/{blob.Name}?{serviceSasToken}%22);|blob.core.windows.net/{container.Name}/{blob.Name}?{serviceSasToken}");>
}

@cold-insurance-72507 so in Pulumi for ACR there is a function that returns the internal ACR blob storage place which is where the az build command puts it to. It outputs a relative path and an upload url , however the az build command can use the SAS provided where as the pulumi blob provider doesn't seem able to. if it did you could replied the az build behaviour by building the ACR , getting the upload url and SAS that comes with it , zipping and uploading locally to the ACR upload url, using the SAS for permissions, and then passing the relative url to the Task Run as the Source with the blob appended. Which is what az build seems to be doing under the hood. https://www.pulumi.com/registry/packages/azure-native/api-docs/containerregistry/listregistrybuildsourceuploadurl/

@mysterious-mouse-98391 yes I saw the

listRegistryBuildSourceUploadUrl

but I didn't investigate it so much. But the problem relative to the task run is still here also in that case...failing the task run then fails also the deploy of the azure container app... in pulumi I mean...

@cold-insurance-72507 yeah I'm pretty sure you can't mimic it exactly, you need to be able to pass the SAS to create the blob there and you don't seem able to. Think you'd have to do as you're doing, put it to a blob storage you already have perms to. Though also if you gzip locally and point to complete url locally maybe it will work ? so like source: ./myfolder/dockerfile.tar.gz.