|
| Re: Jenkins plugins on Hudson [message #1204045 is a reply to message #1203064] |
Sat, 23 November 2013 00:05   |
 Winston Prakash
Messages: 534
Registered: August 2011
Location: Fremont, CA USA |
Senior Member |
|
|
Hi Max, welcome back. We have been asked this question several times. A very relevant question.
A short answer is we port plugin based on user request.
Long answer is ..
We used to blindly port most of the plugins from Jenkins, with simple automation tool and a load check. But we started getting several complain that new version of the plugins are broken and they had to revert to older version. Most of the users seems to be happy with older version that puzzled us. Either they are not interested in the new functionalities or managing with the older version. So we decided to port plugins based on user request only.
However, this model is not correct. How do we know, if we don't port the plugins and make them work adequately in Hudson, that the users are not interested in the new features. They may not be using it, just because it is not there. So plugins must be ported, but we don't have resources to port each and every plugin when they appear in Jenkins update center.
So next option we thought would be to keep track on features added to plugins (even users are not explicitly asking) and if we find any of the new added features may be useful then we port those plugins. However, this is also resource consuming.
The best option we came up with is, analyze the usage statistics of all the plugins and pick the top used plugins (our analysis showed, 95% of the user use about 30 or so plugins and 80 or so plugins are used by 99% of the users). So, we divide these plugins in to Manadatory (needed for Hudson to work), Featured and Recommended in the update center. Rest of the plugins are marked as Others
You can see the details of our analysis here
http://wiki.eclipse.org/images/2/2c/HudsonPluginUsageAnalysis.pdf
We constantly monitor these widely used plugins and port them accordingly at
https://github.com/hudson3-plugins
True, the version of Parameterized trigger plugin at Husdon is old. But truly the new features added are needed for every day use?. A month ago, there was a request to port Conditional Step build plugin, at that time I looked at Parameterized trigger plugin and did not find any interesting feature that warranted a port.
Having said that we may overlook features, seems trivial to us, but important for users. So we certainly depend on the user to tell us the plugin they want us to port via filing a bug at https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Hudson (component Plugins). Some time, we may not be able to attend those immediately, but we will do the porting eventually.
Hope this helps. Feel free to ask more questions.
Winston Prakash
Eclipse Hudson team
|
|
|
| Re: Jenkins plugins on Hudson [message #1211602 is a reply to message #1204045] |
Tue, 26 November 2013 14:23 |
Markus Buchner
Messages: 11
Registered: May 2013 |
Junior Member |
|
|
Hi,
Thanks for the answer - the procedure you mentioned seams okay for me.
One or two other questions:
- we updated to 3.1 but we had the following issues and i dont know if they are already known:
1) the sidebar doesn't display release builds anymore & size & so on (see attachment -> sorry just recognized that i cannot upload a file)
- we want this feature back -> or at least a list of the last release builds or something like that.
2) when a job is moved the symlinks are not copied correctly! Instead all build data is duplicated! This was a showstopper on our side! Is this bug fixed in 3.1.1?
Thanks Max
[Updated on: Tue, 26 November 2013 14:24] Report message to a moderator |
|
|
|
|
|
| Re: Jenkins plugins on Hudson [message #1214600 is a reply to message #1212857] |
Wed, 27 November 2013 19:28 |
Winston Prakash
Messages: 534
Registered: August 2011
Location: Fremont, CA USA |
Senior Member |
|
|
Hi Markus, the logic to move job from one team to another is exactly same as renaming a job that exists in Hudson/Jenkins for years now. On Windows Hudson does not create symlink(shortcut), so not an issue. The issue may occur only on Unix like systems (Linux, Solaris, Mac etc).
The logic used for renaming or moving job between teams is simple
- Hudson first tries to use Java I/O File.renameTo() (preserves symlink). renameTo is tried 5 times before using alternative method.
- If for some reason File.renameTo() fails, then Ant Task "move" is used to move the content. This Ant Task does not guarantee to preserve symlinks.
One of our QA engineers tried on a Linux machine. She noticed that after moving the jobs to another team, symlinks are preserved correctly in the moved jobs.
I tested on MAC. My result was interesting. I created 4 jobs and moved one by one to a team. 3 of them moved with symlinks preserved. However while moving one job, the symlinks were not preserved. I tried to create couple of more jobs and moved them to a team and the symlinks were preserved
We used JDK 7.0 to run Hudson, in case if that makes any difference.
Note: One important thing to keep in mind; if the job is moved across file system, then the symlinks are not preserved.
Winston Prakash
Eclipse Hudson team
|
|
|
Powered by
FUDForum. Page generated in 0.02960 seconds
Search
Help
Register
Login
Home
