1.What are Jenkins plugins?
Plugins are the primary means of enhancing the functionality of a Jenkins environment to suit organization- or user-specific needs. There are over a thousand different plugins which can be installed on a Jenkins controller and to integrate various build tools, cloud providers, analysis tools, and much more.

2.The most useful Jenkins plugins for DevOps?
Job Generator Plugin
Performance Plugin
GitHub/GitLab Pull Request Builder
JIRA Plugin
Kubernetes Plugin
Build Pipeline plugin
SCM Sync Configuration Plugin
Jenkins Maven plugin

3.How do I get a list of Jenkins plugins?
Call the Jenkins API for plugin results. Click Manage Jenkins. Click Manage Plugins. Click on the Installed tab in console.

4.How do Jenkins plugins work?
Jenkins plugins allow you to extend the Jenkins build system to do almost anything. ... Jenkins plugins work by creating or extending an extension point, which hooks into a specific part of the build process. The catch: these extension points can differ significantly in what they do and how they work.

5.How many plugins Jenkins have?
There are over 1000 plugins available in the Jenkins plugins repository, but only a few of them can be considered essential.

1.Why is join trigger plugin used in Jenkins?
The Join trigger plugin is used to allow a job to be run after all the immediate downstream jobs have completed. That is, the Join triggers a job after a group of the job is finished. With this plugin, the execution can branch out and perform many steps in parallel.

2.What are the features of pipeline plugin?
The principal characteristic of the Pipeline plugin is that the deployment flow is defined through code. The plugin is based on Groovy DSL that can be used to specify build steps. The whole flow that would typically require many “standard” Jenkins jobs chained together can be expressed as a single script.

3.What are the features of pre build plugin?
Pre and post-build plugins enable you to apply code before or after the build process to prepare, verify, and test data. Before a build begins, you can: Bring in files/prepare data. Validate your data and cancel a build if there's a problem.

4.What is Thinbackup plugin?
A light-weight fork of backup Plugin. It simply backups the global and job specific configuration.

5.Which maven plugin Jenkins install?
Maven Integration plugin is a plugin that helps us to build projects that use Apache Maven in Jenkins. In this tutorial, I will guide you how to install this plugin to be able to use it. then click Install without restart or Download now and install after restart to install it.

1. What is Thinbackup plugin?
A light-weight fork of backup Plugin. It simply backups the global and job specific configuration.

2. Which maven plugin Jenkins install?
Maven Integration plugin is a plugin that helps us to build projects that use Apache Maven in Jenkins. In this tutorial, I will guide you how to install this plugin to be able to use it. then click Install without restart or Download now and install after restart to install it.

1. How to use Git hooks to set a Jenkins parameter?
I currently have a Jenkins freestyle project going. In Jenkins I have a variable called "branch" and using git hooks I call the Jenkins job and set branch=master. That works no problem. Now I have an active choice param called "config" that I am trying to set based on the branch. I have a simple groovy script
If (branch.equals("master")){
return["Release"]
}else{
return["Debug"]
}
The issue is that config does not get set to either "Release" or "Debug". It is just empty. Is it possible to set the param like this

Jenkins Pipeline Perforce SCM
Hi guys, I'm a complete noob at build automation and Jenkins, having started my first job as a full time build engineer about a month ago now..
Our current set-up works with a bunch of downstream jobs that trigger each other, I'm not a big fan of this and would like to setup a Jenkins pipeline as a proof of concept.. as I think they're written in groovy ? and possibly allow other languages? as well as the benefit of version control and reusability seems a huge win..
that said, I've been having trouble getting the perforce SCM to work.. I keep getting an error
Mapping '//jenkinsTemp-651dd846-1c45-4d93-965e-541df7327c59' is not under '//jenkinsTemp-651dd846-1c45-4d93-965e-541df7327c59/...'.
when running the job. I don't really understand why it keeps trying to make these jenkinsTemp workspaces? Inside the job I have it set up as (static view, master only) with the workspace name entered as the workspace of our build machine (we only have one node at the moment and thus want to set it up to just use this one's workspace.. no need for generating ones..) .. (Credentials fine too)...
the populate options set to 'preview check only' at the moment. And the scrip path set to
//DepotName/main/Tools/Jenkins/HelloWorldPipeline.groovy
I read the docs on github for the p4 plugin.. And couldn't figure out why it keeps trying to use jenkinsTemp and what it's trying to map exactly..
I know perforce isn't the popular option here, at previous workplaces we used git repo and it seemed a tone easier, but alas. Got a work with what I'm given.

Interesting Task
I wrote this in Markdown, so hopefully this comes through for everyone.
I have an interesting task coming down the pipe, I am wondering what people have done and if you all have suggestions for what the best most sustainable path forward is, that'd be hugely appreciated!
# Objective:
Create a template for customer builds. One that is highly parameterized, easy to add/remove from etc, and my most important requirement is it all be in code. The challenge is that every customer has different values to their variables. More so, sometimes there can be a "parent" customer and child customers and some of the parent values get inherited at the child level unless the child customer has that variable defined.
## Currently:
The way the current workflow goes is three part
1. Customer build (unique)
a. This is basically just a job that holds all of the custom parameters that get passed to the next job(s)
2. Build job (generic)
3. Test job (generic)
When we add new customers we copy a job through the UI and edit the values. If a "parent level" value changes that affects several jobs it is a very laborious process clicking through the jobs and editing.
## Gold Standard
Everything is in code
I would like a way to be able to copy/paste the template, edit the parameters based on the customer requirements and "apply" the changes. "Applying" could be running a script against Jenkins, committing to SCM and kicking off a job in Jenkins to then update itself.
## Current
1. At my previous job the entirety of Jenkins was all in code. We would blow away our entire Jenkins instance and just copy/paste the config back into Jenkins and it would all be back. I believe that also had all of the configurations for the jobs as well. In that case, that could be ideal. If I remember correctly this was all done in Groovy and not using the Configuration as Code (YAML) plugin.
2. I don't quite love Groovy and most of my coworkers work in Python, I was unsure if there was an equivalent to this.

1) A build parameter allows us to pass data into our Jenkins jobs. Using build parameters, we can pass any data we want: git branch name, secret credentials, hostnames and ports, and so on.
2) Any Jenkins job or pipeline can be parameterized. All we have to do is check the box on the General settings tab that says this project is parameterized:

Managing Kubernetes Cluster on AWS EKS:
Link: https://www.youtube.com/watch?v=pe8l-GyClZU&list=PLt8Y3NwVSVfacKDZLoR_rJ5mlRiGAvRoX&index=4

What are the common use cases Jenkins is used for?
Jenkins being open-source automation can be used for any kind of software-based automation. Some of the common use-cases include but not limited to -

Software build jobs
Sanity/Smoke/CI/Regression test jobs
Web/Data Scraping related jobs
Code coverage measurement jobs
General-purpose automation
Reverse Engineering jobs
Key Decoding jobs & many other jobs where software automation will be applicable.

Tell me something about Continuous Integration, Continuous Delivery, and Continuous Deployment?
Continuous Integration: A software development process where the changes made to software are integrated into the main code as and when a patch is ready so that the software will be always ready to be - built, tested, deployed, monitored - continuously.

Continuous Delivery: This is a Software Development Process where the continuously integrated (CI) changes will be tested & deployed continuously into a specific environment, generally through a manual release process, after all the quality checks are successful

Continuous Deployment: A Software Development practice where the continuously integrated (CI) changes are deployed automatically into the target environment after all the quality checks are successful

Kubectl Basic Commands
Kubectl get
$ kubectl get namespaces
$ kubectl get nodes
$ kubectl get pods
$ kubectl get pods --namespace jenkins

Kubectl describe
$ kubectl describe ns jenkins
$ kubectl describe pods jenkins-7fc688c874-mh7gv --namespace jenkins
$ kubectl describe node minikube

💥💥 TODAY'S TECHNOTES 💥💥
How do you store credentials in Jenkins securely?
Credentials can be stored securely in Jenkins using the Credentials plugin, which stores different types of credentials like - Username with a password, SSH username with the private key, AWS Credentials, Jenkins Build Token, Secret File/Text, X509 & other certificates, Vault related credentials securely with proper encryption & decryption as and when required.
How can we stop a scheduled job from being executed temporarily?
Disable the job from the job details page to temporarily stop all scheduled executions & other factors/events from triggering the job and enable it back to resume the job schedules/triggers. If a job is not required permanently, we can delete the job from the jobs list view page.

Hi Techies,

Here we have social media links platform for gaining knowledge on *AZURE, GCP CLOUD & LINUX*

There you can get daily basis some technotes, materials and training information

Telegram link: https://t.me/tech_azure

Telegram link : https://t.me/techli_nux

Telegram link: https://t.me/tech_gcp

What are the ways to trigger a Jenkins Job/Pipeline?
There are many ways we can trigger a job in Jenkins. Some of the common ways are as below -

Trigger an API (POST) request to the target job URL with the required data.
Trigger it manually from the Jenkins web application.
Trigger it using Jenkins CLI from the master/slave nodes.
Time-based Scheduled Triggers like a cron job.
Event-based Triggers like SCM Actions (Git Commit, Pull Requests), WebHooks, etc.
Upstream/Downstream triggers by other Jenkins jobs.

📛📛📛📛📛📛📛📛

Hi Friends💐💐

There you can get daily basis some technotes, materials and training information

*LINUX* Telegram link : https://t.me/techli_nux

*AZURE* Telegram link: https://t.me/tech_azure

*GCP* Telegram link: https://t.me/tech_gcp

Hi Friends💐💐

Do you Want to learn LINUX ?🤩🤩

👇Here we are doing YouTube Video on LINUX | Linux Basic Commands👇

https://youtu.be/GafoXUSBAbA

Please Watch👨🏻💻 Like👍🏻 Share📣 Subscribe 🔔our channel to get more videos💯

Regards,
Hi-Tech Institution
+91 7092909192 / 8220217640

🤩 FREE! FREE! FREE!... 🤩

*REALTIME PROJECT BASED VIDEOS*

*LINUX* : https://t.me/techli_nux

*AZURE* : https://t.me/tech_azure

*GCP* : https://t.me/tech_gcp

What is Jenkins Build Cause?
Build Cause is a text attribute that represents what made a job's build to be triggered, say it could be a Jenkins User (from UI), Timer for Scheduled jobs, Upstream jobs for a job which was triggered by upstream job, etc. This is mainly used to identify the nature of the builds - be it nightly, manual, automated, etc.

How Jenkins knows when to execute a Scheduled job/pipeline and how it is triggered?
Jenkins master will have the cron entries set up for the jobs as per the scheduled Job's configurations. As and when the time for a particular job comes, it commands agents (based on the configuration of the job) to execute the job with required configurations.

💥💥 Today's Technotes 💥💥

WHAT ARE THE WAYS TO TRIGGER A JENKINS JOB/PIPELINE?
There are many ways we can trigger a job in Jenkins. Some of the common ways are as below -

Trigger an API (POST) request to the target job URL with the required data.
Trigger it manually from the Jenkins web application.
Trigger it using Jenkins CLI from the master/slave nodes.
Time-based Scheduled Triggers like a cron job.
Event-based Triggers like SCM Actions (Git Commit, Pull Requests), WebHooks, etc.
Upstream/Downstream triggers by other Jenkins jobs.

💥💥 Today's Technotes 💥💥

Hi Friends💐💐

Do you Want to learn GCP CLOUD?🤩🤩

Here we are doing YouTube Video on GCP Machine Images | Custom VM Images| Machine Images in GCP | Google Cloud in GCP 👇

https://youtu.be/oSJj3b8LP1A

Please Watch👨🏻💻 Like👍🏻 Share📣 Subscribe 🔔our channel to get more videos💯

Regards,
Hi-Tech Institution
+91 7092909192 / 8220217640