jenkins - ghdrako/doc_snipets GitHub Wiki

• https://www.jenkins.io/doc/

# role for stable installation of the Jenkins
$ ansible-galaxy install opstree_devops.jenkins

Create a “hosts” file in the directory where you have cloned this ansible role. Define the server connection details where Jenkins should be installed and configured.

[jenkins]
10.1.1.100 ansible_ssh_user=ubuntu
ansible_ssh_private_key_file=<file_path>
Create a file named site.yml:
---
- hosts: jenkins
become: yes
roles:
-opstree_devops.jenkins

Once these two files are created, we can run the ansible by using this command:

$ ansible-playbook -i hosts site.yml

Some features supported by this role are as follows:

• Plugin installation while installing Jenkins
• Credentials management
• Global tool configuration
• Default package installation

$ docker run -p <host_port>:8080 -v <host_volume>:/var/jenkins_home jenkins/jenkins

We need to specify the following parameters

• host_port - The port on which Jenkins is visible outside of the container
• host_volume - This specifies the directory where the Jenkins home is mapped. It needs to be specified as volume because it contains the configuration, pipeline builds, and log

1. Prepare the volume directory $ mkdir $HOME/jenkins_home
2. Run the Jenkins container:

$ docker run -d -p 9090:8080 \
 -v $HOME/jenkins_home:/var/jenkins_home \ 
 --name jenkins jenkins/jenkins

# powershell
docker run -d -p 9090:8080 `
 -v C:\Projects\docker\jenkins\jenkins_home:/var/jenkins_home `
 --name jenkins jenkins/jenkins

3. Check whether Jenkins is running $ docker logs jenkins

After performing these steps, you can access your Jenkins instance at http://localhost:8080/

A job is set of tasks/subtasks implemented as a sequential process to perform different phases of the build release lifecycle.

It will typically include the following steps:

1. Pulling a change from the repository using a plugin, which will integrate with the given source code management system (e.g., a Git plugin).
2. Compiling a change by using a build tool like Maven and the Jenkins plugin (e.g., a Maven plugin).
3. Running unit/integration testing on the compiled code using the build tool again.
4. Running static analysis to check the code against coding standards and for dead code. This is done using a tool like SonarQube, which again is triggered using the Jenkins plugin.
5. Bundling the compiled and tested files in the form of library files, like .JAR or .WAR files. This also can be done by using a build tool that’s triggered using the Jenkins plugin.
6. Deploying this built library file on the production/test environment.
7. Running end-end tests on this deployed application using end- end test automation tools (e.g., UI automation tools like Selenium, Protractor, etc.).
8. Sending an email notification to the concerned team members regarding the status of this newly created application build. Includes the report of the end-end tests.

1. Create a job
2. Fill in the Enter an item name textbox by providing the name of the project in ex. hit_counter.
3. Click Freestyle project and then click OK
4. In the General tab, select the Discard old builds option so that the old builds do not eat up your disk space. Jenkins will do the housekeeping.
5. In the Source Code Management tab, select Git. In Repository URL, enter https://github.com//hit_counter ( need Git Plugin)
6. In the Build Triggers tab, select Poll SCM. This is where you specify how often you want Jenkins to perform the tests.
   • H/5 * * * * this means that you want Jenkins to perform the test every minute
   • H * * * *, this means the polling will be done every hour. If you do it as
   • H/15 * * * * the polling will be done every 15 minutes.
7. Click your mouse outside the textbox. If you entered the code correctly, Jenkins will show the message stating when it will execute the next job. Otherwise, it will display an error in red.
8. Click the Build tab. Click Add build step. Select Execute shell and write:

docker login -u <login> -p <password>
docker build -t hit_counter .
docker tag hit_counter akdevops/hit_counter
docker push akdevops/hit_counter

9. Click on Build Now from the menu on the left.

Information stored in Jenkins in the form of credentials can be shared among different Jenkins jobs as well. You do not need to specify username-passwords or private keys in the pipeline code in the human readable text. Each credential entry must have a unique Credentials ID. With this Credentials ID, you can use the stored authentication information in your Jenkins jobs.

• Basic authentication
• SSH authentication
• API token
• Certificate

The Jenkins Credentials plugin allows you to create credentials of different types in order to store the required authentication information. Once the credential entry has been created, you can refer to it by using the Credentials ID in the Jenkins job/pipeline with the help of the Credentials Binding plugin.

Scope defines where a particular credentials entry is available for usage. There are two types of scope:

• Global: A credential defined with Global scope is available for use in all Jenkins jobs created, as well as to the Jenkins server that works as a system.
• System: A credential defined with System scope is available only to the Jenkins instance to perform system administration functions like email authentication, agent connections, etc. This credential is not available for use in Jenkins jobs.

Domain is a way to group credentials used to access similar systems. By default, credential entries are created in the default domain. When you create in example a domain called “GitLab Credentials” and place the three credential entries under that domain. Now when you will configure access to your code repository from GitLab, you will only see the three credential entries instead of all other. Choosing the right one would be easy in that case.

• Jenkins Credentials Provider: This provider will provide credentials from the Jenkins root and will allow you to create Global and System types of credentials in Jenkins (default domain), as well as specific domains (non-default). Global types of credentials are provided to all jobs from all users.
• User Credentials Provider: Credentials created in the User Credentials Provider are only available to the jobs created and triggered by the user who created the credential. If I log out and back in as a different user, I will not see the credentials I just created.

After installing the plugin, go to the Manage Jenkins ➤ Configure Global Security link. This will open the Configure Global Security page. You will see the Role-Based Strategy option under the Authorization section.

Manage Roles: