az containerapp job start --image <image> voids environment variables

[fardarter]

Describe the bug

When running az containerapp job start with the image tag specified, my job env vars are not retained, but when I simply name the job they are.

The reason I even care is that when I update the job and trigger it the previous container is often run.

Related command

az containerapp job start

Errors

The error is that my environment variables are voided when using the --image flag

Issue script & Debug output

The error is that my environment variables are voided when using the --image flag

Expected behavior

That my environment variables are only voided when I deliberately void them

Environment Summary

azure-cli 2.52.0 *

core 2.52.0 *
telemetry 1.1.0

Extensions:
azure-devops 0.26.0
containerapp 0.3.41

Dependencies:
msal 1.24.0b1
azure-mgmt-resource 23.1.0b2

Additional context

No response

[azure-client-tools-bot-prd]

Hi @fardarter,

2.52.0 is not the latest Azure CLI(2.53.0).

If you haven't already attempted to do so, please upgrade to the latest Azure CLI version by following https://learn.microsoft.com/en-us/cli/azure/update-azure-cli.

[yonzhan]

Thank you for opening this issue, we will look into it.

[microsoft-github-policy-service]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @calvinsID.

[microsoft-github-policy-service]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @calvinsID.

[anandanthony]

This is a known behavior wherein if we have a template property image with the start command, the Container App Job assumes that this is a new template for the job's container. In case the intention is to just update the image and start a job execution with the existing configuration for the job, we would suggest the following steps:

1. Retrieve the current configuration for the job and store it in a YAML file.
2. Update the required properties in the YAML and then start the job with the update YAML template.

The steps are documented in the following article: https://learn.microsoft.com/en-us/azure/container-apps/jobs?tabs=azure-cli#start-a-job-execution-on-demand

We do understand that it can be helpful in certain scenarios that the existing configuration itself is taken by default and only the value for the parameter with the start command is updated. We will look into this approach as well and add a functionality which allows similar behavior in the future.

[fardarter]

@anandanthony

The article isn't clear that when using CLI properties I'm not inheriting the existing job. I'm not using YAML at all (and don't intend to), I'm using azapi with terraform. Why have a set piece job at all if I can't inherit some of the properties? Why not simply have a job execution that runs that passed YAML only?

I feel inheriting settings is the correct default and this behaviour you have should be set by flag.

Regardless, the articles need to be much more explicit.

[SamuelMS]

@anandanthony I agree, this is a strange default; if we want to run a well-known job but override the image to a newer or older version, I'd have expected all of the other configuration to remain in place. Removing all of the environment variables when we don't touch the --env-vars flag is frustrating.

[CharlieDigital]

Chiming in to report that this makes it very tricky to use container jobs in a way that would be useful for kicking off the job with, for example, a specific record ID to process. I found this older related thread: #27023 (comment)

However, that suggested workaround does not seem to work and requires repeating the full --env-vars. What I think many folks want is an additive, one-time variable to be injected for the process.

For example, if I set up my job with the follow vars:

VAR1=a
VAR2=b

And then I run the job:

az containerapps job start ... --env-vars VAR2=x VAR3=y

Then the value x overrides b for VAR2 and VAR3=y is also injected.