Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to deploy to a virtual Directory using GitHub action "azure/webapps-deploy" #340

Open
jlara005 opened this issue May 20, 2023 · 15 comments
Labels
backlog Planned for future enhancement New feature or request feature_request

Comments

@jlara005
Copy link

Is there a way to deploy to a virtual Directory using GitHub action "azure/webapps-deploy"? I don't see the equivalent in the GitHub action.

In Azure DevOps you were able to do this:
image

@m1rl0k
Copy link

m1rl0k commented May 22, 2023

need this aswell

@NoCopy
Copy link

NoCopy commented May 24, 2023

You can't currently do this with this action application alone

See #335 & #154

You can workaround this with another action : azure/login

      - name: 'Configure Azure Deployment Target'
        if: ${{ vars.DEPLOY_METHOD == 'AZURE' }}
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}        
        run: az webapp config appsettings set --name ${{ vars.AZURE_WEBAPP_NAME }} --resource-group ${{ vars.AZURE_WEBAPP_RESOURCE_GROUP }} --settings DEPLOYMENT_TARGET=${{ vars.AZURE_DEPLOYMENT_TARGET }} --output none #surpresses WebApp ENV Vars being added to the log see https://github.com/Azure/login/issues/315
      - name: 'Deploy to Azure WebApp'
        if: ${{ vars.DEPLOY_METHOD == 'AZURE' }}
        uses: azure/webapps-deploy@v2
        with:
          app-name: ${{ vars.AZURE_WEBAPP_NAME }}
          publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
          package: ${{ vars.PACKAGE_PATH }}

One thing to note that I didn't make clear is your vars.AZURE_DEPLOYMENT_TARGET should be set to the absolute path with quotes. I was having an issue without the quotes, maybe you can tweak it so that is not needed. (Guessing you need to escape it but I can't remember if I tried that)

In your case it would be something like
"C:\home\site\wwwroot\api"

@va-timorris
Copy link

va-timorris commented May 25, 2023

Hi NoCopy - this did not work for us.

We have one Azure App Service which uses /wwwroot and a Virtual Directory on that App Service that uses /api

We use two Github workflows. One for the web app (/wwwroot) and another one for the API (/api).

What happens is that we can deploy to the virtual directory (/api) in its workflow, but then when we run the web app workflow, it also deploys to the /api folder.

The only way I've gotten this to work is by manually editing the following file in Kudu: D:\home\site\deployments\tools\deploy.cmd

In that file, I set the DEPLOYMENT_TARGET based on the existence of a DLL in the DEPLOYMENT_SOURCE. If the DEPLOYMENT_SOURCE contains the DLL associated with the API, I set the DEPLOYMENT_TARGET to /api. Else if it contains the DLL associated with the Web App, I set DEPLOYMENT_TARGET to /wwwroot

The problem with this approach is that the 'deploy.cmd' file randomly gets reset and I lose my changes to it! I have no idea what is resetting this file.

Below is the relevant YAML for our deployments:

API workflow file

env:
  AZURE_DEPLOYMENT_TARGET: 'D:\home\site\api'

- name: Configure Azure Deployment Target
  uses: Azure/login@v1.4.6
  with:
      creds: ${{ secrets.ATC_DEVTEST_EXT_GITHUB_SP }}
      environment: 'AzureUSGovernment'
      run: az webapp config appsettings set --name ${{ secrets.ATC_APP_NAME }} --resource-group ${{ env.AZURE_RESOURCE_GROUP }} --settings DEPLOYMENT_TARGET=${{ env.AZURE_DEPLOYMENT_TARGET }} --output none

- name: 'Deploy to Azure App Service using DEV publish profile credentials'
  uses: azure/webapps-deploy@v2.2.10
  with:
    app-name: ${{ secrets.ATC_APP_NAME }}
    publish-profile: ${{ secrets.ATC_PUBLISH_PROFILE_API }}
    package: '.'

Web App workflow file

env:
  AZURE_DEPLOYMENT_TARGET: 'D:\home\site\wwwroot'

- name: Configure Azure Deployment Target
  uses: Azure/login@v1.4.6
  with:
      creds: ${{ secrets.ATC_DEVTEST_EXT_GITHUB_SP }}
      environment: 'AzureUSGovernment'
      run: az webapp config appsettings set --name ${{ secrets.ATC_APP_NAME }} --resource-group ${{ env.AZURE_RESOURCE_GROUP }} --settings DEPLOYMENT_TARGET=${{ env.AZURE_DEPLOYMENT_TARGET }} --output none

- name: 'Deploy to Azure App Service using DEV publish profile credentials'
  uses: azure/webapps-deploy@v2.2.10
  with:
    app-name: ${{ secrets.ATC_APP_NAME }}
    publish-profile: ${{ secrets.ATC_PUBLISH_PROFILE_WEB }}
    package: '.'

@NoCopy
Copy link

NoCopy commented May 25, 2023

@va-timorris well your AzureUSGovernment environment is set on both actions so obviously your env.AZURE_DEPLOYMENT_TARGET is going to be the same.

Either use different vars, or different environments.

Sorry, to correct that statement, and this caught me off guard / pissed me off too, but

env:
  AZURE_DEPLOYMENT_TARGET: 'D:\home\site\wwwroot'

Doesn't work when you specify the environment in the action. You need to do that in the github environment.

If anyone can figure out how to merge the env: statement with the github environment, I am all ears.

@va-timorris
Copy link

va-timorris commented May 25, 2023

@NoCopyright

I was under the impression that environment: 'AzureUSGovernment' was just applicable to the Azure Environment I'm logging into. When logging into Azure, we must specify this since our App Services are in Azure Gov. Otherwise it defaults to 'azurecloud' and login fails. I don't think it has to do with Github environment. We don't have a Github environment named 'AzureUSGovernment'.

Also, in your sample code, you're using ${{ vars.AZURE_WEBAPP_NAME }}

Where is this defined? Is there a section in the workflow yaml file like:

vars:
  AZURE_WEBAPP_NAME: '...'

@NoCopy
Copy link

NoCopy commented May 25, 2023

@va-timorris sorry, I might have misunderstood that.

Github does have the concept of different environments. You can go your repo > settings > environments and then specify specific secrets / vars for your specific ENV. I didn't realize this plugin has an environment setting as well.

Anyways, I am guessing you are just using the standard repo vars; which is fine, but like I said, I couldn't get it to work with the env: line.

Try this:

env.AZURE_DEPLOYMENT_TARGET = wwwroot
env.AZURE_DEPLOYMENT_API_TARGET = api

That should get you there. Obviously that was a short example, you still need the full path. (e.g. "D:\home\site\api")

@m1rl0k
Copy link

m1rl0k commented May 25, 2023

Azure_Deploy_api_target is a recognized variable? i thought only setting azure_deploy_target is what it picks up on. i set them, restart in pipeline to make it take effect and run... for the virtual path modify the zip deploy destination url in ur publish profile... aka a pipeline for each api/ and wwwroot with modified zipdeploy destination on each and before deploy set deploy target and restart app. then deploy

@NoCopy
Copy link

NoCopy commented May 25, 2023

for the virtual path modify the zip deploy destination url in ur publish profile

Can't, see #154

Otherwise this wouldn't be an issue.

You can modify the deploy.cmd directly on the server to change the path but when you want to deploy to a virtual directory it gains you nothing. Hence the request to fix this issue.

the only other way is what I posted, a run time modification to the deployment path when you are deploying. And frankly that wasn't even my solution, it was @voltura that figured it out, so credit to them.

@m1rl0k
Copy link

m1rl0k commented May 26, 2023

im using the zipdeploy and msbuild path successfully on publish profile in production on two seperate pipelines deploying to /api and one to /wwwroot; im setting the app config deployment_target each time, deploying and doing a restart. a separate pipeline for each. everything works, the only caveat is you have to rerun the front end deploy 2 times sometimes as a rerun. so not sure what setting the azure_deployment_api_target would do differently, maybe eliminate the redeploy?

these are virtual paths, and modifying the deploy.cmd would not be efficient as im doing this same setup for 12 pipelines and 6 app services each with two virtual paths (api/wwwroot)...

what i have semi works but again, its not consistent.

@NoCopy
Copy link

NoCopy commented May 26, 2023

@m1rl0k Right, sorry, there may be some mixup here. There is no direct AZURE_DEPLOYMENT_API_TARGET on the Azure CLI. There isn't even a AZURE_DEPLOYMENT_TARGET for that matter. Those are just the set vars on the repo. I was assuming that the poster was sharing the repo with the same Vars and thus deploying to the same location because I know changing the deploy target works - as per your experience. yet @va-timorris is saying it doesn't, there must be a difference in the configuration somewhere. @va-timorris if you want help walking through it I certainly can. DM me.

@github-actions
Copy link

github-actions bot commented Jun 9, 2023

This issue is idle because it has been open for 14 days with no activity.

@m1rl0k
Copy link

m1rl0k commented Sep 20, 2023

so; just an update; having the issue now that sometimes the frontend files are being place in the api folder... here is api


    - name: Azure Login
        uses: Azure/login@v1.4.6
        with:
           client-id: ${{ secrets.CLIENT_ID }}
           tenant-id: ${{ secrets.TENANT_ID }}
           subscription-id: ${{ secrets.SUB_ID }}

      - name: Configure App Settings
        run: |
            az webapp config appsettings set --name ${{ env.AZURE_WEBAPP_NAME }} --resource-group ${{ env.AZURE_RESOURCE_GROUP }} --settings DEPLOYMENT_TARGET='C:\home\site\wwwroot\api' > NUL
 
      - name: Deploy to Azure
        id: portal
        uses: azure/webapps-deploy@v2
        with:
          app-name: '${{ env.AZURE_WEBAPP_NAME }}'
          slot-name: 'production'
          publish-profile: ${{ secrets.AZUREAPPSERVICE_PUBLISHPROFILE }}
          package: "${{ env.DOTNET_ROOT }}/myapp"
          
      - name: Restart Web App
        run: |
           az webapp restart --name ${{ env.AZURE_WEBAPP_NAME }} --resource-group ${{ env.AZURE_RESOURCE_GROUP }} > NUL

and here is front end;


    - name: Azure Login
      uses: Azure/login@v1.4.6
      with:
          client-id: ${{ secrets.CLIENT_ID }}
          tenant-id: ${{ secrets.TENANT_ID }}
          subscription-id: ${{ secrets.SUB_ID }}

    - name: Configure App Settings
      run: |
        az webapp config appsettings set --name ${{ env.AZURE_WEBAPP_NAME }} --resource-group ${{ env.AZURE_RESOURCE_GROUP }} --settings DEPLOYMENT_TARGET='C:\home\site\wwwroot' > /dev/null


    - name: Azure App Service Deploy
      uses: azure/webapps-deploy@v2
      with:
        app-name: 'solutions-portal'
        slot-name: 'production'
        publish-profile: ${{ secrets.AZUREAPPSERVICE_PUBLISHPROFILE }}
        package: './dist'
      env:
        VERBOSE_OUTPUT: true

took the restart off the frontend so not sure if this is causing

@va-timorris
Copy link

va-timorris commented Sep 21, 2023

@m1rl0k : in the API workflow, you're piping the az webapp config command like this: > NUL

But in the frontend workflow, you're piping the az webapp config command like this: > dev/null

Is there a reason for this? I've removed piping that command on the end, I just run the command without that stuff on the end.

@pramodmd
Copy link

pramodmd commented Nov 17, 2023

I have the same problem using azure/webapps-deploy@v3.
Perfectly works for default app hosted at wwwroot. Workflow for wwwrooot/app2 fails.
Can't pass virtual-application as input. git action fails with invalid input.
Anyone successfully implemented this? This is basic requirement . We need this funcationality.

@m1rl0k
Copy link

m1rl0k commented Nov 17, 2023

my successful work around was to not use webapp deploy and auth to azure and zip deploy by target that way with pwsh after build artifact.

even with work arounds, kudu will randomly break and deploy ex api to wwwroot visca versa and its just insanity trying to make it work. also, the maintainers of the repo pretty much dont care about this issue for the past year.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backlog Planned for future enhancement New feature or request feature_request
Projects
None yet
Development

No branches or pull requests

6 participants