In the previous post we discuss how to setup a Windows Node to test PowerShell code. In this post, we’ll configure a new Jenkins project to test some very basic PowerCLI code.
To start, we need to have some basics setup on our Windows Node that we setup previously as a slave. In our case, we need to make sure that we have PowerCLI installed on the host. Let’s think about this logically for a second. Jenkins is going to tell our Windows node to execute some PowerCLI scripts as a test. If the Windows node doesn’t understand PowerCLI, then our tests just won’t work. I would suggest that you install PowerCLI on your Windows node and then do a quick test to make sure you can connect to your vCenter server.
Once those pre-requisites are complete, lets setup a new project. On the Jenkins homepage click “New Item”. Then give the project a name and choose the “Freestyle project” option.
For the code that I’m running, I need to pass a username and a password into the script that is used to later connect to my vCenter server. To do this I click the “This build is paramaterized” option in the Jenkins project. Then I add a pair of parameters. The first one will be a “Password Parameter” which we can select from the drop down list. The second parameter is just a string.
When all of my parameters have been added they’ll show up in the project and look something like this.
Next, we need to ensure that when we try to run this job, that it doesn’t run on the local node since it’s a Linux server and we clearly need Windows to run PowerShell. To do this select the “Restrict where this project can be run” box and then in the Label Expression window enter the name of our Jenkins Windows node.
Next we scroll down and add a build step. Here we’ll select the “Windows PowerShell” build type. Next I’ve added my code to the step and you can see it listed below. Notice that there are two variables listed in the code and we’ve accounted for them in the project already. Also notice that at the end of the script we’re exporting some info to a CSV file.
Run the Job
When you execute the job, there is an opportunity to change the values of the parameters or leave them as their defaults.
The job should execute and you can review the job and console log to see how it ran. Also, in the script we just executed, it should have exported a CSV file, which we can find on our Jenkins Windows node.
This is another brief post about how you can use Jenkins to test your code. It’s a simplified project to get you familiar with the tool. You may be thinking to yourself, “why is this better than just running it on a windows server and then storing it in GIT?” Well, in the next post we’ll show how Jenkins can be integrated with GIT. Once we do that, you’ll see the real value of these continuous integration tools to automatically test code when it gets pushed to your code repository.