We have our frontend and our backend in Azure and we linked the production environment to our backend successfully. As we deploy this SWA using the default GitHub Action, we were wondering how one would specify the Backend Resource Name. We can link it manually in Azure, but only for static environments. How would one do this for all environments? The docs don't really mention anything here.
- name: Build And Deploy
id: builddeploy
uses: Azure/static-web-apps-deploy#v1
with:
deployment_environment: 'develop'
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
repo_token: ${{ secrets.GITHUB_TOKEN }}
action: "upload"
Related
I have a GitHub Action that uses azure/docker-login#v1 for building and pushing images to the Azure image registry, and it works.
Now, I want to pass GITHUB_TOKEN using Docker's secret flag, but it only accepts a file, and I don't know how to create a file using this action.
Is it possible?
For example, with docker/build-push-action I can do this bellow
- name: Build docker image
uses: docker/build-push-action#v2
with:
context: .
secrets: |
"github_token=${{ secrets.GITHUB_TOKEN }}"
How can I secure my image using azure/docker-login?
As the readme.md of the azure/docker-login action suggests:
Use this GitHub Action to log in to a private container registry such as Azure Container registry. Once login is done, the next set of actions in the workflow can perform tasks such as building, tagging and pushing containers.
You can setup your workflow so that it logs in using azure/docker-login and builds and pushes the image using docker/build-push-action, like this:
- uses: azure/docker-login#v1
with:
login-server: contoso.azurecr.io
username: ${{ secrets.ACR_USERNAME }}
password: ${{ secrets.ACR_PASSWORD }}
- uses: docker/build-push-action#v2
with:
push: true
context: .
secrets: |
"github_token=${{ secrets.GITHUB_TOKEN }}"
I'm trying to deploy an Azure Functions Linux app using Github Actions. I've used the Deployment Center in the Azure Portal to connect my Github to enable CICD. Now that goes fine, but I want to use Playwright in my Azure Function, so I need to enable scm-do-build-during-deployment: true. I've added this setting to my workflow yaml, but then the deployment doesn't work anymore. I also added some other settings, which I came across when I searched the interwebs. Now this is the yaml I have:
# Docs for the Azure Web Apps Deploy action: https://github.com/azure/functions-action
# More GitHub Actions for Azure: https://github.com/Azure/actions
name: Build and deploy Node.js project to Azure Function App - app-name
on:
push:
branches:
- main
workflow_dispatch:
env:
AZURE_FUNCTIONAPP_PACKAGE_PATH: "." # set this to the path to your web app project, defaults to the repository root
NODE_VERSION: "16.x" # set this to the node version to use (supports 8.x, 10.x, 12.x)
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- name: "Checkout GitHub Action"
uses: actions/checkout#v2
- name: Setup Node ${{ env.NODE_VERSION }} Environment
uses: actions/setup-node#v1
with:
node-version: ${{ env.NODE_VERSION }}
- name: "Resolve Project Dependencies Using Npm"
shell: bash
run: |
pushd './${{ env.AZURE_FUNCTIONAPP_PACKAGE_PATH }}'
npm install
npm run build --if-present
npm run test --if-present
popd
- name: "Run Azure Functions Action"
uses: Azure/functions-action#v1
id: fa
with:
app-name: "app-name"
slot-name: "Production"
package: ${{ env.AZURE_FUNCTIONAPP_PACKAGE_PATH }}
publish-profile: ${{ secrets.AZUREAPPSERVICE_PUBLISHPROFILE_A5413AC6097F4B21B4A709C270747826 }}
scm-do-build-during-deployment: true
enable-oryx-build: true
respect-funcignore: true
I also added the setting to my application settings in Azure, but to no avail. Furthermore, I added this setting: WEBSITE_RUN_FROM_PACKAGE=0 to the app settings.
Is there anything else I should try?
In the YAML the uses tag is not aligned with the name and the other tags
- name: "Run Azure Functions Action"
uses: Azure/functions-action#v1
id: fa
Add PLAYWRIGHT_BROWSERS_PATH in app settings with its value set to zero.
Rest remains the same and I was able to deploy the function.
I was hoping to link my Azure static web app to a function using the Bring your own function feature. However, I don't see the option for my web app:
I have set the api_location to a blank string when deploying the app via GitHub Actions:
- name: Build And Deploy
id: builddeploy
uses: Azure/static-web-apps-deploy#v1
with:
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
repo_token: ${{ secrets.GITHUB_TOKEN }}
action: 'upload'
app_location: '/'
api_location: ''
What am I missing?
I was using the free plan, and Bring your own functions requires the standard plan. Once I change the hosting plan, the option became available.
While trying to deploy a simple site in Azure got this error message after deployment:
:( Application Error
If you are the application administrator, you can access the diagnostic resources.
How to solve this problem?
As you are using CI/CD to deploy your application, In the deploy task remove the slot name and replace the package with application file. Below are the samples:
From:
- name: 'Deploy to Azure Web App'
uses: azure/webapps-deploy#v2
with:
app-name: 'hello-world-app-to-delete'
slot-name: 'production'
publish-profile: $
package: .
To:
- name: 'Deploy to Azure Web App'
uses: azure/webapps-deploy#v2
with:
app-name: 'hello-world-app-to-delete'
publish-profile: $
package: ./dist/hello-world-app
For more information refer to this GIT blog
And to figure out what is the problem you can enable diagnostics logs in apps for azure app service. Also we can monitor our apps with Azure Application Insights.
Is it possible to use the webapps-deploy action to deploy into a specific path of the web app (and not just into wwroot)? For example deploying into a IIS virtual directory under wwwroot/app.
Current yaml GitHub action configuration, can't find a property here for setting a requested path on the web server.
- name: "Run Azure webapp deploy action using publish profile credentials"
uses: azure/webapps-deploy#v2
with:
app-name: MyApp
publish-profile: ${{ secrets.SECRET_PROFILE }}
package: build
Image showing the Virtual Application (wwwroot/app) I'd like to deploy into
With many times testing, I found it's not possible using Git Action. But you can consider using Visual Studio, importing publish profile.
First, set the virtual path in portal.
Downloads the publish profile. You will use the content of publish profile.
Modify the profile. Change msdeploySite's value from Your-Site to Your-Site\folder\subfolder, such as msdeploySite="dorissub\app". Change destinationAppUrl's value from http://xxx.azurewebsites.net to http://xxx.azurewebsites.net/app
Publish from VS.
Check the sub folder. it works.
Here is how I do using Git Action.
Add secret. Go to your GitHub repository settings and add a secret with the content of publish profile as the value, name it as AZURE_WEBAPP_PUBLISH_PROFILE.
Run workflow with this yaml file:
name: .NET Core dorisxxx
on: [push]
env:
AZURE_WEBAPP_NAME: dorisxxx # set this to your application's name
AZURE_WEBAPP_PACKAGE_PATH: '.' # set this to the path to your web app project, defaults to the repository root
DOTNET_VERSION: '3.1.x' # set this to the dot net version to use
jobs:
build:
runs-on: ubuntu-latest
steps:
# Checkout the repo
- uses: actions/checkout#master
# Setup .NET Core SDK
- name: Setup .NET Core
uses: actions/setup-dotnet#v1
with:
dotnet-version: ${{ env.DOTNET_VERSION }}
# Run dotnet build and publish
- name: dotnet build and publish
run: |
dotnet restore
dotnet build --configuration Release
dotnet publish -c Release -o '${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/myapp'
# Deploy to Azure Web apps
- name: 'Run Azure webapp deploy action using publish profile credentials'
uses: azure/webapps-deploy#v2
with:
app-name: ${{ env.AZURE_WEBAPP_NAME }} # Replace with your app name
publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }} # Define secret variable in repository settings as per action documentation
package: '${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/myapp'
But the project still published to wwwroot...
Maybe you should choose another way to deploy.