Hi Frndz,
Today Technotes
Domain - Devops
Ansible-playbook
Runs Ansible playbooks, executing the defined tasks on the targeted hosts.
📘Synopsis
📕Description
📗Common Options
📙Environment
📒Files
https://docs.ansible.com/ansible/latest/cli/ansible-playbook.html
Regards
Hi-tech Team
Today Technotes
Domain - Devops
Ansible-playbook
Runs Ansible playbooks, executing the defined tasks on the targeted hosts.
📘Synopsis
📕Description
📗Common Options
📙Environment
📒Files
https://docs.ansible.com/ansible/latest/cli/ansible-playbook.html
Regards
Hi-tech Team
Hi Friends,
Today Technotes
Domain : Azure Devops
Best DevOps Tools In 2021
Comparison Of The Top DevOps Software Tools
#1) Kamatera
#2) ActiveControl
#3) Nagios
#4) Chef
#5) Jenkins
#6) Vagrant
#7) Splunk
#8) Git – Version Control Tool
#9) Ansible
#10) Prometheus
#11) Ganglia
#12) Snort
#13) Pagerduty
#14) Puppet
#15) Gulp
Thanks & Regards,
Hitech Team
Today Technotes
Domain : Azure Devops
Best DevOps Tools In 2021
Comparison Of The Top DevOps Software Tools
#1) Kamatera
#2) ActiveControl
#3) Nagios
#4) Chef
#5) Jenkins
#6) Vagrant
#7) Splunk
#8) Git – Version Control Tool
#9) Ansible
#10) Prometheus
#11) Ganglia
#12) Snort
#13) Pagerduty
#14) Puppet
#15) Gulp
Thanks & Regards,
Hitech Team
What is python Boto3?
Boto3 is the name of the Python SDK for AWS. It allows you to directly create, update, and delete AWS resources from your Python scripts.
Installing Python Boto3 to interact with AWS
1. Yum install python
2. wget http://bootstrap.pypa.io/get-pip.py
3. Python get-pip.py
4. Pip install boto3
Boto3 is the name of the Python SDK for AWS. It allows you to directly create, update, and delete AWS resources from your Python scripts.
Installing Python Boto3 to interact with AWS
1. Yum install python
2. wget http://bootstrap.pypa.io/get-pip.py
3. Python get-pip.py
4. Pip install boto3
Client versus Resource in Boto3
At its core, all that Boto3 does is call AWS APIs on your behalf. For the majority of the AWS services, Boto3 offers two distinct ways of accessing these abstracted APIs:
Client: low-level service access
Resource: higher-level object-oriented service access
Client
Clients provide a low-level interface to the AWS service. Their definitions are generated by a JSON service description present in the botocore library. The botocore package is shared between boto3 as well as the AWS CLI. The service definition for AWS S3 is stored as a JSON under the botocore package
import boto3
s3_client = boto3.client('s3')
Resources
Resources are a higher-level abstraction compared to clients. They are generated from a JSON resource description that is present in the boto library itself.
Resources provide an object-oriented interface for interacting with various AWS services. Resources can be instantiated like the following:
import boto3
At its core, all that Boto3 does is call AWS APIs on your behalf. For the majority of the AWS services, Boto3 offers two distinct ways of accessing these abstracted APIs:
Client: low-level service access
Resource: higher-level object-oriented service access
Client
Clients provide a low-level interface to the AWS service. Their definitions are generated by a JSON service description present in the botocore library. The botocore package is shared between boto3 as well as the AWS CLI. The service definition for AWS S3 is stored as a JSON under the botocore package
import boto3
s3_client = boto3.client('s3')
Resources
Resources are a higher-level abstraction compared to clients. They are generated from a JSON resource description that is present in the boto library itself.
Resources provide an object-oriented interface for interacting with various AWS services. Resources can be instantiated like the following:
import boto3
How to Integrate Your GitHub Repository to Your Jenkins Project
The integration presented in this blog post will teach you to:
1)Schedule your build
2)Pull your code and data files from your GitHub repository to your Jenkins machine
3)Automatically trigger each build on the Jenkins server, after each Commit on your Git repository
Configuring GitHub:
Step 1: go to your GitHub repository and click on Settings.
Step 2: Click on Webhooks and then click on Add webhook.
Step 3: In the Payload URL field, paste your Jenkins environment URL. At the end of this URL add /github-webhook/. In the Content type select: application/json and leave the Secret field empty.
Step 4: In the page Which events would you like to trigger this webhook? choose Let me select individual events. Then, check Pull Requests and Pushes. At the end of this option, make sure that the Active option is checked and click on Add webhook.
Configuring Jenkins:
Step 5: In Jenkins, click on New Item to create a new project.
Step 6: Give your project a name, then choose Freestyle project and finally, click on OK.
Step 7: Click on the Source Code Management tab
Step 8: Click on Git and paste your GitHub repository URL in the Repository URL field.
Step 9: Click on the Build Triggers tab and then on the GitHub hook trigger for GITScm polling. Or, choose the trigger of your choice.
Triggering the Jenkins Job to Run with Every Code Commit:
Step 10: Click on the Build tab, then click on Add build step and choose Execute shell.
Step 11: To run a Taurus test, simply use the bzt command, followed by the name of your YML file and click on Save.
Step 12: Go back to your GitHub repository, edit the Taurus script and commit the changes. We will now see how Jenkins ran the script after the commit.
Step 13: Go back to your Jenkins project and you'll see that a new job was triggered automatically from the commit we made at the previous step. Click on the little arrow next to the job and choose Console Output.
https://www.blazemeter.com/blog/how-to-integrate-your-github-repository-to-your-jenkins-project
The integration presented in this blog post will teach you to:
1)Schedule your build
2)Pull your code and data files from your GitHub repository to your Jenkins machine
3)Automatically trigger each build on the Jenkins server, after each Commit on your Git repository
Configuring GitHub:
Step 1: go to your GitHub repository and click on Settings.
Step 2: Click on Webhooks and then click on Add webhook.
Step 3: In the Payload URL field, paste your Jenkins environment URL. At the end of this URL add /github-webhook/. In the Content type select: application/json and leave the Secret field empty.
Step 4: In the page Which events would you like to trigger this webhook? choose Let me select individual events. Then, check Pull Requests and Pushes. At the end of this option, make sure that the Active option is checked and click on Add webhook.
Configuring Jenkins:
Step 5: In Jenkins, click on New Item to create a new project.
Step 6: Give your project a name, then choose Freestyle project and finally, click on OK.
Step 7: Click on the Source Code Management tab
Step 8: Click on Git and paste your GitHub repository URL in the Repository URL field.
Step 9: Click on the Build Triggers tab and then on the GitHub hook trigger for GITScm polling. Or, choose the trigger of your choice.
Triggering the Jenkins Job to Run with Every Code Commit:
Step 10: Click on the Build tab, then click on Add build step and choose Execute shell.
Step 11: To run a Taurus test, simply use the bzt command, followed by the name of your YML file and click on Save.
Step 12: Go back to your GitHub repository, edit the Taurus script and commit the changes. We will now see how Jenkins ran the script after the commit.
Step 13: Go back to your Jenkins project and you'll see that a new job was triggered automatically from the commit we made at the previous step. Click on the little arrow next to the job and choose Console Output.
https://www.blazemeter.com/blog/how-to-integrate-your-github-repository-to-your-jenkins-project
Perforce BlazeMeter
Your GitHub-Jenkins Tutorial: Integrating a GitHub Repo With Jenkins | Perforce BlazeMeter
This blog will give an overview of the GitHub-Jenkins integration via BlazeMeter. Learn how to integrate Jenkins with your GitHub projects for GitHub Jenkins harmony.
Jenkins Parameterized Builds
Jenkins is one of the most popular CI/CD tools in use today. It allows us to automate every aspect of the software lifecycle, from building all the way to deploying.
Defining Build Parameters:
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:
3) Then we click the Add Parameter button. From here, we must specify several pieces of information
Type: the data type for the parameter (string, Boolean, etc.)
Name: the name by which the parameter will be identified
Default value: an optional value that will be used when a user does not specify one
Description: optional text that describes how the parameter is used
A single Jenkins job or pipeline can have multiple parameters. The only restriction is the parameter name must be unique.
4) Jenkins supports several parameter types so add any Parameter type. Once we've defined one or more parameters, the next step is to utilize them. Below, we'll look at different ways to access parameter values.
With a traditional Jenkins job, we define one or more build steps. The most common build step is executing a shell script or Windows batch commands.
${package Type} / %package Type%
We can also create build steps that execute Gradle tasks or Maven goals. Both of these step types can access build parameters just like they would any other environment variable.
5) First, all build parameters are placed into a params variable. This means we can access a parameter value using dot notation
Second, the build parameters are added to the environment of the pipeline. This means we can use the shorter shell syntax inside a step that executes a shell script
6) The final step is to pass values for our parameters when we execute jobs.
Starting a job with Jenkins UI is the easiest way to pass build parameters. All we do is log in, navigate to our job, and click the Build with Parameters link
https://www.baeldung.com/ops/jenkins-parameterized-builds
Jenkins is one of the most popular CI/CD tools in use today. It allows us to automate every aspect of the software lifecycle, from building all the way to deploying.
Defining Build Parameters:
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:
3) Then we click the Add Parameter button. From here, we must specify several pieces of information
Type: the data type for the parameter (string, Boolean, etc.)
Name: the name by which the parameter will be identified
Default value: an optional value that will be used when a user does not specify one
Description: optional text that describes how the parameter is used
A single Jenkins job or pipeline can have multiple parameters. The only restriction is the parameter name must be unique.
4) Jenkins supports several parameter types so add any Parameter type. Once we've defined one or more parameters, the next step is to utilize them. Below, we'll look at different ways to access parameter values.
With a traditional Jenkins job, we define one or more build steps. The most common build step is executing a shell script or Windows batch commands.
${package Type} / %package Type%
We can also create build steps that execute Gradle tasks or Maven goals. Both of these step types can access build parameters just like they would any other environment variable.
5) First, all build parameters are placed into a params variable. This means we can access a parameter value using dot notation
Second, the build parameters are added to the environment of the pipeline. This means we can use the shorter shell syntax inside a step that executes a shell script
6) The final step is to pass values for our parameters when we execute jobs.
Starting a job with Jenkins UI is the easiest way to pass build parameters. All we do is log in, navigate to our job, and click the Build with Parameters link
https://www.baeldung.com/ops/jenkins-parameterized-builds
Baeldung on Ops
Guide to Jenkins Parameterized Builds | Baeldung on Ops
Learn how to use build parameters with both Jenkins jobs and pipelines
Jenkins Parameterized Builds
Jenkins is one of the most popular CI/CD tools in use today. It allows us to automate every aspect of the software lifecycle, from building all the way to deploying.
Defining Build Parameters:
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:
3) Then we click the Add Parameter button. From here, we must specify several pieces of information
Type: the data type for the parameter (string, Boolean, etc.)
Name: the name by which the parameter will be identified
Default value: an optional value that will be used when a user does not specify one
Description: optional text that describes how the parameter is used
A single Jenkins job or pipeline can have multiple parameters. The only restriction is the parameter name must be unique.
4) Jenkins supports several parameter types so add any Parameter type. Once we've defined one or more parameters, the next step is to utilize them. Below, we'll look at different ways to access parameter values.
With a traditional Jenkins job, we define one or more build steps. The most common build step is executing a shell script or Windows batch commands.
${package Type} / %package Type%
We can also create build steps that execute Gradle tasks or Maven goals. Both of these step types can access build parameters just like they would any other environment variable.
5) First, all build parameters are placed into a params variable. This means we can access a parameter value using dot notation
Second, the build parameters are added to the environment of the pipeline. This means we can use the shorter shell syntax inside a step that executes a shell script
6) The final step is to pass values for our parameters when we execute jobs.
Starting a job with Jenkins UI is the easiest way to pass build parameters. All we do is log in, navigate to our job, and click the Build with Parameters link
https://www.baeldung.com/ops/jenkins-parameterized-builds
Jenkins is one of the most popular CI/CD tools in use today. It allows us to automate every aspect of the software lifecycle, from building all the way to deploying.
Defining Build Parameters:
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:
3) Then we click the Add Parameter button. From here, we must specify several pieces of information
Type: the data type for the parameter (string, Boolean, etc.)
Name: the name by which the parameter will be identified
Default value: an optional value that will be used when a user does not specify one
Description: optional text that describes how the parameter is used
A single Jenkins job or pipeline can have multiple parameters. The only restriction is the parameter name must be unique.
4) Jenkins supports several parameter types so add any Parameter type. Once we've defined one or more parameters, the next step is to utilize them. Below, we'll look at different ways to access parameter values.
With a traditional Jenkins job, we define one or more build steps. The most common build step is executing a shell script or Windows batch commands.
${package Type} / %package Type%
We can also create build steps that execute Gradle tasks or Maven goals. Both of these step types can access build parameters just like they would any other environment variable.
5) First, all build parameters are placed into a params variable. This means we can access a parameter value using dot notation
Second, the build parameters are added to the environment of the pipeline. This means we can use the shorter shell syntax inside a step that executes a shell script
6) The final step is to pass values for our parameters when we execute jobs.
Starting a job with Jenkins UI is the easiest way to pass build parameters. All we do is log in, navigate to our job, and click the Build with Parameters link
https://www.baeldung.com/ops/jenkins-parameterized-builds
Baeldung on Ops
Guide to Jenkins Parameterized Builds | Baeldung on Ops
Learn how to use build parameters with both Jenkins jobs and pipelines
Installing jenkins using docker image:(MAC/LINUX)
Below Steps are suggested for installing jenkins in Docker.
Prerequisites
Minimum hardware requirements:
256 MB of RAM
1 GB of drive space
Recommended hardware configuration for a small team:
4 GB+ of RAM
50 GB+ of drive space
Software requirements:
Java,Web browser,Windows operating system
Downloading and running Jenkins in Docker.
There are several Docker images of Jenkins available.
macOS and Linux:
Step1: Open up a terminal window.
Step2: Create a bridge network in Docker using the following docker network create command:
#command docker network create jenkins
Step3: In order to execute Docker commands inside Jenkins nodes, download and run the docker:dind Docker image using the following docker run command:
docker run \
--name jenkins-docker \
--rm \
--detach \
--privileged \
--network jenkins \
--network-alias docker \
--env DOCKER_TLS_CERTDIR=/certs \
--volume jenkins-docker-certs:/certs/client \
--volume jenkins-data:/var/jenkins_home \
--publish 2376:2376 \
docker:dind \
--storage-driver overlay2
Step4:Customise official Jenkins Docker image, by executing below two steps:
a)Create Dockerfile with the following content:
FROM jenkins/jenkins:2.289.2-lts-jdk11
USER root
RUN apt-get update && apt-get install -y apt-transport-https \
ca-certificates curl gnupg2 \
software-properties-common
RUN curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add -
RUN apt-key fingerprint 0EBFCD88
RUN add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/debian \
$(lsb_release -cs) stable"
RUN apt-get update && apt-get install -y docker-ce-cli
USER jenkins
RUN jenkins-plugin-cli --plugins "blueocean:1.24.7 docker-workflow:1.26"
b)Build a new docker image from this Dockerfile and assign the image a meaningful name, e.g. "myjenkins-blueocean:1.1":
#command docker build -t myjenkins-blueocean:1.1.
Step5:Run your own myjenkins-blueocean:1.1 image as a container in Docker using the following docker run command:
docker run \
--name jenkins-blueocean \
--rm \
--detach \
--network jenkins \
--env DOCKER_HOST=tcp://docker:2376 \
--env DOCKER_CERT_PATH=/certs/client \
--env DOCKER_TLS_VERIFY=1 \
--publish 8080:8080 \
--publish 50000:50000 \
--volume jenkins-data:/var/jenkins_home \
--volume jenkins-docker-certs:/certs/client:ro \
myjenkins-blueocean:1.1
Step6:Proceed to the Post-installation setup wizard.
Below Steps are suggested for installing jenkins in Docker.
Prerequisites
Minimum hardware requirements:
256 MB of RAM
1 GB of drive space
Recommended hardware configuration for a small team:
4 GB+ of RAM
50 GB+ of drive space
Software requirements:
Java,Web browser,Windows operating system
Downloading and running Jenkins in Docker.
There are several Docker images of Jenkins available.
macOS and Linux:
Step1: Open up a terminal window.
Step2: Create a bridge network in Docker using the following docker network create command:
#command docker network create jenkins
Step3: In order to execute Docker commands inside Jenkins nodes, download and run the docker:dind Docker image using the following docker run command:
docker run \
--name jenkins-docker \
--rm \
--detach \
--privileged \
--network jenkins \
--network-alias docker \
--env DOCKER_TLS_CERTDIR=/certs \
--volume jenkins-docker-certs:/certs/client \
--volume jenkins-data:/var/jenkins_home \
--publish 2376:2376 \
docker:dind \
--storage-driver overlay2
Step4:Customise official Jenkins Docker image, by executing below two steps:
a)Create Dockerfile with the following content:
FROM jenkins/jenkins:2.289.2-lts-jdk11
USER root
RUN apt-get update && apt-get install -y apt-transport-https \
ca-certificates curl gnupg2 \
software-properties-common
RUN curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add -
RUN apt-key fingerprint 0EBFCD88
RUN add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/debian \
$(lsb_release -cs) stable"
RUN apt-get update && apt-get install -y docker-ce-cli
USER jenkins
RUN jenkins-plugin-cli --plugins "blueocean:1.24.7 docker-workflow:1.26"
b)Build a new docker image from this Dockerfile and assign the image a meaningful name, e.g. "myjenkins-blueocean:1.1":
#command docker build -t myjenkins-blueocean:1.1.
Step5:Run your own myjenkins-blueocean:1.1 image as a container in Docker using the following docker run command:
docker run \
--name jenkins-blueocean \
--rm \
--detach \
--network jenkins \
--env DOCKER_HOST=tcp://docker:2376 \
--env DOCKER_CERT_PATH=/certs/client \
--env DOCKER_TLS_VERIFY=1 \
--publish 8080:8080 \
--publish 50000:50000 \
--volume jenkins-data:/var/jenkins_home \
--volume jenkins-docker-certs:/certs/client:ro \
myjenkins-blueocean:1.1
Step6:Proceed to the Post-installation setup wizard.
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.
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.
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.
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
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.
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.
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:
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
Link: https://www.youtube.com/watch?v=pe8l-GyClZU&list=PLt8Y3NwVSVfacKDZLoR_rJ5mlRiGAvRoX&index=4
YouTube
AWS EKS: EKSCTL, Node Group, Kubectl Get Node, Kubectl Create Deployment, Kubernetes POD | EKS Part4
Hi-Tech Institution
Ph: 82202 17640 and 7092 90 91 92
All Technical Training, all over the world.
Cloud Computing, All Cloud Providers, Dev Ops, open-source tools, DevOps tools, Development
In this Video, We are discussing the AWS Real-Time Projects…
Ph: 82202 17640 and 7092 90 91 92
All Technical Training, all over the world.
Cloud Computing, All Cloud Providers, Dev Ops, open-source tools, DevOps tools, Development
In this Video, We are discussing the AWS Real-Time Projects…
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.
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
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