deploy-azure-storage command no longer creates container that does not exist yet.

[rickhellenthal]

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

💥 SharePoint Framework

Developer environment

Windows

What browser(s) / client(s) have you tested

• 💥 Internet Explorer
• 💥 Microsoft Edge
• 💥 Google Chrome
• 💥 FireFox
• 💥 Safari
• mobile (iOS/iPadOS)
• mobile (Android)
• not applicable
• other (enter in the "Additional environment details" area below)

Additional environment details

Versions used:

• SPFX: 1.13.0 (tried 1.13.0-beta.17 as well)
• Node: v14.17.6
• npm: 7.24.0
• gulp: 4.0.2

Describe the bug / error

We used to change the container name inside the deploy-azure-storage.json file dynamically based on our package version, then we would upload this build to our azure storage account. In this way we have a container for each version of our project. In SPFX 1.21.1 the deploy-azure-storage command would create the container if it didn't exist yet automatically.

However, since upgrading to SPFX 1.13.0 azure storage containers are no longer created automatically, instead we receive the following error:

RestError: The specified container does not exist.
Time:2021-11-02T14:53:48.7614729Z 404 ContainerNotFound

This means we have to create the container each time by hand each time we increment our version, which is quite inconvenient. Keeping the same container is not an option for our use case.

Steps to reproduce

1. Setup an azure storage account as you would normally
2. Fill in the fields in deploy-azure-storage.sjon and write-manifest.json as per the microsoft documentation.
3. Set the 'container' field to a container that does not exist within your azure storage account.
4. bundle your solution
5. run gulp deploy-azure-storage

Expected behavior

We expected that the gulp deploy-azure-storage command would create the container within our storage account automatically (just as in spfx version 1.12.1), however this was not the case and we received an error instead.

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[patmill]

Just checking @rickhellenthal - if you use the existing 1.12 build pipe, does the error go away? Just wondering if it is an azure back end difference vs. a build toolchain in 1.13.

[adrichema]

Unfortunately we have the same issue, @patmill, new containers are not being auto created in Azure for v1.13.0 projects which is very inconvenient. @rickhellenthal, we use the same approach, have a container for each package version, so it's much easier to clean-up storage account by just removing the containers for old versions that are no longer being used.

[rickhellenthal]

Hi @patmill, we first noticed the issue in our azure pipeline, which uses the version that is present in the package.json (1.13.0 in this case), but I also run into it when I try to build and deploy from my local machine.
I'm afraid I can't check if it would work with 1.12.1 in this solution since we're building adaptive card extensions and spfx 1.13.0 is required for this.

However, we also have other solutions (which only contain webparts at the moment) that run on 1.12.1, the deploy-azure-storage command works as expected in these solutions. So it does seem to be related to the new spfx version.

We were looking through the spfx packages in node_modules and noticed that the function uploadFilesToAzureAsync (which is called from deployAzureStorage in @microsoft/sp-build-core-tasks) and uploadFileToAzureAsync in @microsoft/spfx-heft-plugins were quite different, maybe this has something to do with it?

I also checked if a clean solution with webparts instead of adaptive cards would work to see if that would make a difference, but in that case we receive the error as well. [Edit]: with version 1.13.0 that is.

[patmill]

Thanks for the information @rickhellenthal . We'll take a look at what changed.

[patmill]

Hey @rickhellenthal - talked to the tooling people, and they have a fix targetted. We'll look at getting it out in a 1.13.1 patch.