Azure / Azure/azure-cli-extensions
`az containerapp revision copy` returns provisioningState:Succeeded even if container fails to start
- Dominant language
- Python
- Stars
- 454
- Forks
- 1.7k
- Avg merge
- 2d 19h
- Merged PRs (30d)
- 64
Description
### Related command
`az containerapp revision copy`
### Extension name (the extension in question)
containerapp
### Description of issue (in as much detail as possible)
Setup: container app, running in *single instance mode*.
Isssue: CDCI deploys to that container instance. If a container fails to start, `az containerapp revision copy` reports `{"provisioningState": "Succeeded"}`back, even though container failed to provision. Since success is reported back, CICD pipeline continues. It seems like revision copy worked, hence success, the goal was not successful (a new running revision).
Running in multi revision mode, `az containerapp revision activate` does the activation.
Expected outcome: deploying a revision to an container app running in single instance mode, should not return provisioningState=succeeded if deployment fails.
Repro
Create an image that throws an unhandled exception:
```csharp
if(mySettings.MyNumber==5)
throw new Exception($"Bad error by Henrik: {mySettings.MyNumber}");
app.Run();
```
Run az
```
json="$( az containerapp revision copy -n "${containerapp}" -g "${resourceGroupName}" --cpu 0.5 --memory 1.0Gi --set-env-vars MySettings__MyNumber=5 )"
echo "${json}" | jq > ./deployment_status.json
```
The only workaround which seems to be available is to inspect the response from `az containerapp revision copy` to see if `latestReadyRevisionName != latestRevisionName`. If that is the case (!=), then you still need to verify by calling `az containerapp revision list -n "${containerapp}" -g "${resourceGroupName}" ` and then again test the same properties for the lastest deployment.
```json
"latestReadyRevisionName": "xxx--su93uxl",
"latestRevisionName": "xxx--7ip72po",
```
Full script that will test if container succeeded.
```bash
resourceGroupName=somecontainertest-we23
containerapp=somecontainertestapp-we23
json="$( az containerapp revision copy -n "${containerapp}" -g "${resourceGroupName}" --cpu 0.5 --memory 1.0Gi --set-env-vars MySettings__MyNumber=1 )"
echo "${json}" | jq > ./deployment_status.json
latestRevisionName="$( echo "${json}" | jq -r .properties.latestRevisionName )"
latestReadyRevisionName="$( echo "${json}" | jq -r .properties.latestReadyRevisionName )"
provisioningStateFromNewDeployment="$( echo "${json}" | jq -r .properties.provisioningState )"
echo "copy revision \"${latestRevisionName}\" status: \"${provisioningStateFromNewDeployment}\" )"
if [ $latestRevisionName == $latestReadyRevisionName ]; then
echo $"All good! This is what i want: ${latestRevisionName},${latestReadyRevisionName}. Devops pipeline can continue."
else
echo "Issue: latestRevision is NOT the latestReadyRevisoin. That means, what was just deployed is not ready (IT SEEMS FROM THE 'az containerapp revision copy' RESPONSE ) ${latestRevisionName} ${provisioningState}"
echo "But dont trust 'az containerapp revision copy' response. Look at az containerapp revision list, and see if the container just deployed is actually ready"
revisionList="$( az containerapp revision list -n "${containerapp}" -g "${resourceGroupName}" )"
echo "${revisionList}" |jq > revisionlist.json
provisioningState="$( echo "${revisionList}" | jq ".[] | select(.name == \"${latestRevisionName}\" ) | select( .properties.active==true) | .properties.provisioningState " | sed 's/.//;s/.$//' )"
echo "${latestRevisionName} ${provisioningState}"
if [ $provisioningState != "Provisioned" ]; then
echo $"Error, latestrevision (just deployed) is not the same as latestreadyrevision. Latest: ${latestRevisionName} Ready: ${latestReadyRevisionName}"
echo $"'az containerapp revision list' ALSO failed.. Stop pipeline"
# exit 1
else
echo $"'az containerapp revision list' shows that the deployment actually succeeded. So, pipeline can continue "
fi
fi
```
-----
Contributor guide
Research direction
Start with the `az containerapp revision copy` entry point and run the supplied single-instance repro, comparing `provisioningState`, `latestRevisionName`, and `latestReadyRevisionName`. Use `az containerapp revision list` to verify the new revision's state; done means a failed container startup is not reported as a successful deployment.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, python
- Domain
- cli, cloud
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100