- Notifications
You must be signed in to change notification settings - Fork926
feat: allow new immutable parameters for existing workspaces#18579
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
| originalValue, ok := originalValues[parameter.Name] | ||
| // Immutable parameters should not be changed after the first build. | ||
| // They can match the original value though! | ||
| if parameter.Value.AsString() != originalValues[parameter.Name].Value { | ||
| // If the value matches the original value, that is fine. | ||
| // | ||
| // If the original value is not set, that means this is a new parameter. New | ||
| // immutable parameters are allowed. This is an opinionated choice to prevent | ||
| // workspaces failing to update or delete. Ideally we would block this, as | ||
| // immutable parameters should only be able to be set at creation time. | ||
| if ok && parameter.Value.AsString() != originalValue.Value { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
This is the change. The rest is testing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Would it be a lot of trouble to add a test to cover the scenario mentioned in the issue?
You mean a more e2e test? Like from coderd, template versions, etc? The test I did write is pretty locally scoped to the parameter validation logic. |
Doesn't have to be e2e necessarily;
|
Emyrk commentedJun 25, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Added!aa2a809 Test ran on main failed with: (as expected and matches the issue) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
LGTM!
e396b06 intomainUh oh!
There was an error while loading.Please reload this page.
Closes#18578
This was a somewhat conscience choice to prevent new immutable parameters. In an ideal world, immutable parameters can only be set at creation time. The example to illustrate this is:
us-east1East-1is created.regionsparameter with the defaultus-west1.us-west1. Volumes do not transfer, and this workspace is either broken, or wiped.If we disallow new immutable parameters, then the fix would be to let
regionsbemutable. Push an update, update the the workspace, then make it immutable.Since the workaround has no more protection than the original problem, it's probably best to just allow new immutable parameters. If at some point in the future we allow some first class flow to handling this case, we can change back this enforcement.
Notes