Github integration with Azure webApps in Old and New portal

[centur]

This is a follow up on this twitter chat with @davidebbo : https://mobile.twitter.com/davidebbo/status/782768419917602816

This issue is not Kudu related, but Old\New Azure portal. I tried to use forum as adviced but it asks me to somehow verify my account ( but doesn't offer any links or options to do that). So I gave up and decided to raise an issue on Kudu repo as discussed.

It's pretty long lasting (I think it's at least 3-4 months old) problem and I know the solution for it. Just want to bring it back to light and I hope it will be fixed soon.

The context to the problem:

1. We have a github organisation with private repos
2. We have a special Continuous integration account "drawboard-ci" that we are using for our devops needs. This account doesn't have any personal repositories, but has access to the GH repositories in our organisation.
3. We are setting up Azure Web Apps from time to time and want to deploy them from github repositories. This is a known deployment option in Old (manage.windowsazure.com) and New (portal.azure.com) Azure management portals.

The problem is: Currently it's impossible to set up Github integration from the New portal - for a linked github account there is no repositories visible in the blade :

Old portal shows correctly all repositories but create 2 entries per each repository available to the devops account:

Technically - to solve the issue we can continue using old portal but given that everything being pushed to a new portal - it would be nice if new portal can finally get this working properly. I tried to sign-out and change account in the new portal - this doesn't solve the issue.

Google chrome in the network tab shows a call which is probably a cause - GetScmInfo always returns 304 - Not modified :

Old portal uses different endpoints to retrieve the data so GetgithubProjects fetches the actual data (but duplicates it):

Regards, Alexey

[davidebbo]

Let's ignore the old portal for now.

Questions:

• Is 'drawboard-ci' a normal user account, or something special?
• What permission does that account have in that org? Specifically, if you log in as that account, are you able to go to Settings / WebHooks under one of those private repos?

[centur]

Ok, easy.

• drawboard-ci is a usual account,
• Member of the org, not an admin or anything.
• Member of one team (which is not used for granting any access, more like a silo-group)
  • 2FA is Off.
  • Has a special symbol in it's name - ":)"
  • Doesn't have any public or private repositories on it's own.
  • Collaborator on both projects it has access to.
  • Can access to Settings \ Webhooks. Can add \ remove \ edit webhooks there.
  • Has 3 authorized applications in the profile

Azure Management Portal - Primary Last used within the last day · Owned by Azure
Azure Management Portal - Secondary Last used within the last day · Owned by Azure
Windows Azure - Secondary Last used within the last day · Owned by WindowsAzure

[centur]

Also just found an interesting fact about these 3 autorized applications :

[centur]

Seems that the "Secondary" access request was a culpit - I re-requested it on behalf of drawboard-ci and granted it - and now everything is working in the new portal.

Why there is 3 different app access requested by 2 different portals. Also it'd be nice to make App names a bit more dev-friendly: Primary and Secondary are a bit confusing names and there is no correlation of what this app is going to do or from which part of Azure Portal this integration is coming from.

No surprise some other admin may accidentaly revoke or deny the initial request for "Azure Management Portal - Secondary".

[davidebbo]

@Tuesdaysgreen @suwatch do you recognize those 'Azure Management Portal - Primary' and 'Azure Management Portal - Secondary' applications?

[centur]

Another interesting observation - new project doesn't appear in the list until I grant admin rights on the repository (which I don't like to do) to drawboard-ci account or any team this account is in. I'm doing it as part of the 'devops' team but I wish it wouldn't requre an admin rights.

Upd: I tried to grant write only rights to the team - and the repository disappears from the list. Is there any special permission that is missing from default write group now ?

[davidebbo]

@centur continuous deployment cannot be set up unless the account has the ability to add a WebHook and a Deploy Key, and that requires admin. So that part is entirely by design.

The only quirk left here is I think the dual Primary/Secondary apps which I'm not familiar with myself but others could explain.

[centur]

As a side note - would be nice to see some hints\links to FAQ on why projects may not appear in the list. Half of the questions above can be made into bullet points like :

• I can't see any org projects in this list
  • Please check that Github Admin granted authorization for your app to access Org repository.
• I added account as a collaborator but project doesn't appear in the list
  • We need rights "Deploy Key" and "Add a Webhook" in that account so Kudu can set up initial integration
• Can I revoke permissions after integration is set up / Can I downgrade permissions to reader\collaborator
  • Yes, you can \No, this account still need access to A/B/C to work correctly.

[xt0rted]

Though not directly related, an issue I've run into that would be useful on a list like that is if you remove source control deployments to make a change (such as to switch the branch) you need to manually delete the webhhook in GitHub otherwise it'll continue to fail with a non-descript error. I've run into this a few times now.

[ehamai]

We added the primary and secondary applications as a way to roll over the secrets without breaking everyone during the change process. @suwatch can explain in better detail, but I think that even though we regenerated the secrets for both applications, we still need to keep both around because some customers's client secrets are tied to the old application id.

[suwatch]

@suwatch can explain in better detail, but I think that even though we regenerated the secrets for both applications, we still need to keep both around because some customers's client secrets are tied to the old application id.

We do keep both applications around and never remove them. This is part of Key Rollover process.

Another interesting observation - new project doesn't appear in the list until I grant admin rights on the repository (which I don't like to do) to drawboard-ci account or any team this account is in. I'm doing it as part of the 'devops' team but I wish it wouldn't requre an admin rights.

Many of your questions were answered here. For instance, the above is required due to recent changes by GitHub. We can definitely improve on UI to suggest what to do when the repository list is empty, @Tuesdaysgreen? For instance, one has to be admin or has to one-time approve the oauth application.

[centur]

@suwatch Great wiki article, I wish I knew about it beforehand. I had the described issue for months ( not really configured GH deployments very often, but every time I did - it was a mini-battle and all of them ended up in the old portal). Even a link to it on the Website deployment page would help a lot.

[davidebbo]

Agreed, discoverability of this info is poor. @Tuesdaysgreen maybe we can have link from portal just like we already do in the VSTS case?

[ehamai]

That's a good idea. Let me log a bug on our side.

[jvano]

Hi

If the problem persists and is related to running it on Azure App Service, please open a support incident in Azure: https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request

This way we can better track and assist you on this case

Thanks,

Joaquin Vano Azure App Service