Open
Description
The deploy-to-azure-app-service
workflow does everything in a single job. If you want to re-deploy some code, you have to run it all again, including the build. This is not necessary, though, and only the deployment itself has to be run.
This can be achieved by splitting the workflow into two jobs: everything to produce the deployable binaries, and the deployment itself. The first job can upload the binaries as an artifact, and the second one can download it. The latter will also be possible to rerun individually (until the artifact doesn't expire).
- Split the workflow after the
Compress Publish Package
step. - The artifact retention days should be configurable, like it is for the
build-and-test-orchard-core
workflow, with a 7-day default.
The below workflow, generated by Azure for a Web App, implements this principle. You can use it for inspiration.
name: Build and Deploy to Azure
on:
push:
branches:
- main
workflow_dispatch:
jobs:
build:
runs-on: ubuntu-24.04
permissions:
contents: read
steps:
- uses: actions/checkout@v4
- name: Set up .NET Core
uses: actions/setup-dotnet@v4
with:
dotnet-version: '8.x'
- name: Build with dotnet
run: dotnet build --configuration Release
- name: dotnet publish
run: dotnet publish -c Release -o "${{env.DOTNET_ROOT}}/myapp"
- name: Upload artifact for deployment job
uses: actions/upload-artifact@v4
with:
name: .net-app
path: ${{env.DOTNET_ROOT}}/myapp
deploy:
runs-on: ubuntu-24.04
needs: build
environment:
name: 'Production'
url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
steps:
- name: Download artifact from build job
uses: actions/download-artifact@v4
with:
name: .net-app
- name: Deploy to Azure Web App
id: deploy-to-webapp
uses: azure/webapps-deploy@v3
with:
app-name: 'orcharddotnet'
slot-name: 'Production'
package: .
publish-profile: ${{ secrets.AZUREAPPSERVICE_PUBLISHPROFILE_4FE0CF1DE8714910989348B2AF6EDB6D }}