I have a puppet cookbook rspec sample test like below
it {
is_expected.to contain_file('/etc/resolv.conf')
.with(
'ensure' => 'file',
'owner' => 'root',
'group' => 'root',
'mode' => '0444',
'validate_cmd' => '/var/tmp/checkdns_nameservers.sh',
)
.with_content(resolvconf_contents)
.that_notifies('Service[sshd]')
.that_notifies('Service[nscd]')
}
The problem is that this just checks the existence of validate_cmd in the manifest.
I have to mock the validate_cmd function and returns true/false and Based on that I have to check the contents of the file newly created.
How can I mock the validate_cmd command using rspec module ?
Any help would be highly appreciated !!
The short answer is, it is not possible, and you would need to use a tool like Beaker, Test Kitchen etc.
For a longer answer, I direct you to the Rspec-puppet tutorial:
There are a lot of people confused by the purpose of these tests as they can’t test the result of the manifest on a live system. That is not the point of rspec-puppet. Rspec-puppet tests are there to test the behaviour of Puppet when it compiles your manifests into a catalogue of Puppet resources.
The key point is Rspec-puppet never applies the catalog that it compiles; it only inspects the compiled catalog and allows you to make assertions about what is there. But to observe the behaviour in response to differences about what your validate_cmd does, you do need to apply the catalog on a real system.
Of course, it won't be trivial to set up systems in Beaker or Test Kitchen such that your script will return two different values either. Besides, what would you really be testing. Aren't you testing whether Puppet itself does what it promises to do? If so, you really shouldn't try to test that.
Or, is this a script that you wrote yourself? If so, consider using a Bash unit testing framework like shunit2 or BATS instead. Prove, instead, that your shell script behaves the way you expect it to in response to the OS.
Related
Disclaimer: I can achieve the behavior I’m looking for with Active Choices plugin, BUT I really want this to work in a Jenkinsfile and controlled with scm because it’s tedious to configure the Active Choices on each job we may need them on. And with it being separate from the Jenkinsfile creation, it’s then one job defined in multiple places. :(
I am looking to verify if this is possible, because I can’t get the syntax right, if it is possible. And I haven’t been able to find any examples online:
pipeline {
environment {
ARTIFACTS = lib.myfunc() // this works well
}
parameters {
choice(name: "Artifacts", choices: ARTIFACTS) // I can’t get this to work
}
}
I cannot use the function inline in the declaration of the parameter. The errors were clear about that, but it seems as though I should be able to do what I’ve written out above.
I am not home, so I do not have the exceptions handy, but I will add them soon. They did not seem very helpful while I was working on this yesterday.
What have I tried?
I’ve tried having the the function return a List Because it requires a list according to the docs, and I’ve also tried (illogically) returning a String in the precise syntax of a list of strings. (It was hacky, like return "['" + artifacts.join("', '") + "']" to look like ['artifact1.zip', 'artifact2.zip']
I also tried things like "$ARTIFACTS" and ${ARTIFACTS} in desperation.
the list of choices has to be supplied as String containing new line characters (\n): choices: 'TESTING\nSTAGING\nPRODUCTION'
I was tipped off by this article:
https://st-g.de/2016/12/parametrized-jenkins-pipelines
Related to a bug:
https://issues.jenkins.io/plugins/servlet/mobile#issue/JENKINS-40358
:shrug:
First, we need to understand that Jenkins starts running your pipeline code by presenting you with Parameters page. Once you've set up the parameters, and pressed Build, then a node is allocated, variables are set, and your code starts to run.
But in your pipeline, as presented above, you want to run some code to prepare the parameters.
This is not how Jenkins usually works. It's definitely not doing the following: allocating a node, setting the variables, running some of your code until parameters clause is reached, stopping all that, presenting you with GUI, and then continuing where it left off. Again, it's not how Jenkins works.
This is why, when writing a new pipeline, your first option to build it is Build and not Build with Parameters. Jenkins hasn't run your code yet; it doesn't have any idea if there are any parameters. When running for the first time, it will remember the parameters (and any choices, if were) as were configured for this (first) run, so in the second run you will see the parameters as configured in the first run. (Generally, in run number n you will see the result of configuration in run number n-1.)
There are a number of ways to overcome this.
If having a "somewhat recent" (and not "current and absolutely up-to-date") situation fits you, your code may need minor changes to work — second time. (I don't know what exactly lib.myfunc() returns but if it's a choice of Development/Staging/Production this might be good enough.)
If having a "somewhat recent" situation is an absolute no-no (e.g. your lib.myfunc() returns the list of git branches, and "list of branches as of yesterday" is unacceptable), then your only solution is ActiveChoice. ActiveChoice allows you to run some code before showing you the Build with Parameters GUI (with script approval etc.).
We are using the roles pattern in puppet with hiera, meaning we have these lines in hiera.yaml:
- name: "Roles data"
path: "roles/%{::server_role}.yaml"
We have a custom fact that produces the role name when facter runs, but we would like to move this into hiera. Instead of the server_role variable being produced by facter, we want to specify the server_role inside of hiera, and let that variable be referenced elsewhere in hiera. Something like this:
hiera.yaml:
- name: "Per-node data"
path: "nodes/%{trusted.certname}.yaml"
- name: "Roles data"
path: "roles/%{lookup(server_role)}.yaml"
nodes/hostname.yaml:
server_role: foo_bar
I have seen this question, which says to use hiera() or lookup() but when I try to use those, I get this error message:
Interpolation using method syntax is not allowed in this context
So how can I use a hiera variable that's defined elsewhere in hiera?
Edit:
The prototypical code examples for defining roles could use any fact that's known to facter, often giving examples that are based on hostname. When you can't embed server config into hostname, a common(ish) workaround is to write a file such as /etc/server_role, but it seems to defeat the purpose of config management, when you need to ssh into a machine and edit a file. As the other comments & answer here so far mentioned, you could use an ENC, but again, the goal here is not to have config stored outside of version control. In fact, we have foreman as an ENC and we make a practice to never use it that way because then upgrades and other maintenance become unsustainable.
We could write a class which will pick up data from hiera, write it to /etc/server_role, and on the next puppet run, facter will pick that up and send it back to hiera, so then we'll have the server_role fact available to use in hiera.yaml. As gross as this sounds, so far, it's the best known solution. Still looking for better answers to this question.
Thanks.
As #MattSchuchard explained in comments, you cannot interpolate Hiera data into your Hiera config, because the config has to be known before the data can be looked up.
If you need a per-role level in your data hierarchy then an alternative would be to assign roles to machines via an external node classifier. You don't need it to assign any classes, just the server_role top-scope variable and probably also environment.
On the other hand, maybe you don't need a per-role level of your general hierarchy in the first place. Lots of people do roles & profiles without per-role data, but even if you don't want to do altogether without then it may be that module-specific data inside the module providing your role classes could be made to suffice.
I see the SMT test suite has a 'comment' attribute and also see that atp gem generally supports a test level description. Which should I use to add a line in the rendered SMT flow file? The following does not work when called from here:
func :my_func, comment: "make a comment"
thx
A description is intended to be a meta-documentation of the test, meaning it is potentially long and not rendered to the generated program. Instead it would be used in documentation, that is outlined here - https://origen-sdk.org/origen/guides/program/doc/
This comment attribute directly maps to the comment field in the test program, it does not by default contain the description/documentation though you could probably set it up like that.
When creating a test suite the comment should be picked up. If you are not seeing it in the generated flow, then it probably means that your interface layer is not forwarding that comment option to the test suite creation.
So, either pass the options along when you are calling test_suites.add, or else set it in the test suite object like this: my_test_suite.comment = options[:comment].
We have introduced the PDK lately into our developments chain and are now trying to make everybody happy with the test outputs it generates.
We need an output as JUnit test report for our jenkins jobs. That we have solved.
And we need the output still on the console because some of the developers find it very annoying having to open the JUnit report file before they can see failed tests.
pdk test unit --format=junit:report.xml
Is how we configured the output for JUnit.
Unfortunately as soon as you configure the JUnit report no output gets printed on the console/stdout anymore. Even if you add another format like --format=text without target file.
Is there a way to achieve both without running the PDK twice?
It doesn't appear to be in the docs, but this should work.
pdk test unit --format=junit:report.xml --format=text:stdout
See https://github.com/puppetlabs/pdk/blob/7b2950bc5fb2e88ead7321c82414459540949eb1/lib/pdk/cli/util/option_normalizer.rb#L10-L24
I've filed a ticket to ensure that gets promoted to the docs at https://puppet.com/docs/pdk/1.x/pdk_reference.html#pdk-test-unit-command
From PDK documentation
--format=[:]
Specifies the format of the output. Optionally, you can specify a target file
for the given output format,
such as --format=junit:report.xml . Multiple --format options can be
specified as long as they all have distinct output targets
So I believe ,you can try as below
pdk test unit --tests=testcase_name --format=junit:report.xml --format=text:log.txt
Hope it helps.
I have a cucumber feature file 'A' that serves as setting up environment (data clean up and initialization). I want to have it executed before all other feature files can run.
It's it kind of like #before hook as in http://zsoltfabok.com/blog/2012/09/cucumber-jvm-hooks/. However, that does not work because my feature files 'A' contains hundreds of cucumber steps and it is not as simple as:
#Before
public void beforeScenario() {
tomcat.start();
tomcat.deploy("munger");
browser = new FirefoxDriver();
}
instead it's better to be able to run 'A' as a feature file as a whole.
I've searched around but did not find a answer. I am so surprised that no one has this type of requirement before.
The closest i found is 'background'. But that means i can have only one huge feature file with the content of 'A' as 'background' at the top, and rest of my test in the same file. I really do not want to do that.
Any suggestions?
By default, Cucumber features are run single thread in order by:
Alphabetically by feature file directory
Alphabetically by feature file name within directory
Scenario execution is then by order within the feature file.
So have your initialization feature in the first directory (alhpabetically) with a file name that sorts first (alphabetically) in that directory.
That being said it is generally a bad practice to require an execution order in your feature files. We run our feature files in parallel so order is meaningless. For Jenkins or TeamCity you could add a build step that executes the one feature file followed by a second build step that executes the rest of your feature files.
I have also a project, where we have a single feature file, that contains a very long scenario called Scenario: Test data with a lot of very long scenarios, like this:
Given the system knows about the following employees
|uuid|user-key|name|nickname|
|1|0101140000|Anna|annie|
... hundreds of lines like this follow ...
We see this long SystemKnows scenarios as quite valuable, so that our testers, Product Owner and developers have a baseline of what data are in the system. Our domain is quite complex, and we need this baseline of reference data for everyone to be able to understand the tests.
(These reference data become almost like well known personas, and are a shared team metaphore)
In the beginning, we were relying on the alphabetic naming convention, to have the AAA.feature to be run first.
Later, we discovered that this setup was brittle, and decided to use the following trick, inspired by the PageObject pattern:
Add a background with the single line Given(~'^I set test data for all feature files$')
In the step definition, have a factory to create the test data, and make sure inside the factore method, that it is only created once, like testFactory.createTestData()
In this way, you have both the convenience of expressing reference setup as a scenario, that enhances team communication, but you also have a stable test setup.
Hope this is helpful!
Agata