Bicep deployment requires extra properties after the site has been deployed from Azure DevOps

[laurihelkkula]

Describe the bug

When deploying a Static Web Site via Bicep (or ARM), and when the actual site has been deployed via Azure DevOps Pipelines, the Bicep deployment will fail with the error message:

Provider is invalid.  Cannot change the Provider. Please detach your static site first if you wish to use to another deployment provider.

From #495, you can solve this error by setting the provider. In this case, the value needs to be DevOps.

In addition to the provider property, you get similar error message for the properties branch and repositoryUrl.

To Reproduce
Steps to reproduce the behavior:

1. Create Bicep file (with empty properties object as instructed in Vague error message #477 to get around another error)
2. Deploy via Bicep
3. Get the deployment token, create the Azure Pipeline to deploy the site contents, and run it
4. Deploy via Bicep again
5. See error

Workaround
Set the properties to the correct values. You can see the expected values e.g. from Azure Portal. From the Static Web App overview, click JSON view to see the values. See the example Bicep file below for an example

Expected behavior
Provider, branch, or repositoryUrl should not have to be set in the Bicep file when the site deployment is not done via GitHub.

Screenshots
Example Bicep deployment command and the error message:

Device info (if applicable):
Not applicable.

Additional context
Example Bicep file

param location string = resourceGroup().location
param webappname string = 'mystaticwebsite'

resource webapp 'Microsoft.Web/staticSites@2021-01-15' = {
  name: webappname
  location: location
  //note: must include at least an empty properties object. otherwise you'll get a validation error during deployment
  properties: {
    //uncomment these and set correct values to make deployment succeed
    //provider: 'DevOps'
    //branch: 'the_deployed_branch'
    //repositoryUrl: 'https://<url to git repo in ADO>'
  }
  sku: {
    name: 'Free'
    tier: 'Free'
  }
}

[miwebst]

Hey @laurihelkkula, looks like we are crossing a couple of different resolutions. From step 1) can you provide the provider, branch and repoUrl all at once? Then you can use this bicep template for updates too. Something like this works for me:

"properties": { "provider" : "DevOps", "repositoryUrl": "https://dev.azure.com/test/test/_git/test", "branch": "test" },

[laurihelkkula]

Yes, specifying the properties in the first step does seem to work. Thanks @miwebst!

It still seems a bit awkward to specify these in the Bicep/ARM file, since they just need to match the ADO pipeline information. But at least it is possible to create a working Bicep file in the first step.

Since the immediate issue is resolved, I'll close this issue.

[RossMurr4y]

I've just run into this issue yet again. Rather than update my BICEP template library with configuration that is currently mandatory but I hope to remove one day, I sought an alternative solution to prevent breaking changes to the template library down the road.

Through the Azure CLI I eventually found az staticwebapp disconnect which it seems it what is intended by "detaching" as per the error message received.

Doing a quick before/after disconnection with az staticwebapp list -o table shows that the branch, repositoryUrl and provider are cleared when you perform the disconnection. I was then able to perform a re-deployment without getting these issues.

Annoyingly the configuration reappeared again after a short while. So I now just perform the disconnection immediately prior to the infrastructure deployment in my pipelines.

[miwebst]

So that configuration metadata reflects the metadata of the last successful deployment. Is the ask here that you would like to avoid having that metadata in the BICEP template?

[laurihelkkula]

Based on my experience with Bicep, Azure DevOps pipelines, and Azure Web Apps, I think the intuitive way would be to create the static web app resource via Bicep, and then control the deployment with pipelines. In other words, the Bicep should not need to specify repository or branch. It can possibly specify that the source will be Azure DevOps.

The Azure DevOps pipeline task should specify the target resource similarly to other Azure deployments: subscription, resource group and resource identifier. It should also use the Azure service connection for credentials, instead of the deployment token.

[johnnyreilly]

Thanks so much for sharing this workaround! I discovered it after much googling. I shared it here in the hope that others need Google less!

https://blog.johnnyreilly.com/2021/08/15/bicep-azure-static-web-apps-azure-devops

[bkarstaedt]

I totally agree what @laurihelkkula suggests:

The Azure DevOps pipeline task should specify the target resource similarly to other Azure deployments: subscription, resource group and resource identifier. It should also use the Azure service connection for credentials, instead of the deployment token.

As what I just encountered is, that after each bicep deployment the Static Web App got a new deployment token. So the deployment is not idempotent and I therefore have to change the token for the pipeline each time...

[abouroubi]

Hello, I'm having the same issue.
Is there an ETA for it to be fixed ?

[futuredesignUK]

Thanks to @RossMurr4y @johnnyreilly for the workaround, that sorted out my problem.

Was getting the error on an ADO pipeline

The template deployment 'main-20211103-103721-b3b4' is not valid according to the validation procedure.
##[error]Details:
##[error]BadRequest: RepositoryUrl is invalid.  Cannot change the RepositoryUrl. Please detach your static site first if you wish to attach to another repository.

adding the Azure CLI task (before bicep build) below has sorted it

      - task: AzureCLI@2
        name: DisconnectStaticWebApp 
        displayName: 'Disconnect Static Web App'
        inputs:
          azureSubscription: $(serviceConnection)
          scriptType: 'bash'
          scriptLocation: 'inlineScript'
          inlineScript: 'az staticwebapp disconnect -n $(staticWebAppName)'

I guess the Static Web Apps are more geared for GitHub actions than ADO

[abouroubi]

The issue is closed because it fixes the op problem with Azure DevOps, but the root cause is still here, the code is not idempotent, first run goes fine, second without any modification throws an error.

Is there any other issue that was opened to fix it ?

[miwebst]

If you are providing the provider, repositoryUrl, and branch then it should be idempotent.

[abouroubi]

I’m not providing the repositoryUrl, I don’t want my infrastructure to know about how I store my code.
And the first run works, the second don’t, so it’s not idempotent.

[miwebst]

By the second run, do you mean after you've deployed content to the SWA?

[abouroubi]

Yes, I deploy my infrastructure, deploy my code.
modify other parts of my infrastructure, try to deploy it again, and it errors on the SWA part.

[ansman]

I think the problem here is that deployment from DevOps or GitHub Actions actually updates the static site properties which then causes the bicep deployment to fail the next time which feels a bit backwards.

[miwebst]

Correct. When you deploy code our references will be updated so that we can provide the most recent information in our client experiences (i.e. Azure Portal). Changing these references back to empty is what causes the bicep deployment to fail.

[ansman]

It would be nice to get some official support for this workflow in Bicep. Currently it seems to assume that you are setting up your GitHub or DevOps pipeline as a part of the bicep deployment. There are ways to skip this of course (either by omitting those options or by setting the skip property) but that isn't the intended use case.

The use case we are using is to deploy the Azure resources using Bicep then taking the deployment token and manually set up our GH Actions workflow.

Another issue today is that you also need to set the provider property but this property is marked as "read only" and thus generates a warning when deploying unless suppressed.

Perhaps the build config could be extracted into a separate resource type which could be created when deploying but then deploying using Bicep will simply ignore that extra resource unless you opt to change it?

[miwebst]

The provider readonly issue has been fixed in our most recent api-version: https://github.com/Azure/azure-rest-api-specs/blob/0bca06c5e06c6b12ea8e560c7416a5968136e276/specification/web/resource-manager/Microsoft.Web/stable/2021-03-01/StaticSites.json#L2892

As for the overall use case, skipGithubActionWorkflowGeneration is the officially supported way to create a SWA without creating any workflows and you can specify it on update as well which will allow it to be idempotent.

[ansman]

Ah, great. We had been using skipGithubActionWorkflowGeneration already and we still get the same error (Provider is invalid) when deploying after a successful publish.