[xwiki-devs] [Brainstorming] Jenkins vs TC for XWiki
Hi devs, I’ve started doing an analysis of using TC instead of Jenkins for XWiki’s CI at http://design.xwiki.org/xwiki/bin/view/Proposal/ContinuousIntegrationSoftwar... I’ve started by listing the use cases that we use/need and started explaining how they are or can be implemented in both Jenkins and TC. My feeling at this point, without going further, is: * We’ve invested quite a lot already on Jenkins (configuration + scriptler groovy scripts + don’t send emails on false positives, etc) * Jenkins is open source and even though we have slowness issues ATM, even if we switch to TC, I believe we’ll go back to Jenkins at some point * TC has a nicer UI, more polished and better thought out but that’s not enough to compensate for the plugin ecosystem, the open source aspect and what we’ve invested already in Jenkins Thus at this point my personal feeling is that we should invest in diagnosing more the slowness issues in Jenkins and work with the Jenkins team/mailing list to find out the cause and fix it with them. WDYT? Thanks -Vincent
On 08/11/14 06:01, [email protected] wrote:
Hi devs,
I’ve started doing an analysis of using TC instead of Jenkins for XWiki’s CI at http://design.xwiki.org/xwiki/bin/view/Proposal/ContinuousIntegrationSoftwar...
I’ve started by listing the use cases that we use/need and started explaining how they are or can be implemented in both Jenkins and TC.
My feeling at this point, without going further, is: * We’ve invested quite a lot already on Jenkins (configuration + scriptler groovy scripts + don’t send emails on false positives, etc) * Jenkins is open source and even though we have slowness issues ATM, even if we switch to TC, I believe we’ll go back to Jenkins at some point * TC has a nicer UI, more polished and better thought out but that’s not enough to compensate for the plugin ecosystem, the open source aspect and what we’ve invested already in Jenkins
The latest Jenkins version has a redesigned UI, based on Bootstrap, and more "responsive".
Thus at this point my personal feeling is that we should invest in diagnosing more the slowness issues in Jenkins and work with the Jenkins team/mailing list to find out the cause and fix it with them.
WDYT?
Thanks
+1 for staying with Jenkins. -- Sergiu Dumitriu http://purl.org/net/sergiu
Hi Vincent, Currently, Jenkins caused me a lot of trouble while I do not use it much. I have no idea if TC would be better. From your analysis, there is a lot of question marks on TC, which means it could be the right tool but we do not have enough time to fully check it. I agree that its licensing could be also an issue. So, TC or improved Jenkins ? I don't care, but we definitely need a more stable and efficient tool. On Mon, Aug 11, 2014 at 12:01 PM, [email protected] <[email protected]> wrote:
Hi devs,
I’ve started doing an analysis of using TC instead of Jenkins for XWiki’s CI at http://design.xwiki.org/xwiki/bin/view/Proposal/ContinuousIntegrationSoftwar...
I’ve started by listing the use cases that we use/need and started explaining how they are or can be implemented in both Jenkins and TC.
My feeling at this point, without going further, is: * We’ve invested quite a lot already on Jenkins (configuration + scriptler groovy scripts + don’t send emails on false positives, etc) * Jenkins is open source and even though we have slowness issues ATM, even if we switch to TC, I believe we’ll go back to Jenkins at some point * TC has a nicer UI, more polished and better thought out but that’s not enough to compensate for the plugin ecosystem, the open source aspect and what we’ve invested already in Jenkins
Thus at this point my personal feeling is that we should invest in diagnosing more the slowness issues in Jenkins and work with the Jenkins team/mailing list to find out the cause and fix it with them.
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO
+1 for Jenkins or a similar open source alternative. Thanks, Eduard On Mon, Aug 11, 2014 at 5:35 PM, Denis Gervalle <[email protected]> wrote:
Hi Vincent,
Currently, Jenkins caused me a lot of trouble while I do not use it much. I have no idea if TC would be better. From your analysis, there is a lot of question marks on TC, which means it could be the right tool but we do not have enough time to fully check it. I agree that its licensing could be also an issue.
So, TC or improved Jenkins ? I don't care, but we definitely need a more stable and efficient tool.
On Mon, Aug 11, 2014 at 12:01 PM, [email protected] <[email protected]> wrote:
Hi devs,
I’ve started doing an analysis of using TC instead of Jenkins for XWiki’s CI at
http://design.xwiki.org/xwiki/bin/view/Proposal/ContinuousIntegrationSoftwar...
I’ve started by listing the use cases that we use/need and started explaining how they are or can be implemented in both Jenkins and TC.
My feeling at this point, without going further, is: * We’ve invested quite a lot already on Jenkins (configuration +
scriptler
groovy scripts + don’t send emails on false positives, etc) * Jenkins is open source and even though we have slowness issues ATM, even if we switch to TC, I believe we’ll go back to Jenkins at some point * TC has a nicer UI, more polished and better thought out but that’s not enough to compensate for the plugin ecosystem, the open source aspect and what we’ve invested already in Jenkins
Thus at this point my personal feeling is that we should invest in diagnosing more the slowness issues in Jenkins and work with the Jenkins team/mailing list to find out the cause and fix it with them.
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
FYI I’ve raised the following JIRA for Jenkins: https://issues.jenkins-ci.org/browse/JENKINS-24294 Thanks -Vincent On 11 Aug 2014 at 12:02:17, [email protected] ([email protected](mailto:[email protected])) wrote:
Hi devs,
I’ve started doing an analysis of using TC instead of Jenkins for XWiki’s CI at http://design.xwiki.org/xwiki/bin/view/Proposal/ContinuousIntegrationSoftwar...
I’ve started by listing the use cases that we use/need and started explaining how they are or can be implemented in both Jenkins and TC.
My feeling at this point, without going further, is: * We’ve invested quite a lot already on Jenkins (configuration + scriptler groovy scripts + don’t send emails on false positives, etc) * Jenkins is open source and even though we have slowness issues ATM, even if we switch to TC, I believe we’ll go back to Jenkins at some point * TC has a nicer UI, more polished and better thought out but that’s not enough to compensate for the plugin ecosystem, the open source aspect and what we’ve invested already in Jenkins
Thus at this point my personal feeling is that we should invest in diagnosing more the slowness issues in Jenkins and work with the Jenkins team/mailing list to find out the cause and fix it with them.
WDYT?
Thanks -Vincent
Hi devs. Could it be a benefit to use SSD drive instead of a classic hard drive on the server? Thanks, Guillaume 2014-08-17 14:09 GMT+02:00 [email protected] <[email protected]>:
FYI I’ve raised the following JIRA for Jenkins: https://issues.jenkins-ci.org/browse/JENKINS-24294
Thanks -Vincent
On 11 Aug 2014 at 12:02:17, [email protected] ([email protected](mailto: [email protected])) wrote:
Hi devs,
I’ve started doing an analysis of using TC instead of Jenkins for XWiki’s CI at http://design.xwiki.org/xwiki/bin/view/Proposal/ContinuousIntegrationSoftwar...
I’ve started by listing the use cases that we use/need and started explaining how they are or can be implemented in both Jenkins and TC.
My feeling at this point, without going further, is: * We’ve invested quite a lot already on Jenkins (configuration + scriptler groovy scripts + don’t send emails on false positives, etc) * Jenkins is open source and even though we have slowness issues ATM, even if we switch to TC, I believe we’ll go back to Jenkins at some point * TC has a nicer UI, more polished and better thought out but that’s not enough to compensate for the plugin ecosystem, the open source aspect and what we’ve invested already in Jenkins
Thus at this point my personal feeling is that we should invest in diagnosing more the slowness issues in Jenkins and work with the Jenkins team/mailing list to find out the cause and fix it with them.
WDYT?
Thanks -Vincent
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hello! This server is actually a virtual machine, hosted on a dedicated server provided by XWikiSAS, however, adding a SSD would not be possible due to two reasons: 1. This server is an older tier, for which the provider might not support upgrades anymore (as they completely redesigned their offer) 2. it also hosts Maven and Nexus on the same VM, which use an extremely large amount of disk space (close to 1TB in total). Please note that this problem is not hardware related, since when Jenkins is slow, it's using about 750% cpu (as far as I could observe at certain points), so almost all of the 8 cores available on the whole dedicated server, which means that something is broken which causes it to go wild. Adding better hardware is just sweeping the dust under the carpet, and then grabbing a better, SSD-powered carpet, and putting that on top of the first carpet :) On Mon, Aug 18, 2014 at 11:57 AM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:
Hi devs.
Could it be a benefit to use SSD drive instead of a classic hard drive on the server?
Thanks, Guillaume
2014-08-17 14:09 GMT+02:00 [email protected] <[email protected]>:
FYI I’ve raised the following JIRA for Jenkins: https://issues.jenkins-ci.org/browse/JENKINS-24294
Thanks -Vincent
On 11 Aug 2014 at 12:02:17, [email protected] ([email protected] (mailto: [email protected])) wrote:
Hi devs,
I’ve started doing an analysis of using TC instead of Jenkins for XWiki’s CI at
http://design.xwiki.org/xwiki/bin/view/Proposal/ContinuousIntegrationSoftwar...
I’ve started by listing the use cases that we use/need and started
explaining how they are or can be implemented in both Jenkins and TC.
My feeling at this point, without going further, is: * We’ve invested quite a lot already on Jenkins (configuration +
scriptler groovy scripts + don’t send emails on false positives, etc)
* Jenkins is open source and even though we have slowness issues ATM, even if we switch to TC, I believe we’ll go back to Jenkins at some point * TC has a nicer UI, more polished and better thought out but that’s not enough to compensate for the plugin ecosystem, the open source aspect and what we’ve invested already in Jenkins
Thus at this point my personal feeling is that we should invest in diagnosing more the slowness issues in Jenkins and work with the Jenkins team/mailing list to find out the cause and fix it with them.
WDYT?
Thanks -Vincent
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Best Regards, Daniel Patriche XWiki SAS SysAdmin
FYI, since that issue was closed, I’ve raised the issue on the jenkins mailing list: https://groups.google.com/forum/#!topic/jenkinsci-users/L6ZSESU5x6s Thanks -Vincent On 17 Aug 2014 at 14:09:44, [email protected] ([email protected](mailto:[email protected])) wrote:
FYI I’ve raised the following JIRA for Jenkins: https://issues.jenkins-ci.org/browse/JENKINS-24294
Thanks -Vincent
On 11 Aug 2014 at 12:02:17, [email protected] ([email protected](mailto:[email protected])) wrote:
Hi devs,
I’ve started doing an analysis of using TC instead of Jenkins for XWiki’s CI at http://design.xwiki.org/xwiki/bin/view/Proposal/ContinuousIntegrationSoftwar...
I’ve started by listing the use cases that we use/need and started explaining how they are or can be implemented in both Jenkins and TC.
My feeling at this point, without going further, is: * We’ve invested quite a lot already on Jenkins (configuration + scriptler groovy scripts + don’t send emails on false positives, etc) * Jenkins is open source and even though we have slowness issues ATM, even if we switch to TC, I believe we’ll go back to Jenkins at some point * TC has a nicer UI, more polished and better thought out but that’s not enough to compensate for the plugin ecosystem, the open source aspect and what we’ve invested already in Jenkins
Thus at this point my personal feeling is that we should invest in diagnosing more the slowness issues in Jenkins and work with the Jenkins team/mailing list to find out the cause and fix it with them.
WDYT?
Thanks -Vincent
I`ve also registered on the jenkins-users list hoping for a helpful reply. This problem is happening now *too* often and it has become a problem. Either there is something in our build that jenkins does not like, either it's a slave, a plugin, some configuration or even the hardware, we *really* need to get to the bottom of this since it's affecting out productivity. Crossing fingers... :) -Eduard On Sat, Aug 23, 2014 at 6:31 PM, [email protected] <[email protected]> wrote:
FYI, since that issue was closed, I’ve raised the issue on the jenkins mailing list: https://groups.google.com/forum/#!topic/jenkinsci-users/L6ZSESU5x6s
Thanks -Vincent
On 17 Aug 2014 at 14:09:44, [email protected] ([email protected](mailto: [email protected])) wrote:
FYI I’ve raised the following JIRA for Jenkins: https://issues.jenkins-ci.org/browse/JENKINS-24294
Thanks -Vincent
On 11 Aug 2014 at 12:02:17, [email protected] ([email protected] (mailto:[email protected])) wrote:
Hi devs,
I’ve started doing an analysis of using TC instead of Jenkins for XWiki’s CI at http://design.xwiki.org/xwiki/bin/view/Proposal/ContinuousIntegrationSoftwar...
I’ve started by listing the use cases that we use/need and started explaining how they are or can be implemented in both Jenkins and TC.
My feeling at this point, without going further, is: * We’ve invested quite a lot already on Jenkins (configuration + scriptler groovy scripts + don’t send emails on false positives, etc) * Jenkins is open source and even though we have slowness issues ATM, even if we switch to TC, I believe we’ll go back to Jenkins at some point * TC has a nicer UI, more polished and better thought out but that’s not enough to compensate for the plugin ecosystem, the open source aspect and what we’ve invested already in Jenkins
Thus at this point my personal feeling is that we should invest in diagnosing more the slowness issues in Jenkins and work with the Jenkins team/mailing list to find out the cause and fix it with them.
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
FTR I’m going to try disabling artifact archiving in Jenkins since: 1) It takes an awufully long at the end of each build to do that 2) It takes a lot of disk space (even though we only keep the last 20 builds) 3) We shouldn’t need that since our build already pushes artifacts in the local maven repository Thanks -Vincent On 23 Aug 2014 at 21:40:05, Eduard Moraru ([email protected]) wrote: I`ve also registered on the jenkins-users list hoping for a helpful reply. This problem is happening now *too* often and it has become a problem. Either there is something in our build that jenkins does not like, either it's a slave, a plugin, some configuration or even the hardware, we *really* need to get to the bottom of this since it's affecting out productivity. Crossing fingers... :) -Eduard On Sat, Aug 23, 2014 at 6:31 PM, [email protected] <[email protected]> wrote:
FYI, since that issue was closed, I’ve raised the issue on the jenkins mailing list: https://groups.google.com/forum/#!topic/jenkinsci-users/L6ZSESU5x6s
Thanks -Vincent
On 17 Aug 2014 at 14:09:44, [email protected] ([email protected](mailto: [email protected])) wrote:
FYI I’ve raised the following JIRA for Jenkins: https://issues.jenkins-ci.org/browse/JENKINS-24294
Thanks -Vincent
On 11 Aug 2014 at 12:02:17, [email protected] ([email protected] (mailto:[email protected])) wrote:
Hi devs,
I’ve started doing an analysis of using TC instead of Jenkins for XWiki’s CI at http://design.xwiki.org/xwiki/bin/view/Proposal/ContinuousIntegrationSoftwar...
I’ve started by listing the use cases that we use/need and started explaining how they are or can be implemented in both Jenkins and TC.
My feeling at this point, without going further, is: * We’ve invested quite a lot already on Jenkins (configuration + scriptler groovy scripts + don’t send emails on false positives, etc) * Jenkins is open source and even though we have slowness issues ATM, even if we switch to TC, I believe we’ll go back to Jenkins at some point * TC has a nicer UI, more polished and better thought out but that’s not enough to compensate for the plugin ecosystem, the open source aspect and what we’ve invested already in Jenkins
Thus at this point my personal feeling is that we should invest in diagnosing more the slowness issues in Jenkins and work with the Jenkins team/mailing list to find out the cause and fix it with them.
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Done, I’ve done it with a scriptlet script. It’s easy to roll back if need be. Let’s see how it goes. Note that new jobs won’t have the option disable by default so we’ll need to handle this if it proves successful. FTR ci.xwiki.org is really fast for me ATM, not sure if this was caused by my change (I doubt it). Thanks -Vincent On 25 Aug 2014 at 10:04:10, [email protected] ([email protected]) wrote: FTR I’m going to try disabling artifact archiving in Jenkins since: 1) It takes an awufully long at the end of each build to do that 2) It takes a lot of disk space (even though we only keep the last 20 builds) 3) We shouldn’t need that since our build already pushes artifacts in the local maven repository Thanks -Vincent On 23 Aug 2014 at 21:40:05, Eduard Moraru ([email protected]) wrote: I`ve also registered on the jenkins-users list hoping for a helpful reply. This problem is happening now *too* often and it has become a problem. Either there is something in our build that jenkins does not like, either it's a slave, a plugin, some configuration or even the hardware, we *really* need to get to the bottom of this since it's affecting out productivity. Crossing fingers... :) -Eduard On Sat, Aug 23, 2014 at 6:31 PM, [email protected] <[email protected]> wrote:
FYI, since that issue was closed, I’ve raised the issue on the jenkins mailing list: https://groups.google.com/forum/#!topic/jenkinsci-users/L6ZSESU5x6s
Thanks -Vincent
On 17 Aug 2014 at 14:09:44, [email protected] ([email protected](mailto: [email protected])) wrote:
FYI I’ve raised the following JIRA for Jenkins: https://issues.jenkins-ci.org/browse/JENKINS-24294
Thanks -Vincent
On 11 Aug 2014 at 12:02:17, [email protected] ([email protected] (mailto:[email protected])) wrote:
Hi devs,
I’ve started doing an analysis of using TC instead of Jenkins for XWiki’s CI at http://design.xwiki.org/xwiki/bin/view/Proposal/ContinuousIntegrationSoftwar...
I’ve started by listing the use cases that we use/need and started explaining how they are or can be implemented in both Jenkins and TC.
My feeling at this point, without going further, is: * We’ve invested quite a lot already on Jenkins (configuration + scriptler groovy scripts + don’t send emails on false positives, etc) * Jenkins is open source and even though we have slowness issues ATM, even if we switch to TC, I believe we’ll go back to Jenkins at some point * TC has a nicer UI, more polished and better thought out but that’s not enough to compensate for the plugin ecosystem, the open source aspect and what we’ve invested already in Jenkins
Thus at this point my personal feeling is that we should invest in diagnosing more the slowness issues in Jenkins and work with the Jenkins team/mailing list to find out the cause and fix it with them.
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1 for spending time on investigating and fixing Jenkins. Thanks, Marius On Mon, Aug 11, 2014 at 1:01 PM, [email protected] <[email protected]> wrote:
Hi devs,
I’ve started doing an analysis of using TC instead of Jenkins for XWiki’s CI at http://design.xwiki.org/xwiki/bin/view/Proposal/ContinuousIntegrationSoftwar...
I’ve started by listing the use cases that we use/need and started explaining how they are or can be implemented in both Jenkins and TC.
My feeling at this point, without going further, is: * We’ve invested quite a lot already on Jenkins (configuration + scriptler groovy scripts + don’t send emails on false positives, etc) * Jenkins is open source and even though we have slowness issues ATM, even if we switch to TC, I believe we’ll go back to Jenkins at some point * TC has a nicer UI, more polished and better thought out but that’s not enough to compensate for the plugin ecosystem, the open source aspect and what we’ve invested already in Jenkins
Thus at this point my personal feeling is that we should invest in diagnosing more the slowness issues in Jenkins and work with the Jenkins team/mailing list to find out the cause and fix it with them.
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (7)
-
Daniel Patriche -
Denis Gervalle -
Eduard Moraru -
Guillaume "Louis-Marie" Delhumeau -
Marius Dumitru Florea -
Sergiu Dumitriu -
vincent＠massol.net