AzureFunctionAppV1 and AzureRmWebAppDeploymentV4 fail when used with Management Group Service Connection

[cstrempfer]

Copied from #13779, because it was closed incorrectly and nobody reopened it since 3 months.

Justification:

1. Service Connections support Management Groups
2. App Service Tasks support Service Connections
3. App Service Tasks fail if used with a Management Group Service Connection
   => Bug, because it isn't compatible with the Azure Pipelines' standard and users cannot fix it themselves

Required Information

Question, Bug, or Feature?
Type: Bug?

Enter Task Name: AzureFunctionAppV1 and AzureRmWebAppDeploymentV4

Environment

• Server - Azure Pipelines

  • If using Azure Pipelines, provide the account name, team project name, build definition name/build number: not specific to our environment....

• Agent - Hosted

  • If using Hosted agent, provide agent queue name: Azure Pipelines

Issue Description

When using the two mentioned tasks to deploy a WebApp/FunctionApp we get the error: "'subscriptionId' cannot be null" when using a Management Group Service connection. Checking the code both tasks don't support the subscriptionId yet. Using the tasks with the normal Subscription Level Service connection works fine.

Task logs

##[error]Error: 'subscriptionId' cannot be null.

Error logs

##[error]Error: 'subscriptionId' cannot be null.

[cstrempfer]

It could be easily avoided if there would be an optional "subscriptionId" parameter in addition to the "azureSubscription" parameter (which is actually pointing to a service connection), and if its value would be applied in case that a service connection with Management Group is selected. If you put this logic into "InitializeAzModuleFunctions.ps1" you could use the same mechanism for other Pipeline Tasks as well, because I've seen other bug reports for similar issues.

[20shivangi]

@cstrempfer As pointed out earlier, Management Group service connection will not work for deploying to a web app. Since Management Group service connection does not take subscription id while creation but for deploying to resources like a web app, we do need the subscription id.
And for your idea of being having an optional "subscriptionId" parameter in case of Management Group service connection, we will reach out to PMs and confirm about this requirement.

[cstrempfer]

@20shivangi I'm not sure we are on the same page here, because I don't know which PMs you mean (those of the Service Connection or those of the Tasks?). Service connections should not have an additional subscription id, because that would defeat the purpose of using management groups in service connections. My suggestion was to add a subscription id to the pipeline tasks, so that it can handle both kinds of service connections.

Trying to put the subscription id anywhere else would ignore increasing adoption of management groups. I created this as a bug, because there is no obvious reason for not supporting Management Groups already and because there is no documented limitation.

[20shivangi]

@cstrempfer I totally agree what you said "Service connections should not have an additional subscription id, because that would defeat the purpose of using management groups in service connections."

What I am saying is that , having an optional "subscriptionId" parameter in addition to the "azureSubscription" parameter (which is actually pointing to a service connection), and its value would be applied in case that a service connection with Management Group is selected, we will confirm this with our PMs about this.

[KZeronimo]

@20shivangi any update on this - in general, the Tasks ecosystem needs to catch up with management group scoped service connections - AzureResourceManagerTemplateDeployment@3 is a good pattern with a clear separation of the required params

azureResourceManagerConnection for the service connection
and
subscriptionId for the subscription id

[github-actions]

This issue is stale because it has been open for 180 days with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days

[nadesu]

• @v-jkarri for visibility, @vijayma for prioritisation

[github-actions]

This issue is stale because it has been open for 180 days with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days

[cstrempfer]

Still waiting for a solution...

[SamBonavika]

Allow me to add my 2 cents:

Half of Microsoft pushes really hard to promote a top-down strategy for managing policy and security ...

Half of Microsoft pushes really hard to "empower" the Azure DevOps user community to create truly dynamic CI/CD pipeline implementations ...

But unfortunately, these two halves never seem to intersect, leaving those of us who really really REALLY want to invest in the entire MS tech stack out in the cold pulling our hair and gnashing our teeth in ABJECT FRUSTRATION!!!!

Please escalate this issue to a Tech PM who has actually USED these products and who understands how the omission of a seemingly trivial feature can result in such chaos to the user community.

[FinVamp1]

Hi, I am following up on this request and will come back to you on this thread.

[Codemagedon]

@FinVamp1 do we have any updates for this, those of us in the MSP and SI space are really interested in a working product here and I am personally really bored of writing workaround PowerShell scripts or having to directly scope to a subscription.

[FinVamp1]

Hello,

This is an enhancement for the agent overall that the team is tracking. Adding @geekzter to help

[github-actions]

This issue is stale because it has been open for 180 days with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days

[cstrempfer]

Another year passes by ...

[steve-carlson]

Wondering how this is still an issue that has been left unresolved by MS. A comment that is over a year old at this point by SamBonavika could not be more spot on yet there is absolutely no response to these challenges and concerns which makes this even more frustrating.

[FinVamp1]

Hello, I'm following up with the Azure DevOps to help understand if there is another work item tracking overall Task Support for Management Group Service Connections as opposed to implementing for specific Tasks as asked in this item.

[FinVamp1]

@geekzter Can you update this work item with the plans for this?

[FMERI001]

Any word from MS on this issue?

[FinVamp1]

Updated the labels and my assignment. @geekzter can follow up on this.