Getting Started Jenkins
This getting started tutorial is based on the Jenkins documentation.
Step 1: Installing Jenkins
Jenkins can be distributed as a set of WAR files, installers, Docker images, and native packages.
Its minimum requirements in terms of hardware include 256 MB RAM and at least 1 GB drive space (though 10 GB or more is recommended when running Jenkins as a container).
To install Jenkins:
- Download the Jenkins generic Java WAR package. (place the jenkins.war file in some where for me. C:\Jenkins)
- In the download’s directory, open a terminal and run the following:
- Navigate to http://localhost:8080 and follow the installation instructions on the this url
- During installation it asks you where copy the adminPassword and paste it, and after that asks from you give username, passoword, email , full name etc.
- Note: Jenkins installs in Windows: C:\Users\Owneruser\.jenkins
- press to save and continue then it asks you start the Jenkins, in the following you see the UI of Jenkins:
Step 2: Creating a Pipeline
Jenkins Pipeline includes several plugins that support the implementation and integration of CI pipelines in Jenkins. This tool suite is extensible and can be used to model continuous delivery pipelines as codes, regardless of their complexity. You write the pipeline’s definition in a Jenkinsfile, which is a text file used in the project’s repository.
Prerequisites: Before following the procedures below, you need to have access to a Git Repository, with credentials to commit.
You can get started with Pipeline using these steps:
- Go to the Manage Jenkins page, then to Plugins, and install the plugin for Docker Pipeline
- Do this by pressing to the Manage Jenkins: Plugins: Available plugins and scroll down and find the Docker Pipeline as seen in the following image
- Select the checkbox front of Docker Pipeline and press to the install button on the upper right of UI. then the it is installed.
- Once the plugin is installed, you should restart Jenkins to ensure the plugin is usable.
- You can restart Jenkins as follow:
- Close command prompt then browser for jenkins is not running
- start command line and navigate to the folder where Jenkins.war is placed (for me is C:\Jenkins) and then execute the “java -jar jenkins.war” command.
- Then go to localhost:8080 then Jenkins Dashboard is displayed)
- Copy the following text into the project’s source control repository and name the file
Jenkinsfile:
Jenkinsfile://Jenkinsfile (Declarative Pipeline) /* Requires the Docker Pipeline plugin */ pipeline { agent { docker { image ‘maven:3.9.0-eclipse-temurin-11’ } } stages { stage(‘build’) { steps { sh ‘mvn –version’ } } } }Notes : for me: Githu: project: ProductMicroservice-DotNET-Core-Master)
- Inside Jenkins, click on New Item to view the menu.
- Specify the name of the new item (e.g jenkinsItem) and choose the Multibranch Pipeline option and press OK
- Then a new windows is opend there give the followings
- Display name: productmicroservice
- Description : productmicroservice is a Microservice in .NET Core
- Under Branch Sources, choose Github
- Credentials : choose: Credentials for Github rep
- Repositor https URL: https://github.com/mehzan07/ProductMicroservice-DotNET-Core-Master.
- press to the validate (under) then you can see it is OK (Credentials ok. Connected to https://github.com/mehzan07/ProductMicroservice-DotNET-Core-Master.)
- Scan Multibranch Pipeline Triggers: choose a time like day, x hours, etc (I am testing with 5 minutes)
- Docker registry URL: https://hub.docker.com/
- Registry credentials: Credentials for Github rep
- press to Save and t see the first Jenkins pipeline run creates Scan Repository log as follow:
Started by user Mehrdad Zandi
[Tue Jan 16 23:15:25 CET 2024] Starting branch indexing...
23:15:25 Connecting to https://api.github.com using f6711e01-b57d-432e-b2c6-bfb2e052f9b5
Examining mehzan07/ProductMicroservice-DotNET-Core-Master
Checking branches...
Getting remote branches...
Checking branch master
Getting remote pull requests...
‘Jenkinsfile’ found
Met criteria
Scheduled build for branch: master
Checking branch feature
‘Jenkinsfile’ not found
Does not meet criteria
2 branches were processed
Checking pull-requests...
0 pull requests were processed
Finished examining mehzan07/ProductMicroservice-DotNET-Core-Master
[Tue Jan 16 23:15:26 CET 2024] Finished branch indexing. Indexing took 1.9 sec
Finished: SUCCESSAs we see from the above it check the branches, finds Jenkinsfile in the master does a Pull request, and checks feature branch and JeninsFile Not found. checking pull- requests (0 pull request were processed) and atleast Finished: SUCCESS
And in the lef menu of Jenkins Dashboard under: Build Execute Status, you can find status of build
You might need to modify your Jenkinsfile to enable it to run with the project. For example, you can modify the sh command to let it run the same command that would be run on a local machine. Once you’ve set up the pipeline, Jenkins will be able to automatically detect new pull requests and branches created in your source control repository. It will then run the pipelines for these.
Note: you can Disable or Enable Build of your project from the upper right of Dashboard : Disable (Enable) MultiBranch Pipeline button
Step 3: Running a Pipeline with Multiple Steps
A typical pipeline has multiple steps involving the building, testing, and deployment of applications. With Jenkins Pipeline, you can define multiple steps in a simple way to help model various, more complex automation processes.
A step in this context is a specific command that performs a given action. Upon the successful completion of each step, the pipeline will continue to the next one. If one step fails, the overall pipeline also fails.
You can use the sh step on Linux, Mac OS, and BSD systems to execute shell commands in the pipeline:
//Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Build') {
steps {
sh 'echo "Welcome"'
sh '''
echo "The multiline shell steps are working"
ls -lah
'''
}
}
}
}Step 4: Using Timeouts and Retries
Some steps can be used alongside other steps to make it easier to address issues such as retrying steps or timing out. A timeout step determines when Jenkins should exit an unsuccessfully retried step.
If a given step does not complete successfully within the specified time limit, the timeout prevents the controller from wasting further resources on attempting to run it. For example, you might allow the pipeline to retry a deployment step up to five times, and wait up to five minutes, before exiting:
//Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Deploy') {
steps {
retry(5) {
sh './flakey-deploy.sh'
}
timeout(time: 5, unit: 'MINUTES') {
sh './health-check.sh'
}
}
}
}
}In this example, the flakey-deploy.sh script will be retried five times. If the health-check.sh script fails to execute within five minutes, Jenkins will mark the pipeline’s “Deploy” stage as failed. Retry and timeout steps are often used together.
Here is an example of how to compose these wrapper steps to retry the deployment up to ten times, but without spending more than a total of two minutes before exiting the stage and marking it as failed:
Note: The code below assumes that your deployment folder is /usr/local/security-group-manager/ and the script is flakey-deploy.sh. Ensure you provide the full path.
//Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Deploy') {
steps {
timeout(time: 2, unit: 'MINUTES') {
retry(10) {
sh '/usr/local/security-group-manager/flakey-deploy.sh'
}
}
}
}
}
}Step 5: Cleaning Up the Pipeline
Once your pipeline has finished running, you might want to execute steps to clean it up. You can carry out these actions from the post section:
//Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Test') {
steps {
sh 'echo "Fail!"; exit 1'
}
}
}
post {
always {
echo 'This always runs'
}
success {
echo 'This only runs when successful'
}
failure {
echo 'This only runs when failed'
}
unstable {
echo 'This only runs when marked unstable'
}
changed {
echo 'This only runs when the Pipeline’s state changes'
}
}
}
What Is Jenkins X?
Jenkins X is a CI/CD solution that continuously ships applications with Kubernetes. Jenkins X emphasizes CI/CD automation for the cloud.
Jenkins X combines Jenkins with open source tools like Helm, Docker, Nexus, and KSync. It automatically installs, configures, and upgrades these tools to integrate them into your CI/CD process.
Jenkins X offers feedback for all pull requests, providing previews before pushing code changes to the staging and production environments. It helps you incorporate authentication and reliability early on, preventing post-deployment surprises. You leverage a higher degree of automation to enable frequent, secure, and predictable software releases.
Jenkins X is useful regardless of your familiarity with Kubernetes, providing a CI/CD process to facilitate cloud migration. It supports bootstrapping onto your chosen cloud, which is crucial for a hybrid setup.
However, Jenkins X also has the following drawbacks:
- A primary drawback of Jenkins X is that the project went through rapid change, which makes it difficult to adopt by new users and challenging to maintain for existing users.
- It only deploys via Helm, so you need to adopt Helm if you haven’t.
- It requires trunk-based development.
- It lacks its own UI (it relies on the limited Jenkins UI), so you need to use the command line for new constructs.
- Scales by adding builders to its Kubernetes cluster and automatically connecting Jenkins Slaves to the Master.
- You can implement a serverless installation without a Master, which consumes excessive resources.
Conclusion
In this post we have described how to install Jenkins, Creating a Pipeline, Running a Pipeline with Multiple Steps, Using Timeouts and Retries and Cleaning Up the Pipeline.
The Next post explores Jenkins with .NET application
This post is part of Jenkins- step by step