-
Notifications
You must be signed in to change notification settings - Fork 24
Add login_type to coder_workspace_owner data source #235 #287
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
All contributors have signed the CLA ✍️ ✅ |
|
I have read the CLA Document and I hereby sign the CLA |
johnstcn
left a comment
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.
That was quick! You'll also need to update the integration tests to expect the new field.
|
Done! |
provider/workspace_owner.go
Outdated
| if login_type := os.Getenv("CODER_WORKSPACE_OWNER_LOGIN_TYPE"); login_type != "" { | ||
| _ = rd.Set("login_type", login_type) | ||
| } else { | ||
| _ = rd.Set("login_type", "none") |
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.
@mtojek should we instead set login_type to an empty string if Coder does not set the required env?
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.
Perhaps at the very least, drop a diag.Warn?
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.
should we instead set login_type to an empty string
This seems reasonable and consistent with other ENV vars. I would start with empty string, we can always revisit it in the future and replace it with none.
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 seems reasonable and consistent with other ENV vars. I would start with empty string, we can always revisit it in the future and replace it with
none.
Great, what about the warn?
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.
Adding a diag.Warn if the CODER_WORKSPACE_OWNER_LOGIN_TYPE environment variable is not present or empty would be a good indication to the user that they have a potential mismatch of the Coder version and provider version.
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.
Sorry, but taking a look to the diag package there is not Warn method.
https://pkg.go.dev/github.com/hashicorp/terraform-plugin-sdk/v2/diag
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.
Sorry! I should have been more specific -- you can append a diag.Diagnostic with severity diag.Warning to the second return argument of type diag.Diagnostics.
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.
Done, this is the first time I have to deal with the diags, so please let me know if this solution is correct 🙏🏼 .
mtojek
left a comment
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.
Thank you for your contribution!
provider/workspace_owner.go
Outdated
| if login_type := os.Getenv("CODER_WORKSPACE_OWNER_LOGIN_TYPE"); login_type != "" { | ||
| _ = rd.Set("login_type", login_type) | ||
| } else { | ||
| _ = rd.Set("login_type", "none") |
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.
should we instead set login_type to an empty string
This seems reasonable and consistent with other ENV vars. I would start with empty string, we can always revisit it in the future and replace it with none.
|
All fixed @johnstcn thanks for your time! |
Co-authored-by: Cian Johnston <public@cianjohnston.ie>
johnstcn
left a comment
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.
Thanks for your contribution!
Note that this won't be useful until coder/coder is updated to set CODER_WORKSPACE_OWNER_LOGIN_TYPE. This will require a separate PR.
This PR add the login type the the
coder_workspace_ownerdata source (Issue #235).I took some decisions (like the default value to
none), but if you think this should be different please let me know.Thanks!