Step 2: Configuring Jenkins

Step 2: Configuring Jenkins

Jenkins is one of the major part in setting up Poor Man’s CI. Lets look into how Jenkins can be configured and how can we make it automate task.

Jenkins can be downloaded for the OS you are using from their website. After downloading the mistake that I did was using Jenkins with Global Credentials, as pointed by lsedlar on the channel, because of this I was not able to get the “Trigger by URL” option in the project.

Initial configuration is pointed by lsedlar in his blog. I will be covering extra configuration to have it working for local development. First and foremost being the authentication , this can be done by  Manage Jenkins –> Configure Global Security. Selection_013


Give Read, View and Discover to anonymous and add another user and give all the permission to that user. You need to restart Jenkins service.

sudo systemctl restart jenkins.service

On web ui jenkins will ask you to sign in ,  create a user with the username you gave all the permission and log in with the user. Now add New Item  and create a Freestyle Project. Now configure the project , click on  “This build is parameterized” and configure it according to Poor Man CI’s. Once that is done, select the option as shown below:


Once that is done you can use this token to trigger build using a POST request. The trick is you need to pass parameters too with the URL. Next thing is you need to tell Jenkins what to do and where to do. Since we are dealing with Jenkins and git we need a local repo or some URL to the git repo. For every operation carrying out in the repository the directory should have the group and user set to jenkins else you cat just put the repo in /var/lib/jenkins.

Download and install Git Plugin for Jenkins. Once that is done you need to point the git plugin to the repository you are going to test.


Once jenkins know where to perform action you need to tell what to perform this is done in the build section of the configuration and select Execute Shell.

if [ -n "$REPO" -a -n "$BRANCH" ]; then
git remote rm proposed || true
git remote add proposed "$REPO"
git fetch proposed
git checkout origin/master
git config --global ""
git config --global "Your Name"
git merge --no-ff "proposed/$BRANCH" -m "Merge PR"

We are almost done, the last thing is we need an auth token for the user. Go to Manage Jenkins –> Manager User. Now get the api token for the user. Make sure that branch you are passing as parameter exists in the repository. Lets trigger the build using cuRL.


API Token: 728507950f65eec1d77bdc9c2b09e14b



curl -X POST http://fhackdroid:728507950f65eec1d77bdc9c2b09e14b@localhost:8080/job/pagureExp/buildWithParameters\?token\=BEEFCAFE\&REPO\=file:///$\{JENKINS_HOME\}/new_one_three\&BRANCH\=checking\&cause\=200

Part 1: Setting Up Fedmsg

Part 1: Setting Up Fedmsg

I was trying to make Poor man’s CI work for local development. Since it has been written in a way that it has been put to productions directly. So I started to talk about it in fedora-admin channel, I got a lot of input from pingou and lsedlar.

Finally, I tried to divide the task into various parts the first one was making fedmsg work on my system locally. Fedmsg is way in which application talk to each other in Fedora infrastructure. A message contains a lot of information about the changes in the application.

Well setting up was a big problem for me because the version of fedmsg being installed was throwing a segment fault whenever it tried running fedmsg-tail. I pinged Sayan regarding this issue, we worked a lot over it finally the solution we found was using virtualenv and installing a specific stable version of fedmsg which was :

        pip install fedmsg==0.16.4

Now, since fedmsg now got properly set up , fedmsg has to take messages from my local Pagure, fedmsg-relay is a service which binds two ports one where the message is being emitted and the other where it has to be listen to.

If a project doesn’t have a fedmsg.d/<somefile>.py  then fedmsg will take inputs from /etc/fedmsg.d/ , in my case fedmsg-relay was using the latter location so I modified that file a bit to get message from my local instance.

In a different terminal we can run fedmsg-tail  –really-pretty to see the messages. Any change being done to any repo in local Pagure instance is now being logged.


With these changes I was able to configure in such a way that I can see my local instance emitting messages on fedmsg.

Tip: Using virtualenv wrapper its an amazing tool to manage various virtualenv. And most of the projects comes with a convention that has install and develop option.