I just can’t stop playing around with the Jenkins JCasC plugin. However, I just don’t think its in a state to replace all of your Jenkins configuration yet.
Example – I want to create a new Jenkins user\password and add the additional user data such as email, token, and description with the JCasC plugin.
You are currently only able to automate the username and password, and that is it.
- id: "builduser"
If you try adding the additional attributes, its going to fail. Checking the code seems to confirm the only available values are username and password.
Anyways, I will be following this plugin very closely. Probably even test it out more…
I’m still playing around with this Jenkins JCasC plugin. Its got major potential!!
One little gotcha if you are on Windows is how you path out to the jenkins.yaml file from within Jenkins. In my case, I was using standard Windows back slash.
This isn’t going to work. You need to use forward slashes in the Path text box.
I have been doing a little research on the Jenkins Configuration as Code (JCasC) plugin and I must say I think it’s definitely a step in the right direction.
In theory, with this plugin, you can have the majority of your Jenkins configuration stored in 1 file. This file can then be put in source control, which would allow you to easily rebuild your Jenkins instance at anytime.
However, while playing around with the plugin, a couple things came to my mind.
- It was hard for me to determine the correct syntax that needed to go into my jenkins.yaml file. There are examples located here, but these weren’t enough for me to get moving quickly.
- Long term, it could be a bit cumbersome to make all changes in the yaml file correctly, then re-apply to Jenkins instances.
- If the examples and plugin mature more, this is surely a easy way for teams to fail-safe\share their Jenkins configuration
- Fixing or growing the jenkins.yaml export functionality would greatly help. This would essentially allow you to apply Jenkins changes manually, then export to see the correct yaml syntax.
Anyways – This is a cool plugin that I am surely looking forward to using in the future!
Here is one way to add some data redundancy to your Jenkins instance. The solution below won’t auto recover, but the data itself should be safe if your active Jenkins master fails.
The following are some key points not really mentioned in the beautiful Google Docs created chart above!
- A dedicated file system is created on the NAS that is attached to each Jenkins master server
- The NAS has snapshot backups enabled for X number of days on this file system
- The same user and group is created on both master servers
- The group ID must be the same on both master servers
- groupadd -g <unique_id> <group_name>
- The new user’s home dir should be on the NAS under the dedicated file system and the user should own it
- /etc/passwd – home dir
- chown – change ownership
- Tomcat is installed from 1 master server to the NAS
- Jenkins is installed from 1 master server to the NAS
- Tomcat is only kept running from 1 master server
- A load balancer like HAProxy can be used for active\passive load balancing
Some other recovery recommendations.
- Store all Jenkins job scripts in Git and setup your jobs to pull the latest scripts from Git a execution time
- Implement the Sync Jenkins plugin. This plugin will push all job\config changes to Git for easy recovery.
Lets say I am in need of a private Git repo for a small 3 – 5 person team…. Where should I look?
For this blog post I looked at GitHub and VSTS. Below is the pricing for both.
From the links above, you will notice that VSTS is the better deal. Its basically free, plus it includes many additional features!
So, I know I can connect my Jenkins instance to GitHub, but can I connect Jenkins to my VSTS Git repo? The answer is yes and it’s basically the same process as connecting to GitHub
- Create your public\private keys with ssh-keygen
- Add your public key to VSTS
- Create “SSH Username with private key” Jenkins credential
- User private key from #1 here
- Use this new credential when configuring Git in your new job
Now you will probably want your new Jenkins job to launch when changes are made to the VSTS Git repo.
Below are some of the options you have with Jenkins and VSTS
I must say that Microsoft is really pushing out some cool products!
So you would like to execute tests using Selenium against a Website. Below are 3 ways that you can execute Selenium for testing.
Selenium via Firefox.
- You must have Firefox installed.
- You will need the Selenium IDE add-on
- After installing the add-on, you should restart FireFox and verify the Selenium tool installed properly.
- Now you can open the IDE from Firefox. From the IDE you can record a test case or load an existing test case\test suite to execute. (If creating a new test case, save as testcase.html)
- Below is a simple test case for demonstration purposes. (control\shift\c to inspect element id’s on the given webpage)
Selenium via CMD.
- Before we run the test case from the command line, we must create a test suite html file that calls the test case html file. (Great link below)
- Now you will need to download the Selenium server jar (e.g. 2.45)
- If you are downloading the 3.0 Selenium jar, you will also need to download the latest geckodriver to support Firefox with Selenium 3. (exe must be in your path)
- With the files in place on your computer, you can execute the following command to launch the test case.
- java -jar selenium-server-standalone-2.53.1.jar
- -“htmlsuite” “*firefox”
- “http://www.google.com “GoogleTestSuite.html”
Selenium via Jenkins.
- If you know Jenkins, you know that you can launch commands above using the Windows batch command.
- You can also use the following plugin to configure\launch your test suite via Jenkins
- Finally, the above link contains information on an Ant task that can also be used in your build scripts to launch tests. (Haven’t tried it, but it looks cool)
How easy is it to deploy Jenkins using Docker? On a scale of 1 to 10, I would say something between 2 – 4.
Here are the quick steps you can follow (along with links) to help you get the job done!
- First and foremost, you need to get Docker installed on your server. Here is a good link I would recommend.
- Next you will want to go to the Docker Store and search for Jenkins.
- Click on the “1” returned result
- Follow the instructions on the page to pull the image and run your Jenkins container
- I would recommend persisting your Jenkins data by specifying a volume when you start up\run the Docker Jenkins container.(-v /your/home:/var/jenkins_home)
- -v, –volume=[host-src:]container-dest[:<options>]: Bind mount a volume