Repository navigation
Bicep deployment requires extra properties after the site has been deployed from Azure DevOps #516
Description
Activity
Hey Lauri Helkkula (@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" },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.
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 disconnectwhich 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 tableshows 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.
Reacted by Aleksander Valle Grunnvoll, bkarstaedt, Sam Hope-Evans, Glenn Versweyveld and Rujith AnandSo 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?
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.
Reacted by Aleksander Valle Grunnvoll, bkarstaedt, Neno Loje, Glenn Versweyveld, Richard van Zandwijk, Max Cross, Andrei Matracaru, Roberto Prevato, SGrajdean, Wesley Van den Eede and 2 moreThanks 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
Reacted by Sam Hope-Evans and maeiI totally agree what Lauri Helkkula (@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...
Hello, I'm having the same issue.
Is there an ETA for it to be fixed ?Reacted by Neno Loje, Malek Olabi, Lee McMullen and Antoine MilochauThanks to Ross Murray (@RossMurr4y) John Reilly (@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
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 ?
Reacted by Neno Loje, Glenn Versweyveld and algreat2If you are providing the provider, repositoryUrl, and branch then it should be idempotent.
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.Reacted by Glenn Versweyveld, Mike Childs, Max Cross, Wesley Van den Eede and MikeBy the second run, do you mean after you've deployed content to the SWA?
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.Reacted by Mike ChildsI 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.
Reacted by abouroubiCorrect. 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.
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
providerproperty 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?
Reacted by abouroubi and Max CrossThe 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.
Ah, great. We had been using
skipGithubActionWorkflowGenerationalready and we still get the same error (Provider is invalid) when deploying after a successful publish.
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:
From #495, you can solve this error by setting the provider. In this case, the value needs to be
DevOps.In addition to the
providerproperty, you get similar error message for the propertiesbranchandrepositoryUrl.To Reproduce
Steps to reproduce the behavior:
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 viewto see the values. See the example Bicep file below for an exampleExpected 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