]]>https://blog.tom-krieger.de/2018/04/06/sonne-und-wolken-im-april/feed/0340Jenkins build pipelines and PHP Unit tests and what Docker can do for youhttps://blog.tom-krieger.de/2018/03/07/jenkins-build-pipelines-and-php-unit-tests-and-what-docker-can-do-for-you/
https://blog.tom-krieger.de/2018/03/07/jenkins-build-pipelines-and-php-unit-tests-and-what-docker-can-do-for-you/#respondWed, 07 Mar 2018 14:27:23 +0000https://blog.tom-krieger.de/?p=236Some time ago I didn’t like Jenkins Pipelines at all. I preferred to concatenate Jenkins jobs by triggering one Job after the other in a job chain using the build triggers. Together with the Build Flow Plugin you get a good overview of the job chain. This workes like a charm and I like the approach. I know about the bugs and flaws of the Build Flow Plugin but I accept that.

But then I updated my environment to Jenkins 2 and I came over the Pipelines again. I got curious and started reading about the Pipelines because I could use them instead of the Build Flow Plugin and use them instead of concatenating Jenkins jobs with build triggers. After some reading, for me Pipelines are some kind of „Software defined Builds“. And the idea to have a build script written in Groovy was quite nice. You can develop scripts and have all the possibilities of a modern programming language like conditions, try/catch blocks and so on.

At the same time I wanted to make my PHP project ready for PHP 7. But how to make sure to not break anything by updating database drivers or changing code to run in PHP 7? I remembered from former Java projects I was involved that there are unit tests. And luckily there are unit tests for PHP as well. I started to get familar how unit tests in PHP work and what you can do.

Unit tests can cover database functionality as well. But there are some prerequisites to run unit tests on databases. You need a database with the database schema created before starting the unit tests and for sure you need test data which you have to load into the database to have a well defined environment to run the tests with reproducable results. My first approach was to create a test database on a database server, create the schema and run the tests. But my PHP project supports MySQL and PorgreSQL. So I would need two test databases. And as always I have no suitable PostgreSQL installation available.

Why not combine Jenkins Pipelines, PHP unit tests and Docker? A MySQL/MariaDB Database can run in a Docker container and a PostgreSQL database can run there as well. Why not use dockerized MySQL/MariaDB and PostgreSQL? I decided to use database containers without created database inside. The database schema I will create after the database is running in the Docker container. And why not put the PHP application into a Docker cotainer as well and bundle it with a database to make tests easier. For that I use a Docker compose file bundling application and database comtainers together.

And that’s the point Jenkins Build Pipelines come into play. With Groovy I have a programming language which I can use to catch errors and use conditions to run the job depending on job parameters. As in my opinion scripted pipelines have less limitations than declarative ones, I started to dig into Groovy and scriptes pipelines. Luckily there is a snippet generator in Jenkins included to help starting scripting wit generating snippets.

Pipeline example

The picture shows the pipeline I setup for my PHP project. Let’s dig a little bit deeper. One of my favourite features is that I can run things in parallel in the pipeline as I did before with the concatenated Jenkins Jobs. The above pipeline breaks as soon as one of the stages fails. Before stopping some cleanup will be done depending on the stage to break and a nitification will be sent to inform about the build failure.

]]>https://blog.tom-krieger.de/2018/03/07/jenkins-build-pipelines-and-php-unit-tests-and-what-docker-can-do-for-you/feed/0236Puppet augeas and sudoers parameter listshttps://blog.tom-krieger.de/2018/03/06/puppet-augeas-and-sudoers-parameter-lists/
https://blog.tom-krieger.de/2018/03/06/puppet-augeas-and-sudoers-parameter-lists/#respondTue, 06 Mar 2018 14:53:47 +0000https://blog.tom-krieger.de/?p=227Today I had little problems with Puppet’s augeas. I tried hard to find some documentation helping me out but did not find anything suitable. So I think I’m not the only one facing that problem so I want to share what I did.

I want to change the /etc/sudoers file on Linux system with Puppet. What I want to do is negate the requiretty default and add SSH_AUTH_SOCK to the env_keep list.

My first problem was the requitetty setting. I tried a lot until I got a working solution. The problem was the value needed in the Puppet augeas set statement. I developed the following solution:

Above you can see the settings for env_keep which I want to change. I want to add SSH_AUTH_SOCK at the end of the list. And I only want to add the value once and not with every Puppet run. So I need a possibility to check if the setting is already done. To achive this, there is an „onlyif“ statement you can add to the augeas call. But it was a little bit difficult to find a way how to do it because

match /files/etc/sudoers/Defaults/env_keep not_includes SSH_AUTH_SOCK

won’t work. The reason why it is not working is that the match returns a list of env_keep lines.The not_included checks the return value of the „match <arg>“ command which is a list in our case.

After figuring out the problem with the match art I found asolution to get it work:

Finally I succeeded. But it costs me a lot of time for Googling and trying out things. So I hope this short documentation will help anyone else to get a quicker solution and save time for anybody else.