Jenkins CI - things I missed
Good day,% username%. Not long ago, I was asked to set up a Continuous Integration server, strongly recommending the use of Jenkins \ Hudson. I, as an uninformed person in these cases, decided to study tips and reviews on setting up CI systems on the network. I would like to thank Wolonter for this article, she helped me to understand the general concept and provided the widest range of useful plugins. But, as it turned out, far from everything that I wanted to implement, it was possible to find in the "Internet". For those who are interested in little (and not very) pranks and how I came to them - I ask for a cat.
Naturally, you need to remember to install jdk and check if jenkins is added to autoload. Something like this, occurred my first unsuccessful launch of Jenkins CI - ajp Jenkins ports clashed with one of the previously installed web servers (in combination with a non-relational database). After disabling ajp in the configuration file, everything fell into place, and finally I was able to see all the wonders with my own eyes.
I think everyone has something to add to this list. But, it seems, all the most important, I took into account. And I really hope that this small list will save a lot of time.
Formally, we wait for the server to start, run the unit tests on it, and turn off the server upon completion of the tests. Actually what was required. It seems to me that Jenkins means one project, it is impossible to do this.
')
Conclusion: sometimes it is still worth creating one project more than writing another bike.
I would also attribute the Build Name Setter Plugin to the stumbling problem. It's quite nice to see the name of the strum instead of the build number, but it's not that simple either. Since not all variables have a length attribute (for example, environment variables), with which you can trim the maximum length of a string. Agree, this view is not very motivating, but what if the length is not 30, but 255 characters?
Again, this problem can be solved with the preBuild groovy script. But in my situation it was easier to ask to make the names of strangers informative and not very long. It is very convenient when some inconveniences are solved not by bicycles, but by common sense.
Since I had projects that could be completed only by pressing the cross (which means “canceling the assembly”), I was very strongly oppressed by gray balls, for this I wanted to make the assembly successful (let it not spoil the statistics, I know that everything is correct) . I did not find the Plugin implementing it, but I found the Groovy Postbuild Plugin , which I actively promoted and anti-exploited above. So, the groovy postbuild API (let's call it that way), offers the buildSuccess () method to set a successful build state, and similar for other states. The problem is that this method does nothing. The whole family can only worsen the current state of the assembly, and since Aborted is much worse than Success, the build status has not changed. At one time on Jenkins, I found three issues asking for the implementation of the full functionality of changing the status of assemblies. The above piece of code is so simple that it simply could not fit my head. Asking the question: “may groovy have analog reflections?” The solution came instantly. Hopefully lovers ofperversions izyskov appreciate.
Build promotion . Yes, I know about the existence of Promoted Builds Plugin , but in my case, again, it did not help. There was one server that was updated only by hand and raised the manual stitch, and there was a project that was run every 2 hours, recognized the first branch of the project, downloaded it, and launched the unit tests. The number of assemblies in the projects was different. By agreement, it was decided to give a star if the last unit tests were successful. At what star is assigned only upon completion of the first server. Agree, a rather unusual implementation of promoted plugin sharpened purely for personal needs:
Fighting manual testing
It so happened that testers are different. And it’s a shame when they most likely know why something is wrong, but they are trying to push the responsibility in advance, arguing that “I did everything well, but it broke, you are guilty, you fix it”. It is for such cases that the AnsiColor Plugin helps very well. If this does not work, I strongly recommend using more offensive measures: Build User Vars Plugin - personal appeal makes your actions more shameful (how did the car know what my name was?). The main thing is not to overdo it, a situation is possible when the script does not work correctly, and the testers were afraid to ask for 3 days, because it was written to them in the console: “did you just do everything right?”. In this case, all the stones will fly into you. No one likes to look like a fool. But if you are upset - get something like this ( ! Red color is necessary to use ):
Auto start assemblies at startup . Suppose, due to a voltage surge \ lack of light, the server was rebooted. It started JenkinsCI, but did not start projects that should be constantly running? Every time to start handles - it is stupid. So, I really want a tick: “should this project be launched after a reboot?”
SVN \ Git custom branch + patch , if updated with the above images, it simply overwrites all existing local changes. This makes the application of patches very inconvenient. I really do not like my scripts, which cancel the patch, extort the desired branch and apply the patch back.
System Message. So that the result of running 'jenkins \ configuration \ System Message' is displayed on all pages, and not just on the view. And in general, I would like more plugins to change the appearance. Since First of all, it facilitates the work of managers, and the fewer questions on operation, the more time left to develop.
Rebuild Plugin. I want the Rebuild Plugin to learn how to stop the previous build, or else I clicked the rebuild button, and he only planned another build.
PS I am aware that the things I want are far from the essentials, but these are the things that I probably don’t have enough for complete happiness. I hope this article will be useful to someone.
Stages of the problem
And so, the initial task was to teach the system to simply run a web server, track changes in repositories, and run jUnit, TestNG and Selenium tests. Over time, this task is overgrown with a bunch of small things, which will be discussed later. It seems to be not difficult, but as it turned out, the first opinion is erroneous. With a clear conscience, I installed the centos 6 x64 on the virtual machine provided to me, and installed CI with several movements:sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo sudo rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key sudo yum install jenkins Naturally, you need to remember to install jdk and check if jenkins is added to autoload. Something like this, occurred my first unsuccessful launch of Jenkins CI - ajp Jenkins ports clashed with one of the previously installed web servers (in combination with a non-relational database). After disabling ajp in the configuration file, everything fell into place, and finally I was able to see all the wonders with my own eyes.
Errors
While I was setting up, I made a lot of mistakes, so I offer a small list for people who like to save their time:- Hierarchy of projects: if you have rather complex hierarchical dependencies, do not be too lazy to take a leaf and think about what depends on what, and how ideally it should be.
- Do not try to set up all projects at once. Try to bring each project to a working, intermediate state, and switch to the next. You will always have time to lead a marafet.
- Do not lick the project configuration until the intermediate configuration of all dependent projects. It is possible that the functionality that you decide to implement will be either very time consuming or not at all a task at this stage. Writing your plugin is not always a reasonable exercise.
- Project names. In some situations, renaming a project can be expensive. And if suddenly it turned out that you need to rename 130 projects without any structure in the titles? So you can’t write a script on your knee, and rename it with your hands - the toad presses. From simple tips to the names: it should not be very long, and should carry useful information. For example, if you have several versions of the same product running on different ports, why not call them in the spirit of “ProjectAbbr9587”, where 9587 is the port number. This name policy allows you to quickly understand, and reduces the possibility of confusion about what is at stake.
- If you have a choice of OS, on which plan to run Jenkins CI, then choose Unix in the case when you are a sure / advanced user. I have had most of the problems with the user access rights from which Jenkins and other applications are running. If this is not difficult, then try to run everything on behalf of one user.
- Remember, Jenkins, more Heidegger likes to produce entities. Therefore, in advance, increase the maximum number of threads and processes launched on behalf of the user's jenkins. Especially if you have a high-load CI server
- Do not install all the plugins you see. Often, a plugin is needed for "one-time use" and such a plugin can be replaced by an elementary script. They may not do anything useful, but eat extra resources (this does not apply to the ChuckNorris Plugin ).
- Estimate the resource consumption in advance. Think how many assemblies it makes sense to store. How many artifacts are really needed. If the server has low performance, think over the assembly schedule so that many resource-intensive assemblies are not running at the same time, and if you do not want to monitor the number of resources used, make sure that the maximum number of launched assemblies is greater or at least the same as projects.
- Informativeness jUnit, TestNG etc. If you run more than 5,000 units of tests that are not particularly grouped, then even a beautiful conclusion like Jenkins does not always have to be informative. Maybe it makes sense to regroup and post tests on different reports?
- Security. Do not forget about it. The transition to password access will not only temper the heat of sabotage-minded individuals, but in the event of a “hitting” of the head of “you broke everything”, there will be documented evidence refuting the argument “it was not me.”
- Do not forget that Jenkins CI is an auxiliary tool of the developer, and if you can’t do something, don’t dwell on it. Perhaps a brilliant decision will come to your mind in a week, or maybe in the same week you will realize that this feature is not so necessary. Sometimes this wisdom should be explained to the project manager, his desire to make everything beautiful is not always justified.
I think everyone has something to add to this list. But, it seems, all the most important, I took into account. And I really hope that this small list will save a lot of time.
First attempts
Naturally, after the first launch, it was unusual for me to look at the blue cups, but their color was not changed immediately. I set up SVN and Git, distributed the project hierarchy and everything seemed to work. The next day, on one task there were 4 scheduled assemblies, and the running one had already lasted about 9 hours. It turned out that it was on this day that a “bad” commit was made, which made the unit test go to endless waiting. Build-timeout Plugin came to the rescue. On the other hand, I had projects that should be in an “infinite build”. Ant task'i, who run the web server and in the assembly displayed a log of actions, which was very convenient. Naturally, these servers could be in a state of neglect for several days, and there is no point in stopping them unnecessarily, since they can work, show results to customers and so on. It was decided to create a project that at a certain time of the day checks if there is an update of the branch, and if it does, it downloads the update and restarts the assembly. The reaction of the managers who asked the question killed most of all: “Why is the redline of the project assembly reds? “Well, probably, because it's 10 am and the build has not written anything to the log for the last 6 hours.” I have not yet found the solution to repainting the stripes (see paragraph 11), but I think it is not difficult. Other problems arose with a non-terminating build: how do you run unit tests on a separate server without creating 2 projects? After all, to implement this, you need to run 2 ant tasks: a: start-server and junit, the first of which does not end. Why on a separate server you ask: because it is not good to score tests with the main web server. Moreover, the web server for tests should be run as needed and only for the duration of the unit tests, so as not to waste extra resources. Remembering all the possibilities of ant, it was decided to do something like this: <target name="start-server-with-units"> <parallel> <daemons> <antcall target="start-server"> </antcall> </daemons> <sequential> <waitfor maxwait="10" maxwaitunit="minute"> <socket server="localhost" port="${port}" /> </waitfor> <antcall target="junit"> </antcall> </sequential> </parallel> </target> Formally, we wait for the server to start, run the unit tests on it, and turn off the server upon completion of the tests. Actually what was required. It seems to me that Jenkins means one project, it is impossible to do this.
')
Branches
In my opinion, in Jenkins, the support for strumming is poorly implemented. “Svn: //svn.adress: port / $ {branchName}”, where branchName is an environment variable, often does not solve the problem. First, such assemblies can only be started by hand, or with the default parameter, but the launch of an assembly using Pall SCM is clearly not possible. If someone needs this functionality (as it turned out, I didn’t need it yet), then with a clear conscience he can write a groovy script that, when launched, will change the default branchName value to the value that was set at launch and then run the project on normal schedule, and if necessary, add a check for updates in the version control system. The disadvantage of this approach is that in a series of unnecessary assemblies, it is difficult to find something useful. But it also does not matter, in the same postBuild groovy script, you can fasten the "pedals", which will remove the "idle" assembly. Is it worth it to invent this miracle groovy script if you can create another project that will check for updates?Conclusion: sometimes it is still worth creating one project more than writing another bike.
I would also attribute the Build Name Setter Plugin to the stumbling problem. It's quite nice to see the name of the strum instead of the build number, but it's not that simple either. Since not all variables have a length attribute (for example, environment variables), with which you can trim the maximum length of a string. Agree, this view is not very motivating, but what if the length is not 30, but 255 characters?
Again, this problem can be solved with the preBuild groovy script. But in my situation it was easier to ask to make the names of strangers informative and not very long. It is very convenient when some inconveniences are solved not by bicycles, but by common sense.
Bicycles
We are all human, and we all want some comfort. I did not want to write my own plugin, there was no one to compromise with, and I wanted to achieve a result. For this, here I will describe, all those bicycles that somehow made my life easier. if(manager.build.result == hudson.model.Result.ABORTED){ manager.build.@result = hudson.model.Result.SUCCESS } Since I had projects that could be completed only by pressing the cross (which means “canceling the assembly”), I was very strongly oppressed by gray balls, for this I wanted to make the assembly successful (let it not spoil the statistics, I know that everything is correct) . I did not find the Plugin implementing it, but I found the Groovy Postbuild Plugin , which I actively promoted and anti-exploited above. So, the groovy postbuild API (let's call it that way), offers the buildSuccess () method to set a successful build state, and similar for other states. The problem is that this method does nothing. The whole family can only worsen the current state of the assembly, and since Aborted is much worse than Success, the build status has not changed. At one time on Jenkins, I found three issues asking for the implementation of the full functionality of changing the status of assemblies. The above piece of code is so simple that it simply could not fit my head. Asking the question: “may groovy have analog reflections?” The solution came instantly. Hopefully lovers of
Build promotion . Yes, I know about the existence of Promoted Builds Plugin , but in my case, again, it did not help. There was one server that was updated only by hand and raised the manual stitch, and there was a project that was run every 2 hours, recognized the first branch of the project, downloaded it, and launched the unit tests. The number of assemblies in the projects was different. By agreement, it was decided to give a star if the last unit tests were successful. At what star is assigned only upon completion of the first server. Agree, a rather unusual implementation of promoted plugin sharpened purely for personal needs:
item = hudson.model.Hudson.instance.getItem("jUnitJobName") def build = item.getLastBuild() if(build.getResult() == null){ build = build.getPreviousCompletedBuild() } def result = build.getResult() if(result == hudson.model.Result.SUCCESS){ manager.addBadge("star-gold.gif", "Success Unit Tests") } else { manager.addBadge("warning.gif", "Unit Tests Failure") } Fighting manual testing
It so happened that testers are different. And it’s a shame when they most likely know why something is wrong, but they are trying to push the responsibility in advance, arguing that “I did everything well, but it broke, you are guilty, you fix it”. It is for such cases that the AnsiColor Plugin helps very well. If this does not work, I strongly recommend using more offensive measures: Build User Vars Plugin - personal appeal makes your actions more shameful (how did the car know what my name was?). The main thing is not to overdo it, a situation is possible when the script does not work correctly, and the testers were afraid to ask for 3 days, because it was written to them in the console: “did you just do everything right?”. In this case, all the stones will fly into you. No one likes to look like a fool. But if you are upset - get something like this ( ! Red color is necessary to use ):
I'd love to
Well, in the end I will write things - which I really would like, but I will not write plugins. Maybe they are implemented, but I did not find them. For tips - I will be grateful.Auto start assemblies at startup . Suppose, due to a voltage surge \ lack of light, the server was rebooted. It started JenkinsCI, but did not start projects that should be constantly running? Every time to start handles - it is stupid. So, I really want a tick: “should this project be launched after a reboot?”
SVN \ Git custom branch + patch , if updated with the above images, it simply overwrites all existing local changes. This makes the application of patches very inconvenient. I really do not like my scripts, which cancel the patch, extort the desired branch and apply the patch back.
System Message. So that the result of running 'jenkins \ configuration \ System Message' is displayed on all pages, and not just on the view. And in general, I would like more plugins to change the appearance. Since First of all, it facilitates the work of managers, and the fewer questions on operation, the more time left to develop.
Rebuild Plugin. I want the Rebuild Plugin to learn how to stop the previous build, or else I clicked the rebuild button, and he only planned another build.
PS I am aware that the things I want are far from the essentials, but these are the things that I probably don’t have enough for complete happiness. I hope this article will be useful to someone.
Source: https://habr.com/ru/post/183558/
All Articles