Closed chriswangelin closed 1 year ago
@chriswangelin Hey Chris, apologies for the delayed response; the task is currently using the az containerapp up
command to support both creating and updating a Container App, and it looks like it differs from something like az containerapp create
, which allows the user to provide a --container-name
argument to specify the name of the container.
Let me relay this feedback to the folks who own the az containerapp
module and see what their plans are for supporting additional arguments surrounding the container in the az containerapp up
command. Thanks!
@cormacpayne Cormac, thank you for your reply. I corrected my original post; the last bit should read "...rather than updating container "Y"'s image". Apologies for any confusion.
I noticed az container app update
supports the --container-name
argument. If it turns out that az container app up
won't support that argument in the reasonably-near future, perhaps update
could be called if the container already exists.
@chriswangelin Hey Chris, that's a good callout -- the az containerapp create
and az containerapp update
commands are more specific scenario commands that are bundled into the az containerapp up
command we use (which acts as a lighter weight create/update command). I'll sync with the Container Apps folks responsible for these commands and see what their plans are for up
, but worst case scenario we could integrate these create
and update
commands to provide additional control over the user's Container App. I'll keep you posted -- thanks!
Also having to work around this issue. would appreciate a fix.
@chriswangelin @derSchtefan Hey folks, we just released version 1.0.0
of the AzureContainerAppsRC
task, which now has support for YAML configuration files that specify properties of the new or existing Container App. Within this file is a properties.template.containers
property that allows you to define a list of containers used by your Container App, the images they reference, the container name, and more.
We recognize this is not the same as directly exposing the container name as an argument of the task, but supporting this YAML configuration file allows us to expose all settable properties of the Container App without needing to have an exact 1:1 mapping between arguments and properties for the task.
Please feel free to give the AzureContainerAppsRC@1
task a try with this new YAML configuration file and let us know if you have any additional questions or concerns. Thanks!
Would it be possible to add a parameter for specifying the target container?
This would support scenarios where a single container app has: 1) multiple containers 2) a single container that is named differently than the container app
The task appears to assume that the target container app will contain a single container named the same as the container app itself. So, when I run the task against container app "X" that has a single container "Y", it creates a second container named "X" alongside "Y" rather than updating container "Y"'s image.