This is part 3 in a series. If you are not familiar with Jenkins, please read Part 1 and Part 2 first.
This walkthrough should give you an overview of the Freestyle Project.
Our first Jenkins job we will set up is to run Drupal Cron every hour, with a 1 hour throttle.
Jenkins — Drupal Cron
From the main menu select New Item
Enter a Name for the job and select Freestyle Project, click OK at the bottom of the form.
You should now be on the config screen.
Check Discard Old Builds, cleaning up older builds will help the admin interface perform better. You can choose between Days or Number of Jobs to keep.
Check Build periodically, this sets the schedule for the build. Jenkins cron system adds a ‘H’ symbol. This is a hashed value based on the job name.
H * * * * Would once an hour
H H * * * Would once a day
H H(0-7) * * * means some time between 12:00 AM (midnight) to 7:59 AM.
In the Build section choose Add build step and Execute shell
On your Drupal site navigate to /admin/config/system/cron and copy the cron URL
End the command text box enter the wget -O - -q -t 1 https://example.com/cron.php?cron_key=drupalkey7hSsc7QtW3lpANY9VxP2O
Save and Build now. If all went well the job will be successful.
While curl works for cron, you will need ssh for more robust remote work. Using SSH Agent Pluginyou can add ssh keys per project, folder or globally. If you have access to ssh in to the server it’s best to add the trusted_hosts via sudo su -l jenkins (setup is beyond the scope of this article).
If you do not have shell access you can use -o StrictHostKeyChecking=no for the first run of the job. Removing the flag after you have verified connection will ensure the remote server has not changed.
Our second in the Using Jenkins for Drupal and WordPress series, we will cover the interface and a few key administration settings. ReadPart 1 – Installation
Jenkins interface out to the box can look utilitarian to some if you are not used to it. There are also elements of confusion as it can change or disappear based on the type of page you are on or plugins you have installed.
When you first start Jenkins you will be greeted with this welcome screen
On the left side of the screen, you will find the Main Menu, Build Queue and Build Executor Status
New Item – Brings up the job type selection page. People – Listing of people Jenkins is aware of. This could be users with a password or names it has pulled from git commits. Build History – Timeline and list view of the job build history. Manage Jenkins – Admin and configuration settings for the system, adding plugins, managing users, and permissions. Credentials – Quick link to the values you have setup. Here you can add ssh keys, APT tokens, and other settings. Values can be used in your Jobs and pipeline scripts. Build Queue – Jobs waiting to be run. Build Executor Status – Active Jobs
For now, we will just cover the Configure System area, where you will make the bulk of the system-wide changes and the Manage Plugins.
There are four tabs on the plugin page Updates, Available, Installed and Advanced. The sections are self-explanatory, I myself have not found a need to change any settings in the Advanced tab. I encourage you to explore and read about the available plugins and try a few out on a testing environment.
Here are a few settings I use and update as needed including Slack notification and core settings.
Maven Project Configuration Section:
\# of executors – The number of jobs Jenkins can run at one time. For what we are doing you will need at least 2. If you want to run parallel testing you will want to run 4 or more. Labels – When running multiple Jenkins instances in master/slave Labels allow you do ‘tag’ where a process or job is run. Quiet period – When this option is checked, newly triggered builds of this project will be added to the queue, but Jenkins will wait for the specified period of time before actually starting the build. SCM checkout retry count – When working with git how often should Jenkins retry checkout.
Checking on the Environment variables setting will expose the list of variables configured. Names are usually all uppercase i.e. LIVE_SERVER_PATH, USERNAME,
Using Environment variables are a good idea for security items like DeployBot API Keys or for items that could change like remote IP addresses.
Jenkins Location Section:
Jenkins URL – The URL for Jenkins server System Admin e-mail address – Email address of the admin
Global Slack Notifier Settings
I recommend adding the Jenkins App Base URL – If you are using the Slack Jenkins Bot the URL Integration Token Credential ID – create a secret text entry using the token from Slack, the ID should lowercase no spaces, the Description is free-form text.
Is Bot User? – Checked
The next post we will cover building your first job.
Continuous Integration (CI) at a high level is testing every code push from each developer, every time. While this sounds like an argues task, it does not have to be. Drupal and WordPress both have tools available that can help you test your code.
With Behat you can “walk” through your site one scenario at a time. You can fill out forms as a user would. Check for the existence of text on a page, even limit it to a pre-defined region of your site like the #footer. You can also log in a user with a specific role to test the admin or user function.
Of the three I am covering here, PHPUnit is the most involved. Each module or plugin you write needs a compatible test written. In this case, each class is proven to work with the test data provided. From the results, you can be ensured the new code has not broken the site. IMO the best way to work with PHPUnit is to use Test Driven Development (TDD); where you start with a failing test and write the code needed to get it to pass.
These three methods are only some of the tests you can run on your site but they cover the bulk of changes made by the development team. Testing your code as you go ensures a better product and allows you to act quickly if an issue arises; most times before it goes live.
This is the first in a series on Using Jenkins for Drupal and WordPress. Over the next few posts I will cover which plugins to use, server-side software needed, how to back up the remote database, testing each commit and more.
Jenkins is an open source automation server which enables developers around the world to reliably build, test, and deploy their software.1
The commands that I will be using have been tested using Ubuntu 16.04 2. Jenkins will run on Mac, Windows and most Unix/Linux based servers Java 8 (either JRE or JDK) If you do not have a server for the install you can get one for a low as $5 a month from Digital Ocean. Though Jenkins will run on the low-end server for testing for production I would highly recommend a multi-core setup, the $40 plan or larger.
As a first run, we are going to run Jenkins on the same host as our testing server. As you become more familiar with working with Jenkins I suggest running a master and multiple slave agents. Do not try to run Jenkins on your Drupal or WordPress production servers.
DNS name docker.for.mac.host.internal shoud be used instead of docker.for.mac.localhost (still valid) for host resolution from containers, since since there is an RFC banning the use of subdomains of localhost. See https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-06.
Since writing Setting up Docker4Drupal with multiple projects on Mac I have discovered a better way. Træfik allows for automatic detection, so you can leave it running in it’s own container. With a few changes to Docker4Drupal and Docker4Wordpress YAML files you can start and stop your development sites without having to reconfigure Træfik.
Create a working folder for Træfik:
Create wildcard cert files for *.test (If you have not setup Dnsmasq locally I recommend it)