In the previous article, we have built a continuous integration environment for Jenkins, and this article will guide us on how to use Jenkins for continuous integration. We want to achieve this: Jenkins automatically gets the latest code and executes the test when it reaches the project push code on GitHub, and notifies us by email of the test results. 1. Install and set up Git
First, the machine that executes the build installs Git to make it easy to download code from GitHub. Installation and Setup method reference: http://blog.csdn.net/liuchunming033/article/details/40862011
Second, specify the installation path for Git in Jenkins. The method is: Enter the Jenkins home page, click System Management, click System Settings, on the popup page, in the path to Git executable location input: "C:\Program Files (x86) \git\cmd\git.exe"
2. New Job
Click "New" On the Jenkins home page to enter the new job. Enter the job name and select "Build a free-style software project." Click OK. Follow the steps below to set up:
A, Restrict where this project can is run: used to specify which node the job executes on. This is where you fill in the node name (note that it must be a name). Here we select the Master node, which is the machine running the Jenkins server.
B, source management: Choose Git, enter the repository URL of the corresponding project on GitHub, for example, my is: git@github.com:liuchunming033/ Build.git, when the build is made, Jenkins will go to the URL to fetch your code to the current workspace. Credential Click Add here and select "SSH Username with private key" (I chose the other way, as if this is the only way to download code from GitHub), the "Install and set git" section of the private The key is pasted into the private key text box.
You can also choose the branch of the Git repository.
C, Build: We want to increase the build step-execute Windows Batch command, which fills in the script command to execute the build. Because I'm doing a test job, here's the command to execute the test script: Python. \unit.py
Click Save.
Note
To make the test run successfully on the slave node, set the necessary test environment on the slave. For example, the tests in my work are written in Python, so the Python environment will be installed on the machine where the tests are run. 3. Manually trigger the build
Go to the Job page and click "Build Now" on the left to make a build, which is a manual trigger build. The alternative step of the build should be to first clone the newest code from Gtihub to the current job workspace, which is workspace.
Once the build is complete, you can see that the code on GitHub has been downloaded to the job workspace.
When the build is complete, you can view the console output for this build, which should look like this:
Started by user anonymous Building on master in Workspace C:\Program Files (x86) \jenkins\jobs\pythonrun\workspace cloning The remote Git repository cloning repository git@github.com:liuchunming033/build.git > C:\Program Files (x86) \git\cmd \git.exe init C:\Program Files (x86) \jenkins\jobs\pythonrun\workspace # timeout=10 fetching upstream changes from Git@git Hub.com:liuchunming033/build.git > C:\Program Files (x86) \git\cmd\git.exe--version # timeout=10 using GIT_SSH to set Credentials > C:\Program Files (x86) \git\cmd\git.exe-c core.askpass=true fetch--tags--progress GIT@GITHUB.COM:LIUC Hunming033/build.git +refs/heads/*:refs/remotes/origin/* > C:\Program Files (x86) \git\cmd\git.exe Config Remote.origin.url Git@github.com:liuchunming033/build.git # timeout=10 > C:\Program Files (x86) \git\cmd\git.exe Config remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10 > C:\Program Files (x86) \git\cmd\ Git.exe config Remote.origin.url Git@github.com:liuchuNming033/build.git # timeout=10 fetching upstream changes from Git@github.com:liuchunming033/build.git using GIT_SSH to S ET credentials > C:\Program Files (x86) \git\cmd\git.exe-c core.askpass=true fetch--tags--progress git@github.com:l Iuchunming033/build.git +refs/heads/*:refs/remotes/origin/* > C:\Program Files (x86) \git\cmd\git.exe Rev-parse " Refs/remotes/origin/master^{commit} "# timeout=10 > C:\Program Files (x86) \git\cmd\git.exe Rev-parse" refs/remotes/ Origin/origin/master^{commit} "# timeout=10 Checking out Revision 5cccefe3d4a755e97e04dac7f901009f0ddc41d3 (refs/ Remotes/origin/master) > C:\Program Files (x86) \git\cmd\git.exe config Core.sparsecheckout # timeout=10 > C:\Progr Am Files (x86) \git\cmd\git.exe checkout-f 5cccefe3d4a755e97e04dac7f901009f0ddc41d3 > C:\Program Files (x86) \git\cmd \git.exe rev-list 5cccefe3d4a755e97e04dac7f901009f0ddc41d3 # timeout=10 [Workspace] $ cmd/c Call C:\Windows\TEMP\ Hudson1838296705227589066.bat C:\Program Files (x86)\jenkins\jobs\pythonrun\workspace>python. \unit.py. ----------------------------------------------------------------------Ran 2 Tests in 0.000s OK C:\Program Files (x86) \ Jenkins\jobs\pythonrun\workspace>exit 0 finished:success
4. Auto Trigger Build automatically trigger test when 4.1 push code
Now that we can manually trigger the continuous integration to run the test, the following configuration automatically triggers the test when the push code.
In the "Build triggers" area of the Job Settings page, tick "build when a-change is pushed to GitHub" and "Poll SCM", The two functions are to trigger Jenkins to build and periodically check the repository for updates when GitHub has a repository update, and to trigger Jenkins to build if there is an update. Note here that the schedule syntax, such as "H/2 * * * *" means checking every 2 minutes.
This way, when we modify the local test script unit.py and commit to local and push to GitHub, Jenkins is automatically triggered to test in 2 minutes.
After the test is complete, go to the latest build to view the build results as shown in the diagram below, and you can see that this build is due to the SCM change, and that the specific information for changes is a commit operation with an "add email address".
4.2 Periodic trigger test Sometimes we may need to run the tests periodically. For example, our test execution takes 30 minutes to complete, and we can set it to run every 1 hours, so that at night, when the Jekins runs the test, you can perform more rounds in one night. If we want to do it every 2 minutes, we can set it up like the following figure.
4.3 Other job trigger tests Jenkins allows the current job to be executed when the other job is completed, which is very useful for test engineers. We can set the pre-test environment deployment to a job called prepareenv, and only perform the test job if the job is completed, that is, the environment is built. In this case, we can build the trigger when we choose build after the other projects is built, and set the job that needs to depend on.
5, the operation after the construction
Sometimes we want to let Jenkins send us an email when the build fails. The content of the message is the console output at the time of the build. 5.1. Configure Email Notifications
From the Jenkins home page to System Management-system settings, in the "Mail Notification" area, enter the SMTP server address, Gmail as an example: SMTP server Input smtp.gmail.com, click Advanced ..., check the use SMTP Authentication,user Name and password Enter your Gmail email address and password. You can then check the test configuration by sending test e-mail and fill in your email address and then point to testing Configuraton, if you can receive a test message, the configuration is successful. Then click Save at the bottom of the page.
Next go to the Job page, click Configure to enter the job configuration page, the bottom of the ADD post-build action Select e-Mail Notification, and then in the recipients enter the email address to receive notifications, Multiple addresses are separated by English spaces (mailing list addresses are recommended).
5.2 jekins generating test reports
First, we need to generate a test report that Jekins can read, and after installing the JUnit plugin plugin, Jenkins is able to parse the test report in XML format and parse the XML report to generate the readability form after the test is complete.
If you are using Pytest to perform tests, you can generate reports in XML format as follows:
Py.test--junitxml Results.xml tests.py
This will generate a report called Result.xml in the root directory of the project's workspace.
Next, in the following "post-Build Action", click the "Add post-build Action" button and select "Publish JUnit test Result report" in the list. Since our report is output to the job root path, we fill in the XML file name here directly. As shown in the following figure.
Then, after the test is complete, you can see test result.