Using inputs with profile inheritance

Hello,

for my specific use case, I have two profiles that depend on a third profile. The controls in the third profile depend on which profile included the controls. That's why I tried to use inputs. I configured inspec.yml like the example at https://docs.chef.io/. When I work with only two profiles (one depends on the other and overwrites the input), it works fine. However, when two profiles overwrite the input, only the last overwritten value is used.
Example:

Profile A and B both depend on C
A defines the input "data" with the value "1" for C
B defines the input "data" with the value "2" for C
C defines a control that checks the input "data" for a certain value

Now when I use 'include_controls' in both A and B to include all the controls of C, only one of the values '1' or '2' is used alone. I have also tried setting the input in the 'include_controls' block of both profiles A and B instead of the metadata (this approach is not documented anywhere), but it results in strange behavior. Using the debugging options described in https://docs.chef.io/, I can see that both 'set' events are still fired for the 'data' input (which is not what I want), but I can't even access the value in C.

I would like that when I include the controls of C in profile A, the value of A ("1") is used for the input 'data', and when I include the controls of C in profile B, the value of B ("2") is used for the input 'data'. Is this somehow possible?

I would like that when I include the controls of C in profile A, the value of A ("1") is used for the input 'data', and when I include the controls of C in profile B, the value of B ("2") is used for the input 'data'. Is this somehow possible?

Are you referring that by including controls of C in profile A and B respectively, you want your tests to compare data value as specified in inspec.yml of each profile A and B?
That means, if you test is like this in control C:

control 'Test control' do
  describe input('data') do
    it { should cmp 3 }
  end
end

And do you want to compare data with value 1 when you run profile_a and with value 2 when you run profile_b?

If yes, then in this scenario profile_c is a wrapper profile and profile_a and profile_b are dependent ones.
And in InSpec input precedence for wrapper profile is greater than dependent profile.

If your scenario is different than what I just mentioned then please add some code snippets too, that will help :slight_smile:

Thank you for your answer!

And do you want to compare data with value 1 when you run profile_a and with value 2 when you run profile_b?

Yes, this is exaclty what I want to do.

If yes, then in this scenario profile_c is a wrapper profile and profile_a and profile_b are dependent ones.
And in InSpec input precedence for wrapper profile is greater than dependent profile.

Okay so I conclude that with the current way inputs work I can't do what I need.

Maybe a little bit about why I need this:
I have common controls which are needed by mutliple profiles. I don't want to copy paste them in every profile and I want that the result of these checks get merged. But the checked data in the common controls is depending on the profile where the common check is implemented e.g.:

Profile A:

control 'Common-1' do
  describe data_a do
    it { should cmp 1 }
  end
end

Profile B:

control 'Common-1' do
  describe data_b do
    it { should cmp 1 }
  end
end

Both data_b and data_a should be compared to the same common value "1". I have several of these common controls and it would be nice to put them in the same profile. The advantage of this would be that the result gets merged:

Profile: InSpec Profile (common)

common-1: Common test 1
  1 is expected to eq "1" -> include_controls in Profile A (data_a)
  1 is expected to eq "1" -> include_controls in Profile B (data_b)

So in the end I get one result for all common controls instead of individual results in every profile where the common controls are used.

Is this possible? Maybe with something different than inputs?

If the value of data_a and data_b is set as 1 in your wrapper profile, which means your profile C then in that case this will be 1. Makes sense?
Because you are using tests which are defined in your profile C and they can not be changed in your profile A and B. They are like included in your profile A and B as it is.
So since you want to run some common tests then it is good to define those values in your common profile which in this case is profile C.

Understood, thank you for your reply.

No problem! Happy to help :slight_smile: