-
Notifications
You must be signed in to change notification settings - Fork 11
Fix input_vars fetching from job options in Job #104
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
196a1b2
to
7aea7db
Compare
3870a9a
to
2167c7c
Compare
:credentials => [], | ||
:credentials => anything, # Authentication.where(credentials), |
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.
I think we should try to match the expected credentials
here not anything and comment this out
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.
Interesting this actually passes with the old []
still was there a reason you changed this?
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.
reverting back to []
It started failing for spy function - https://github.com/putmanoj/manageiq-providers-embedded_terraform/blob/fix-input_vars-in-job/spec/models/manageiq/providers/embedded_terraform/automation_manager/job_spec.rb#L106
in between working on the issue ..., in logs could see credential as ActiveRecord relation, ....
also being credential is empty list .. putting anything
seems to fix it the problem then,
@@ -178,7 +178,7 @@ def input_vars_type_constraints | |||
end | |||
|
|||
def input_vars | |||
options.fetch(:input_vars, {}) |
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.
Why was this not working previously? Was the issue that the input_vars
passed in above had another nested input_vars
? Maybe if you have an example of the previous payload
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.
Okay I see the payload in the issue
:input_vars=>{
"execution_ttl"=>"",
"verbosity"=>"0",
"input_vars"=>{
"name"=>"World"
}
},
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.
Yes, after changes for 'extra_vars' removal , .., as these test were using simulated values ..., tests gave a false positive result
Checked commits putmanoj/manageiq-providers-embedded_terraform@72f7f7b~...18ea6f8 with ruby 3.1.5, rubocop 1.56.3, haml-lint 0.62.0, and yamllint |
Backported to
|
Fix input_vars fetching from job options in Job (cherry picked from commit 08c48c2)
Fix the fetching of
:input_vars
from job options,Fixes #103