Replies: 2 comments 8 replies
This would improve the user experience! I'm curious if we need a manual override, so that users can easily publish different templates with different version tags. Let's say we know that a published revision
Do you think that we could support a nested structure, so that it bundles all version properties together under |
I don't see why not! |
Would this instead be a use-case for rolling back to a previous template version? |
|
Rolling-back to the previous template can help here if it doesn't mean that it will nuke the latest template version. Let's say we want to keep it for debugging purposes. Maybe it's an edge case, but I remember that I struggled a bit with emergency fixes applied to Docker |
|
+1 Our company is using Artifactory and migrating from Coder v1 to v2. Being able to get tags dynamically is a feature we would really like to see as well. |
|
You mean to get all tags for an image from the registry,,? |
|
Yes. In Coder v1 when users click to create a new workspace, they get a screen where they can select an existing image source and then select a tag. They have reported to me that the Git integration dynamically updates the tags from Artifactory. The feedback I received after setting up a v2 cluster was that they want to deploy the images they use for Airflow into Coder by just selecting the image and a tag. When we spoke with support, they mentioned this might be a new feature that will get added eventually. It would greatly speed up our developer's adoption of the new platform. We may be able to accomplish this by modifying their current workflow. I just have not had time to investigate it. |
|
There is a related issue that is no more being worked on I guess. kreuzwerker/terraform-provider-docker#204 |
|
Created a new request: kreuzwerker/terraform-provider-docker#524 |
|
There is now a native data source to fetch tags for an image. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
In the docker-image-builds example template](https://github.com/coder/coder/tree/main/examples/templates/docker-image-builds#updating-images) template, there is a manual required step of updating the image tag in the Terraform code. Without this step, the Terraform provider doesn't rebuild the image.
What would make intuitive sense here is to provide a data source that exposes the template version identifier to the provisioner so that the manual step above becomes automated:
There are some other use-cases I can also see this enabling though:
I'd imagine the schema to look something like the following:
name(string) The name of the templateid(string) The UUID of the templateversion_id(string) The UUID of the active template versionversion(string) The SHA-like representation of the active template version IDversion_friendly(string) The human-readable UUID (e.g. fantastic_narwhal7) of the active template version IDThoughts?
All reactions