-
Notifications
You must be signed in to change notification settings - Fork 677
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
Add support for Code Engine functions #5596
Conversation
hasChange := false | ||
|
||
patchVals := &codeenginev2.FunctionPatch{} | ||
if d.HasChange("project_id") { |
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 block is n't required when you mark ForceNew : true on "project_id" argument
Description: "The name of the function.", | ||
}, | ||
"run_env_variables": { | ||
Type: schema.TypeList, |
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.
Can we use TypeSet .
With TypeList when the order changes in user tf and in state file it always show a diff when more than one element is provided
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.
Is there anything else that would change when switching from TypeList
to TypeSet
or are they mostly interchangeable?
value = "value" | ||
} | ||
|
||
lifecycle { |
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 block is n't required when we use TypeSet.
Adding this block restricts user's to do update of run_env_variables
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 you very much for reviewing our PR. I have a question from our side though. We ignore changes here, because our system injects some run_env_variables
on the server-side, resulting in diffs during testing and obviously from the user's perspective. Users can react by adding those system-generated variables to the definition alongside the user-defined ones.
Are you saying that if we changed it to TypeSet
, Terraform would be able to identify changes in the user-set variables only and ignore outside changes?
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.
No TypeSet doesn't identify the changes . Can we loop , identify system-generated variables before setting back in read method?
Typeset is unordered list so it will help in controlling diff on the order of items in the list
Resolve confiicts in .secretbaseline file |
9d74cd4
to
0d03a89
Compare
I think we use to have same behavior in deprecated function to filter system-defined parameters/annotation terraform-provider-ibm/ibm/flex/structures.go Line 1269 in 7e9da7b
|
Do you think we can get this in September? We are addressing the environment variable issue in a future PR by introducing a new computed env variable field to hold the system-defined env vars. As I mentioned before, this issue is not at all related to the current PR. So, I see no reason to hold the current PR up. The env var fields in functions are not unique to functions and exist in our existing jobs and applications resources as well. |
* Add support for Code Engine functions * update .secrets.baseline * remove unnecessary check
Community Note
Relates OR Closes #0000
Output from acceptance testing: