1. What Is Jenkins Used For?

Jenkins is used for automating software development tasks such as code compilation,
testing, code quality checks, artifact creation, and deployment. It streamlines the
development process, ensuring reliability and quality by automating repetitive
tasks in a DevOps context.
2. How To Trigger a Build In Jenkins Manually?

To manually trigger a build in Jenkins:

Access the Jenkins Dashboard.

Select the specific Jenkins job.
Click “Build Now” to start the manual build.
Provide build parameters if necessary.
Confirm and monitor the build progress in real time.
Review the build results on the job’s dashboard.
Access build artifacts if applicable.
Trigger additional builds as needed.

3. What Is The Default Path For The Jenkins Password When You Install It?

The default path for the Jenkins password when you install it can vary depending on
your operating system and how you installed Jenkins. Here are the general default
locations for the Jenkins password:
1. On Windows

If you installed Jenkins as a Windows service, the initial administrative password

is typically stored in a file called initialAdminPassword inside the secrets
directory within the Jenkins installation directory. The path may look something
like this: C:\Program Files (x86)\Jenkins\secrets\initialAdminPassword.
2. On Linux/Unix

If you installed Jenkins using a package manager like apt or yum, the initial
password might not be stored directly on the file system. In this case, you can
typically find it in the console output when you start Jenkins for the first time.
You’ll see a message that includes the initial password.

If you installed Jenkins manually, you might need to check the Jenkins home
directory, which is often located at /var/lib/jenkins. Within this directory, you
can find the secrets directory and, inside it, the initialAdminPassword file.
3. On MacOS

If you installed Jenkins on MacOS, the initial password is generally located in the
same way as on Linux or Unix systems. You can look in the secrets directory within
the Jenkins home directory.

Please note that these paths can change depending on your Jenkins installation
method and configuration, so it’s a good idea to refer to the documentation or
installation instructions specific to your setup if you encounter any issues
locating the initial Jenkins password.
4. How To Integrate Git With Jenkins?

To integrate Git with Jenkins:

Install the “Git Plugin” in Jenkins through the plugin manager.

Configure Git in the global tool configuration, ensuring automatic installation
is enabled.
Create or configure a Jenkins job, selecting Git as the version control system.
 Specify the Git repository URL and, if necessary, credentials for
authentication.
Define the branches to monitor and build.
Set up build triggers as needed.
Save the job configuration and trigger builds manually or automatically based
on your settings.
Monitor build progress and results in the Jenkins dashboard.

5. What Does “Poll SCM” Mean In Jenkins?

In Jenkins, “poll SCM” means periodically checking a version control system (e.g.,
Git) for changes. You can schedule how often Jenkins checks for updates. When
changes are detected, Jenkins triggers a build, making it a key feature for
continuous integration, scheduled tasks, and automated response to code changes.
6. How To Schedule Jenkins Build Periodically (hourly, daily, weekly)? Explain the
Jenkins schedule format.

To schedule Jenkins builds periodically at specific intervals, you can use the
built-in scheduling feature. Jenkins uses a cron-like syntax for scheduling,
allowing you to specify when and how often your builds should run. Here’s a
detailed explanation of the Jenkins schedule format and how to schedule builds:
1. Jenkins Schedule Format

The Jenkins schedule format closely resembles the familiar cron syntax, with a few
minor differences. A typical Jenkins schedule consists of five fields, representing
minute, hour, day of the month, month, and day of the week, in that order:

Here’s what each field means:

Minute (0 – 59): Specifies the minute of the hour when the build should run
(e.g., 0 for the top of the hour, 30 for the half-hour).
Hour (0 – 23): Specifies the hour of the day when the build should run (e.g., 1
for 1 AM, 13 for 1 PM).
Day of the month (1 – 31): Specifies the day of the month when the build should
run (e.g., 1 for the 1st day of the month, 15 for the 15th day).
Month (1 – 12): Specifies the month when the build should run (e.g., 1 for
January, 12 for December).
Day of the week (0 – 7): Specifies the day of the week when the build should
run (e.g., 0 or 7 for Sunday, 1 for Monday, and so on).

Scheduling Examples:

Now, let’s look at some scheduling examples:

Cron Expression Description
0 0 * * * Schedules a build every day at midnight (00:00).
30 * * * * Schedules a build every hour at the 30th minute (e.g., 1:30 AM, 2:30
AM).
0 15 * * 1 Schedules a build every Monday at 3 PM.
0 8,20 * * * Schedules a build every day at 8 AM and 8 PM.
30 22 * * 5 Schedules a build every Friday at 10:30 PM.
Configuring The Schedule In Jenkins

To schedule a build in Jenkins:

Open your Jenkins job’s configuration page.

In the “Build Triggers” section, check the “Build periodically” option.
In the text box that appears, enter your desired schedule using the cron-like
syntax.
For example, to schedule a daily build at midnight (00:00), enter 0 0 * * *. Make
sure to include the five fields in the schedule.

Click “Save” to apply the schedule.

Jenkins will now automatically trigger your builds according to the specified
schedule. You can use this scheduling feature to automate tasks, such as nightly
builds, daily backups, or any other recurring job that fits your project’s needs.
7. What Is Jenkins Home Directory Path?

The Jenkins home directory is where Jenkins stores its critical data, including job
configurations, logs, plugins, and more. The location of this directory varies by
operating system but can typically be found at:

Linux/Unix: /var/lib/jenkins
Windows: C:\Users<YourUsername>.jenkins
macOS: /Users/<YourUsername>/.jenkins

You can configure its location during installation or in the Jenkins startup
script. Understanding this directory is essential for managing and backing up
Jenkins data.
8. How To Integrate Slack With Jenkins?

To integrate Slack with Jenkins for notifications:

Set up a Slack Incoming Webhook in your Slack workspace to get a Webhook URL
Install the “Slack Notification” plugin in Jenkins.
Configure Jenkins global Slack settings by adding the Slack Webhook URL.
In your Jenkins job configuration, add a “Slack Notifications” post-build
action.
Specify the Slack channel, customize message options, and select notification
preferences (e.g., success, failure).
Save the job configuration.
Run a build, and Jenkins will send notifications to the specified Slack channel
based on build results.
Now, Jenkins is integrated with Slack, providing real-time notifications to
keep your team informed about build status and progress.

9. What Is A Jenkins Agent?

A Jenkins agent, also called a Jenkins slave or node, is a separate machine or

resource that collaborates with a Jenkins master to execute jobs and build tasks.
Agents enable parallel and distributed builds, scaling Jenkins’ capacity.

They register with the master, get assigned jobs, execute them on their own
hardware or VMs, and report back results. Agents can run on various platforms,
making it possible to test and build in different environments.
10. How To Restart Jenkins?

To restart Jenkins, you can follow these steps:

Method 1.Using the Jenkins Web Interface (if available):

Open a web browser and navigate to your Jenkins server’s URL.

Log in to the Jenkins web interface if required.
In the top-right corner, you may see a “Restart” option. Click on it to
initiate the restart process.
Jenkins will display a confirmation dialog. Confirm that you want to restart
Jenkins.
Method 2.Using Command Line (Linux/Unix):

If you have SSH access to the server where Jenkins is installed, you can use
the following commands:
Open a terminal or SSH into the Jenkins server.
Run the following command with superuser privileges (e.g., using sudo):

sudo systemctl restart jenkins

This command assumes that Jenkins is managed as a systemd service. If Jenkins is

managed differently on your system, you may need to use an alternative command.

Step 3. Using Command Line (Windows):

On Windows, you can restart Jenkins as a service using the following commands:

Open a Command Prompt or PowerShell window with administrator privileges.

Stop the Jenkins service:

net stop “Jenkins”

Start the Jenkins service:

net start “Jenkins”

Ensure that you use double quotes around “Jenkins” if the service name has spaces.

Method 4: Using a Container Or Other Deployment Method:

If Jenkins is running inside a container or managed through a different deployment

method, you should refer to the specific instructions for that environment. The
procedure for restarting Jenkins may differ based on the setup.

Please choose the method that best suits your Jenkins deployment and the level of
access you have to the server or environment where Jenkins is installed.
11. What Is The Default Port Number For Jenkins?

The default port number for Jenkins is 8080. When you access the Jenkins web
interface via a web browser, you typically use the URL:
http://your_jenkins_server:8080/.
Intermediate Jenkins Interview Questions
12. Types of build triggers in Jenkins.

Types of build triggers in Jenkins include:

SCM Polling Trigger: Monitors source code repositories for changes and triggers
builds.
Scheduled Build Trigger: Runs jobs on a predefined schedule using cron-like
syntax.
Webhook Trigger: Listens for external events or notifications to start builds.
Upstream/Downstream Trigger: Triggers downstream jobs based on the success of
upstream jobs, creating build pipelines.
Manual Build Trigger: Requires manual user intervention to start a job.
Dependency Build Trigger: Triggers jobs when another job is completed,
regardless of success or failure.
Parameterized Trigger: Passes parameters from one job to another during
triggering.
Pipeline Trigger: Allows custom triggering logic within Jenkins Pipelines.
Using the right trigger type is crucial for automating and managing your CI/CD
pipelines effectively.
13. What is the language used to write the Jenkins CI/CD pipeline?

Jenkins CI/CD pipelines are typically written using a domain-specific language

called Groovy. Specifically, Jenkins uses the Jenkins Pipeline DSL (Domain-Specific
Language), which is an extension of Groovy tailored for defining and orchestrating
continuous integration and continuous delivery pipelines.

Here are some key points about the language used to write Jenkins CI/CD pipelines:

Groovy: Groovy is a versatile and dynamic programming language that runs on the
Java Virtual Machine (JVM). It is known for its simplicity and flexibility, making
it well-suited for scripting and automation tasks.
Declarative and Scripted Syntax: Jenkins Pipelines support two syntax flavours.
Declarative and Scripted. Declarative syntax provides a simplified and structured
way to define pipelines, while Scripted syntax allows for more fine-grained control
and scripting capabilities.
Pipeline DSL: The Jenkins Pipeline DSL provides a set of domain-specific
constructs and functions for defining stages, steps, and post-build actions within
a pipeline. It also includes built-in support for parallel execution, error
handling, and integrations with various plugins.
Pipeline as Code: Jenkins Pipelines are often referred to as “Pipeline as Code”
because you define your build and deployment processes as code within a version-
controlled file. This approach allows for versioning, code review, and
collaboration on pipeline definitions.
Version Control Integration: Jenkins Pipelines can be stored in version control
repositories, such as Git. This integration allows you to manage and version your
pipeline definitions alongside your application code.
Customization: The Groovy-based Jenkins Pipeline DSL allows you to customize
and extend your pipelines with custom functions, logic, and integrations. You can
use existing Groovy libraries and create reusable components.
IDE Support: Groovy is supported by various integrated development environments
(IDEs), such as IntelliJ IDEA and Visual Studio Code, which provide code
completion, syntax highlighting, and debugging capabilities for pipeline
development.
Shared Libraries: Jenkins allows you to define shared libraries written in
Groovy, which can be used across multiple pipelines. Shared libraries enable code
reuse and maintainability for common pipeline tasks.

In summary, Jenkins CI/CD pipelines are written using Groovy and the Jenkins
Pipeline DSL, which provides a powerful and flexible way to define and automate
your continuous integration and delivery workflows. Groovy’s ease of use and
Jenkins’ robust features make it a popular choice for the pipeline as code
implementations.
14. What is the difference between Continuous Delivery and Continuous Deployment?

Continuous Delivery (CD) and Continuous Deployment (CD) are two distinct practices
in the DevOps and software development lifecycle, but they are closely related.
Here are the key differences between the two:

Criteria

Continuous Delivery

Continuous Deployment
Definition Continuous Delivery is a software development practice that focuses on
automating the process of delivering code changes to production-like environments
(staging or testing environments) after passing through the entire pipeline of
build, test, and deployment.

Continuous Deployment is an extension of Continuous Delivery. It is a practice

where code changes that pass automated tests are automatically and immediately
deployed to the production environment without requiring manual intervention or
approval.
Deployment to Production In Continuous Delivery, the deployment to the
production environment is not automated. Instead, it requires a manual trigger or
approval process. The code is considered “production-ready” and can be deployed to
the live environment, but this step is not automated.

In Continuous Deployment, the deployment to the production environment is fully

automated. As soon as code changes pass all automated tests, they are automatically
released to the live environment.
Human Intervention CD allows for human intervention and decision-making before
deploying code to the production environment. It allows teams to assess the
changes, perform final testing, and ensure that business requirements are met.
CD eliminates the need for human intervention or approval in the production
deployment process. If the automated tests pass, the code goes live.
Use Cases

Continuous Delivery is often chosen in scenarios where organizations want to

achieve a balance between rapid development and the need for human validation
before releasing changes to customers. It reduces the risk of unexpected issues in
production.
Continuous Deployment is often implemented by organizations that prioritize
rapid delivery of new features and bug fixes to end-users. It is common in
environments where there is a strong focus on continuous improvement and
automation.

In summary, the main difference between Continuous Delivery and Continuous

Deployment is the level of automation and human intervention in the final
deployment to the production environment. Continuous Delivery stops short of fully
automated production deployment and includes a manual approval step, while
Continuous Deployment automates the entire process, releasing code changes to
production as soon as they pass automated tests. The choice between the two
practices depends on an organization’s risk tolerance, release strategy, and the
need for manual validation.