I'm trying to update a Github Actions Script that publishes to Azure Web Apps and I added a Private Link to the Web App in question - causing me to substantially update the Script. But I'm still seeing errors.
I initially saw an error addressing the fact that my app uses a private link and as a result, I can no longer deploy the same way I previously been doing. The Article is here: https://azure.github.io/AppService/2021/03/01/deploying-to-network-secured-sites-2.html
Here is a portion of the Github Actions Script:
deploy:
runs-on: ubuntu-latest
needs: build
environment:
name: 'Production'
url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
steps:
- name: Azure Login
uses: azure/login@v1
with:
creds: ${{ secrets.AZURE_CREDENTIALS }}
- name: Download artifact from build job
uses: actions/download-artifact@v2
with:
name: java-app
- name: Zip the app contents
uses: papeloto/action-zip@v1
with:
files: app.jar
dest: app.zip
- name: Set SAS token expiration
run: echo "expiry=`date -u -d "$EXPIRY_TIME" '+%Y-%m-%dT%H:%MZ'`" >> $GITHUB_ENV
- name: Azure CLI script
uses: azure/CLI@v1
with:
azcliversion: 2.19.1
inlineScript: |
az extension add --name webapp
echo "Added Extension"
az storage container create -n $CONTAINER --account-name $ACCOUNT --resource-group $BASE_GROUP
echo "Created Container"
az storage blob upload -f app.zip --resource-group $BASE_GROUP --account-name $ACCOUNT -c $CONTAINER -n $ACCOUNT
echo "Blob Upload Step Completed"
ZIP_URL=$(az storage blob generate-sas --full-uri --permissions r --expiry ${{ env.expiry }} --resource-group $BASE_GROUP --account-name $ACCOUNT -c $CONTAINER -n $ACCOUNT | xargs)
echo "ZIP_URL Created"
az webapp deploy --name $WEBAPP --resource-group $TEST_GROUP --type zip --src-url $ZIP_URL --async false
echo "Deployment Completed"
az storage container delete -n $CONTAINER --account-name $ACCOUNT
And here is the output I'm currently seeing:
Run azure/CLI@v1
Starting script execution via docker image mcr.microsoft.com/azure-cli:2.19.1
WARNING: The installed extension 'webapp' is in preview.
Added Extension
WARNING: There are no credentials provided in your command and environment, we will query for the account key inside your storage account.
Please provide --connection-string, --account-key or --sas-token as credentials, or use `--auth-mode login` if you have required RBAC roles in your command. For more information about RBAC roles in storage, visit https://docs.microsoft.com/en-us/azure/storage/common/storage-auth-aad-rbac-cli.
Setting the corresponding environment variables can avoid inputting credentials in your command. Please use --help to get more information.
ERROR: Client-Request-ID=a4d42790-c7ab-11ee-b92c-0242ac110002 Retry policy did not allow for a retry: Server-Timestamp=Sat, 10 Feb 2024 00:30:50 GMT, Server-Request-ID=b66b9e8f-901e-0075-6bb8-5bd530000000, HTTP status code=404, Exception=The specified resource does not exist. ErrorCode: ResourceNotFound<?xml version="1.0" encoding="utf-8"?><Error><Code>ResourceNotFound</Code><Message>The specified resource does not exist.RequestId:b66b9e8f-901e-0075-6bb8-5bd530000000Time:2024-02-10T00:30:51.5358190Z</Message></Error>.
ERROR: The specified resource does not exist. ErrorCode: ResourceNotFound
<?xml version="1.0" encoding="utf-8"?><Error><Code>ResourceNotFound</Code><Message>The specified resource does not exist.
RequestId:b66b9e8f-901e-0075-6bb8-5bd530000000
Time:2024-02-10T00:30:51.5358190Z</Message></Error>
Error: Error: az cli script failed.
cleaning up container...
MICROSOFT_AZURE_CLI_(number)_CONTAINER
Error: az cli script failed.
The issues occur in the final step. Could the messages on Credentials being missing as seen in the early lines of the output be related to the Resource Not Found Error? If so, How can I ensure that when the CLI Step Runs, authentication works correctly and I don't see the Credential message? If Not, why isn't it seeing the Storage Account? I'm confident it exists.
Notes: The Storage Account is in one resource group and the web app is in a different resource group. I have a Service Principal created and referenced in the Azure Login step that has the contributor for both resource groups. In theory, the Azure Login step should help the Azure CLI Script step authenticate and verify the existence of that storage account. Clearly, at least one of these is not happening.
I also added echo statements to the CLI Script, which is how I know the az storage container create -n $CONTAINER --account-name $ACCOUNT --resource-group $BASE_GROUP
command is what is causing me issues.
How to Fix Azure CLI Task That Uses GitHub Actions and Gives Resource Not Found Errors
I agree with Azeem's comment. To use GitHub Action for Azure CLI, you need to use Azure's latest version.
Script:
deploy:
runs-on: ubuntu-latest
needs: build
environment:
name: 'Production'
url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
steps:
- name: Azure Login
uses: azure/login@v1
with:
creds: ${{ secrets.AZURE_CREDENTIALS }}
- name: Download artifact from build job
uses: actions/download-artifact@v2
with:
name: java-app
- name: Zip the app contents
uses: papeloto/action-zip@v1
with:
files: app.jar
dest: app.zip
- name: Set SAS token expiration
run: echo "expiry=`date -u -d "$EXPIRY_TIME" '+%Y-%m-%dT%H:%MZ'`" >> $GITHUB_ENV
- name: Azure CLI script
uses: azure/CLI@v1
with:
azcliversion: 2.56.0
inlineScript: |
az extension add --name webapp
echo "Added Extension"
az storage container create -n $CONTAINER --account-name $ACCOUNT --resource-group $BASE_GROUP
echo "Created Container"
az storage blob upload -f app.zip --resource-group $BASE_GROUP --account-name $ACCOUNT -c $CONTAINER -n $ACCOUNT
echo "Blob Upload Step Completed"
ZIP_URL=$(az storage blob generate-sas --full-uri --permissions r --expiry ${{ env.expiry }} --resource-group $BASE_GROUP --account-name $ACCOUNT -c $CONTAINER -n $ACCOUNT | xargs)
echo "ZIP_URL Created"
az webapp deploy --name $WEBAPP --resource-group $TEST_GROUP --type zip --src-url $ZIP_URL --async false
echo "Deployment Completed"
az storage container delete -n $CONTAINER --account-name $ACCOUNT
You can use the azcliversion: 2.56.0
or, if you remove the azcliversion argument, it will automatically take the latest CLI version.
Reference: