Happy Coincidence

Setting Up a Jenkins Master

The easiest approach is to set up the Jenkins Master based on the official Docker image. To do this, the admin on the host that will be hosting the Jenkins Master runs the command:

docker run --name jenkins -d -v jenkins_home:/var/jenkins_home -p 8080:8080 -p 50000:50000 jenkins/jenkins:latest

Immediately afterward, you need to print the log with

docker logs -f jenkins

to get the initial admin password (Listing 3).

[...]
Jenkins initial setup is required. An admin user has been created and a password generated.
Please use the following password to proceed to installation:
12345678901234567890123456789012
This may also be found at: /var/jenkins_home/secrets/initialAdminPassword
[...]

As you can see, the password is also available for viewing in the container below the specified path:

$ docker exec -it jenkins cat /var/jenkins_home/secrets/initialAdminPassword
12345678901234567890123456789012

The file remains until the initial setup is finished. This is precisely what the admin follows when calling the Jenkins URL in the browser. The easiest way to do this is by typing http://<Host-IP>:8080/ directly on the Jenkins Master, because the setup is simplified and does not include HTTPS setup or port configuration.

The following steps set up the default admin and install the recommended plugins; then, the standard Jenkins interface is accessible, and the basic installation of the Jenkins Master is complete.

In preparation, the admin stores the credentials that Jenkins needs to access GitHub and Docker Hub. The credentials are of the type Username/Password and support access to the respective API. Later, GitHub will also be accessed via SSH, which is why you have to store the corresponding private key in a separate credential entry of Kind SSH Username with private key and install the SSH agent plugin.

For a GitHub organization, it makes sense to set up a separate CI account and deposit the corresponding public key there. In the case of a personal account, the account owner has to add the public key to their profile.

Setting Up Build Slaves

To connect Linux or Mac builders, you need to configure a build node with Launch method Launch slave agents via SSH . For this you need an account with SSH access and key-based login on the slaves. The private key to be used is stored on the master in the credentials configuration.

The account on the slave normally does not need admin privileges but must be allowed to execute Docker commands. It is also important that the Linux slaves have the correct label – docker, in this case – thus ensuring that the pure Docker builds start explicitly on the Linux slaves.

The easiest way for the admin to integrate a Windows slave is with Launch method Launch agent via Java Web Start , as described online [7].

Linking GitHub and Jenkins

An important point of build automation is connecting Jenkins to the repositories on GitHub. At this point, it is advisable to use an organization scanner (Figure 1). For an initial design, the default organization scanner settings will be fine. You only need to enter the access credentials plus the GitHub organization or your own GitHub username under Owner .

Figure 1: The starting point for creating a GitHub organization scanner in Jenkins.

The big advantage of a scanner is that you only need to configure the GitHub project or the GitHub user in it. The organization scanner automatically finds the Git repositories for the specified organization or user and analyzes their branches for the presence of a Jenkinsfile. If a Jenkinsfile exists, the scanner automatically creates a suitable build job.

Therefore, admins no longer have to create additional Git repositories on the CI system, because the build jobs are created in a fully automated process. If a branch is deleted after a successful pull request, the corresponding build job also disappears.