CODEWITHSUNDEEP
githubazure-web-app-service
vinhddinh
vinhddinh

Reputation: 21

Cannot redeploy to staging after swap to production using Azure App Service

I'm running into an issue with Azure App Service using deployment slots. I have two slots: one for staging and one for production.

Here's the problem: It seems like the GitHub deployment key/connection is tied to the actual instance and not the deployment slot. This means when I deploy to staging and then swap with production, I'm unable to redeploy to staging.

I've already tried a few things to remedy this, including checking the deployment settings and app configurations, but there does not seem to be anything about tying github credentials to slot vs instance. The issue persists, and I still cannot deploy to the staging instance (previous prod) after swapping.

I can disconnect and connect again, but that would work once, and break again after swapping.

The strange part? If I swap back, it works fine again. It's as though the GitHub connection is swapping along with the underlying instances.

Is there a way to tie the deployment key to the slot, and not the instance?

Anyone else encountered this or have a solution? Thanks in advance!

Upvotes: 0

Views: 197

Answers (1)

vinhddinh
vinhddinh

Reputation: 21

At the end, I found a workaround by creating an additional 'temp' slot. Interestingly, the staging slot would always show a connection to GitHub even when it lacked the necessary credentials. Here's the step-by-step process I undertook:

  1. I first created this 'temp' slot and linked it to the GitHub repository, which allowed this slot to have its own GitHub deploy key.
  2. Next, I swapped this 'temp' slot with my original staging slot.
  3. The result of this swap was that both the production and staging slots now had valid deployment keys, but the staging slot was the only one configured for deployment from GitHub.
  4. I deleted the 'temp' slot as it was no longer required.

This process resulted in two visible deploy keys in my GitHub repository, corresponding to the production and staging slots. While this approach is essentially a workaround, it successfully addressed the issue, and both slots retained their deploy keys after the swap. Also, I'm not sure why this is even an issue in the first place.

Upvotes: 0

Related Questions