Forked from Sun’s Hudson project after it was acquired by Oracle, Jenkins is a popular open-source CI/CD tool used throughout the industry to create and manage build pipelines. Jenkins is distributed as a Java war package and can be deployed to a Tomcat server or run as a self-executing war. The Jenkins dashboard is then accessible through a web application.
When Jenkins first runs, it creates a .jenkins directory where pipelines and project workspaces will be managed, along with an installation directory elsewhere for managing tools, plugins, and users.
Once Jenkins is up and running, the dashboard can be found at http://localhost:8080 by default. The Unlock Jenkins page will prevent further access until the autogenerated password is copied from the file location specified on the page or on the console log output when running Jenkins as an executable war.
Once unlocked, Jenkins can download several popular plugins and help configure the admin account.
The popularity of Jenkins is in part thanks to its rich plugin community offering many helpful tools for a variety of build actions. On initial setup a variety of popular plugins come bundled with Jenkins and can be installed individually. More plugins can be discovered and installed (or removed).
Jenkins runs its processes as a special user on its host operating system. In order to work with a variety of tools, it must install and configure permissions for these tools, ranging from command line programs such as Git or Maven to authentication of external services like GitHub or Slack. If certain tools are missing, Jenkins can be configured to automatically install them during a build.
A default admin account is registered during initial setup. If this admin account creation is skipped, the password will be the autogenerated password used to unlock Jenkins. Other accounts can be created, and permissions can be set by the admin using the security matrix. This is useful for restricting access to your pipelines to developers who may not require it.
A pipeline is defined through a Jenkins Job, a project created and monitored on the Jenkins dashboard. Jobs can be structured in multiple ways using a variety of archetypes. Each job creates a folder with a workspace directory where a bulid can be isolated from other jobs. A job is configured through a graphical wizard interface or programmatically using a Jenkinsfile script (written in Groovy, a JVM scripting language).
Besides the build itself, various pre-build and post-build stages can be defined in order to set environment variables, prepare build tools, poll SCM repositories, and log messages to email or other messaging services like Slack.
Jenkins jobs normally run on the master node, the server the Jenkins instance defining the pipeline shares. But distributed builds are possible through a Jenkins Agent, a separate node hosted on a different server and linked to a master node through SSH. A Jenkins master with one or more agents can run a build on these agents thereby freeing up resources on the master for other jobs.
Rather than poll a GitHub repository at regular intervals, Jenkins can be configured to listen to the repository for any updates, then trigger a build.
On a repository, under “Settings” and “Integrations and Services”, the Jenkins (GitHub plugin) service can be added and configured using http://<your public DNS>:8080/jenkins/github-webhook/ as the Jenkins hook URL. “Active” should be checked.
Under the user’s profile, “Settings”, then “Personal access tokens” under “Developer settings”, a user access token can be generated and assigned a repository scope. The generated token, an alphanumeric string pattern, can be copied over to Jenkins.
In “Manage Jenkins”, “Global Tool configuration”, The path to Git should be configured. Then Under “Configure System”, then “Github”, and “Add GitHub Server”, the hook can be added. The API URL should be https://api.github.com while in “Credentials”, then “Add/Jenkins” and “Kind”, the “secret text” should be the generated token copied from GitHub. “Test connection” should display a message saying, “Credentials verified for user <your github name>… etc”.
Then while configuring a project job, “Git” should be chosen under “Source Code Management” specifying the repository URL and branch to build from. Afterwards the “GitHub hook trigger for GITScm polling” under “Build Triggers” should enable the feature for the pipeline.