Community
Participate
Working Groups
We need to ask ourselves the same question that was posed to the Apache mailing list recently. http://mail-archives.apache.org/mod_mbox/www-builds/201102.mbox/%3CAANLkTikCymNt_HxHSC9-JJfK6U+LSs8BOf2j_-unhjXw@mail.gmail.com%3E 1. Do we go with Hudson or Jenkins? 2. If we go with Jenkins, do we then rename hudson.eclipse.org to jenkins.eclipse.org? If we opt to go for Jenkins, I think we should still maintain status quo for now until Indigo goes GA and/or when the current Hudson instance needs to be brought down and updated [for whatever reasons the webmasters deem appropriate]. No point causing more work for the webmasters then is necessary.
I think we should move to Jenkins and do it post Indigo. This allows time for the "dust" to settle :)
I would also vote for Jenkins.
Since Hudson is now an Eclipse project, we'll eat our own dog food.
(In reply to Denis Roy from comment #3) > Since Hudson is now an Eclipse project, we'll eat our own dog food. While that seemed logical at the time, Jenkins has clearly won the CI wars. We're missing out on a lot of plug-ins that appear to be Jenkins only. As an example, we've been struggling with the Andmore instance getting the UI tests not to hang. I wanted to try the Xvnc recorder to see if we can see what was happening. No dice on Hudson. I also wonder if Jenkins scales better. I have first hand knowledge of a massive Jenkins instance that had hundreds if not thousands of jobs. All the real work is supposed to be done in slaves anyway. Then we could get rid of this HIPP craziness. Reopening to see if this can get any traction.
(In reply to Doug Schaefer from comment #4) > I also wonder if Jenkins scales better. I have first hand knowledge of a > massive Jenkins instance that had hundreds if not thousands of jobs. All the > real work is supposed to be done in slaves anyway. Then we could get rid of > this HIPP craziness. Where is this massive Jenkins anyway? URL please, I want to poke around.
(In reply to Denis Roy from comment #5) > (In reply to Doug Schaefer from comment #4) > > I also wonder if Jenkins scales better. I have first hand knowledge of a > > massive Jenkins instance that had hundreds if not thousands of jobs. All the > > real work is supposed to be done in slaves anyway. Then we could get rid of > > this HIPP craziness. > > Where is this massive Jenkins anyway? URL please, I want to poke around. http://jenkins.rim.net, but you probably can't get to it :). And most of the projects there have moved over to Electric Commander anyway. We have another one here at QNX that has about 600 jobs running from it. Again, the key is to have enough slaves to actually do the builds. That's another advantage a single Jenkins instance has, it can load balance the builds to your slave pool. If every project has it's own instance, it's hard to share resources.
> http://jenkins.rim.net, but you probably can't get to it :) Massive Jenkins infra performs well when it's sheltered behind corporate firewall. Apples != Oranges. Gotcha. > That's another advantage a single Jenkins instance has There's no arguing the advantages (and disadvantages) of a single instance. Scalability is the only reason we went with HIPP. That's all discussed in the HIPP bug.
(In reply to Denis Roy from comment #7) > > http://jenkins.rim.net, but you probably can't get to it :) > > Massive Jenkins infra performs well when it's sheltered behind corporate > firewall. > > Apples != Oranges. Gotcha. Well, certainly Eclipse's problems aren't unique. Here's a pretty good example: https://jenkins.qa.ubuntu.com/view/All/ taken from the list found here: https://wiki.jenkins-ci.org/pages/viewpage.action?pageId=58001258 There's no Gotcha to get. Just trying to make things better for myself and my fellow committers.
I think I really hate Hudson, but I hate also jenkins: it's unstable, bloated and the JSON API is a joke. builds.apache.org which is based on jenkins is always broken in a way or in another. My jenkins instance at work is always flappy once a week and need a reboot.. I used drone.io and it worked like a charm and it's simplicity is a breath. Just scheduling job inside docker container. https://github.com/drone/drone It's linux only but it's rock solid. It's supporting java and dozen of other languages.
(In reply to Julien Vermillard from comment #9) > I think I really hate Hudson, but I hate also jenkins: > it's unstable, bloated and the JSON API is a joke. > builds.apache.org which is based on jenkins is always broken in a way or in > another. > > My jenkins instance at work is always flappy once a week and need a reboot.. You mileage may vary I guess. We used to have issues with our Jenkins but that was mainly our fault and the crazy nfs mounts we were trying to do. Since we simplified our structure, it's been rock solid. > I used drone.io and it worked like a charm and it's simplicity is a breath. > Just scheduling job inside docker container. > https://github.com/drone/drone > It's linux only but it's rock solid. It's supporting java and dozen of other > languages. Jenkins supports jobs in docker containers. Part of the reason for re-opening this bug was to try and follow where the community went. I can't tell if there's as big a community behind drone.
Speaking of community, it would be interesting to know how many committers use Jenkins outside of Eclipse and how many use Hudson. From the few I've talked to (I haven't talked to any who use Hudson outside Eclipse), part of the problem is you get to know how Jenkins works and set-up in your day job and when you come to Eclipse and Hudson and it's just seems like a big step back. That could be just perception, but I've brought up a couple of examples here (Xvnc recorder and Docker) which make it seem more real.
Hudson/Jenkins are both kind of old-school. If we're going to revisit CI at Eclipse.org why not investigate more modern components: Gradle: https://gradle.org/ Buck: http://facebook.github.io/buck/
Gradle and Buck are build systems (like Maven or Make), not CI tools. Example of modern Hudson/Jenkins are: - https://travis-ci.org/ (MIT) - https://drone.io/ (Apache 2 Licence) - http://www.thoughtworks.com/products/go-continuous-delivery (Apache 2 Licence) - https://circleci.com/ (proprietary)
(In reply to Mikael Barbero from comment #13) > Gradle and Buck are build systems (like Maven or Make), not CI tools. > > Example of modern Hudson/Jenkins are: > > - https://travis-ci.org/ (MIT) > - https://drone.io/ (Apache 2 Licence) > - http://www.thoughtworks.com/products/go-continuous-delivery (Apache 2 > Licence) > - https://circleci.com/ (proprietary) I've never used it but I also heard of: http://buildbot.net/
(In reply to Denis Roy from comment #12) > Hudson/Jenkins are both kind of old-school. If we're going to revisit CI at > Eclipse.org why not investigate more modern components: I don't mind thinking outside the box. We just need to make sure its significantly better and worth the investment that everyone setting up and using the CI system needs to make. travis-ci is probably the closest to what we need that I've seen. But I can't see where the source is. Jenkins seems to be the one I hear about most and I know committers use for their in house needs. That familiarity reduces the overall investment we have to make.
(In reply to Doug Schaefer from comment #11) > Speaking of community, it would be interesting to know how many committers > use Jenkins outside of Eclipse and how many use Hudson. > > From the few I've talked to (I haven't talked to any who use Hudson outside > Eclipse), part of the problem is you get to know how Jenkins works and > set-up in your day job and when you come to Eclipse and Hudson and it's just > seems like a big step back. That could be just perception, but I've brought > up a couple of examples here (Xvnc recorder and Docker) which make it seem > more real. +1 eclipse.org is the only place I use Hudson. I vote to switch to Jenkins. BTW, the trend seems to clearly go towards Jenkins: http://www.google.ca/trends/explore#q=jenkins%20build%2C%20hudson%20build&cmpt=q&tz=
> Jenkins seems to be the one I hear about most and I know committers use for > their in house needs. That familiarity reduces the overall investment we > have to make. +1 to that.
I don't have a strong opinion about this but it's pretty obvious that Hudson has lost a lot of momentum and Jenkins has taken over. Documentation on Hudson is pretty sparse compared to Jenkins. Also, we had a few cases where things were working in Jenkins but not in Hudson. To be fair, after reporting the bugs and waiting for a bit, the bugs were fixed in Hudson too. All things considered, it seems inevitable that Eclipse will have to switch to Jenkins eventually so why not start planning the transition?
We have another important plug-in that Jenkins has that Hudson does not (apparently). That's the github pull request build plug-in which gives projects who chose github over gerrit the ability to do verification jobs when contributors submit pull requests.
(In reply to Denis Roy from comment #5) > (In reply to Doug Schaefer from comment #4) > > I also wonder if Jenkins scales better. I have first hand knowledge of a > > massive Jenkins instance that had hundreds if not thousands of jobs. All the > > real work is supposed to be done in slaves anyway. Then we could get rid of > > this HIPP craziness. > > Where is this massive Jenkins anyway? URL please, I want to poke around. Probably the best public massive Jenkins instance to look at is OpenStack's Jenkins [1]. OpenStack also details some of their infra here [2]. With 1000s of jobs configured in a multi-master setup capable of spinning up dynamic slaves for each build. Using gearman we can allow jobs to be queued across multiple Jenkins masters that have unused slaves which helps with the Jenkins scaling issues. Using Jenkins Job Builder [2] we can manage project jobs in Gerrit and easily deploy them to multiple master instances. Since jobs are managed in Gerrit we can make part of our infra become a project and thus take advantage of code review and CI to verify job configuration. The OpenStack model is the model we're moving towards at LF. [1] https://jenkins.openstack.org/view/All/ [2] http://ci.openstack.org/jenkins.html [3] http://ci.openstack.org/jenkins-job-builder/
My biggest reason for wanting to use Jenkins is that the plugin community and third party plugins I need to really make integration with Github easier on my project are maintained by that community. If Hudson had the equivalent plugins then I'd be fine with using it. But right now I'm having to do work arounds, have filed bugs, and have had just general frustration. Maybe it is because our project choose to stay on Github, as the general barrier to getting somebody to do submit code is less. A new tool doesn't need to be learned. We could use Gerrit, but that still leaves a huge workflow whole for those that would send Pull Requests in through github. As long as we don't go with Travis CI, I'm fine. I HATE that CI system. I just want something that works well with the choosen hosting platform and tools I've choosen to use. Jenkins has it currently, Hudson does not.
FWIW, there is no disagreement about the momentum behind Jenkins vs. Hudson. (In reply to Doug Schaefer from comment #19) > That's the github pull request build plug-in which gives > projects who chose github over gerrit the ability to do verification jobs > when contributors submit pull requests. Wouldn't we want a Jenkins "builder in an isolated box" (ie, docker) as a prerequisite to that? It seems to easy to plop a bunch of unverified malicious code inside a PR and have some process run it as part of a verification job. (In reply to Marc-Andre Laperle from comment #18) > why not start planning the transition? You are witnessing exactly that. (In reply to David Carver from comment #21) > I just want something that works well with the choosen hosting platform and > tools I've choosen to use. There is no "I" in team :) We cannot accommodate every one of everyone's needs. That said, I concede that Jenkins likely accommodates everyone's needs better than Hudson. Keep the feedback coming. I can't promise action tomorrow morning on this front, but you know how we operate. We tend to follow the community's input.
> There is no "I" in team :) We cannot accommodate every one of everyone's > needs. That said, I concede that Jenkins likely accommodates everyone's > needs better than Hudson. Yes there is take a look at the A it is right there in the middle. :)
(In reply to Denis Roy from comment #22) > (In reply to Doug Schaefer from comment #19) > > That's the github pull request build plug-in which gives > > projects who chose github over gerrit the ability to do verification jobs > > when contributors submit pull requests. > > Wouldn't we want a Jenkins "builder in an isolated box" (ie, docker) as a > prerequisite to that? It seems to easy to plop a bunch of unverified > malicious code inside a PR and have some process run it as part of a > verification job. That's a great point. My biggest fear is a change request that has too much access to the system. That could happen with the Gerrit verifier we already have. And yes, Docker would be great for that. And the Jenkins Docker plug-in does just that. https://wiki.jenkins-ci.org/display/JENKINS/Docker+Plugin
(In reply to Doug Schaefer from comment #24) > (In reply to Denis Roy from comment #22) > > (In reply to Doug Schaefer from comment #19) > > > That's the github pull request build plug-in which gives > > > projects who chose github over gerrit the ability to do verification jobs > > > when contributors submit pull requests. > > > > Wouldn't we want a Jenkins "builder in an isolated box" (ie, docker) as a > > prerequisite to that? It seems to easy to plop a bunch of unverified > > malicious code inside a PR and have some process run it as part of a > > verification job. > > That's a great point. My biggest fear is a change request that has too much > access to the system. That could happen with the Gerrit verifier we already > have. > > And yes, Docker would be great for that. And the Jenkins Docker plug-in does > just that. > > https://wiki.jenkins-ci.org/display/JENKINS/Docker+Plugin The nice thing about the Jenkins Pull Request plugin is that you can set it up so that it only runs automatically for White Listed users. All other users would need to have the commit verified by a committer giving the plugin the OK to go ahead an run it. The nice thing about this is, that it allows for a circle of trust to occur, if somebody is submitting a lot of good pull requests and we start to trust them, getting them white listed could be a first step for them to eventually be committers. Merging of the pull request back into develop would still need to be done by a committer regardless.
Here is the actual text: When a new pull request is opened in the project and the author of the pull request isn't white-listed, builder will ask "Can one of the admins verify this patch?". "ok to test" to accept this pull request for testing "test this please" for a one time test run "add to whitelist" to add the author to the whitelist If the build fails for other various reasons you can rebuild. "retest this please" to start a new build
In the last few months we've upgraded most Hudson instances to the latest Hudson release. If there are Jenkins plugins that are not working on the latest Hudson, can we file bugs against the Hudson project and mark them as blockers to this bug? The Hudson team can't fix it if they don't know about it.
(In reply to Denis Roy from comment #27) > can we file bugs against the Hudson project and mark them as > blockers to this bug? The Hudson team can't fix it if they don't know about > it. I created bugs a month ago for the lacking plugins/feature in Hudson. I added them as blocker to this bug.
Hi, I added a blocker.
Upgrade of the JGit HIPP to Hudson 3.3.2 again broke the gerrit-trigger plugin, I filed bug 484914 to track this. We saw the same or similar breakage already two times with earlier Hudson upgrades (3.2.2 and a version from 2012).
(In reply to Denis Roy from comment #3) > Since Hudson is now an Eclipse project, we'll eat our own dog food. The dog food not tasting so good :( I'll have to dig up whether Hudson is working on Github integration. Sucks that we're not getting proper verify jobs for projects hosted on github.
I think it's time to move to Jenkins, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=484914#c4 and Winston's reply in https://bugs.eclipse.org/bugs/show_bug.cgi?id=484914#c6
(In reply to Matthias Sohn from comment #32) > I think it's time to move to Jenkins, see > https://bugs.eclipse.org/bugs/show_bug.cgi?id=484914#c4 > and Winston's reply in > https://bugs.eclipse.org/bugs/show_bug.cgi?id=484914#c6 +1 for moving to Jenkins It's far too better and all its plugins are up-to-date... the same does not hold for Hudson I'm afraid... see all the blockers (my experience with the Jacoco plugin for Hudson is really bad, starting from the report it produces, while the one for Jenkins is really good).
(In reply to Matthias Sohn from comment #32) > I think it's time to move to Jenkins, see > https://bugs.eclipse.org/bugs/show_bug.cgi?id=484914#c4 > and Winston's reply in > https://bugs.eclipse.org/bugs/show_bug.cgi?id=484914#c6 Uh, yeah. I guess we have permission now. Of course the next real question is how do we make this change in a practical way. IMHO, we fire up a Jenkins instance and let people have at it. Reset things back before HIPP and see if we still need that kind of separate in the Jenkins world. But I'm sure I'm just being naive and Denis and company could put together a real plan. It's certainly not going to be free.
I found this slide deck over the holidays which I found helpful: https://narkisr.github.io/jenkins-scaling/
> Reset things back before HIPP and see if we still need that kind of > separate in the Jenkins world. HIPP has given us a lot of good experience. If for no other reason than a perfect separation of project privileges, JIPP would be the way to go IMHO and we could do a HIPP->JIPP transition on a project-by-project basis. But one comment from Winston on the other bug -- Hudson does go through a more rigorous release process, and HIPP has been very stable. If Jenkins' release model leads to a sloppier product that webmasters are unable to support, we're no further ahead. As usual, we have to tread cautiously but with some planning and patience, we'll make it right.
(In reply to Denis Roy from comment #36) > > Reset things back before HIPP and see if we still need that kind of > > separate in the Jenkins world. > > HIPP has given us a lot of good experience. If for no other reason than a > perfect separation of project privileges, JIPP would be the way to go IMHO > and we could do a HIPP->JIPP transition on a project-by-project basis. > > But one comment from Winston on the other bug -- Hudson does go through a > more rigorous release process, and HIPP has been very stable. If Jenkins' > release model leads to a sloppier product that webmasters are unable to > support, we're no further ahead. > > As usual, we have to tread cautiously but with some planning and patience, > we'll make it right. For Jenkins stick with the Stable versions. yes they release versions pretty frequently, but they have what they consider the Stable Release which is more static.
(In reply to Denis Roy from comment #36) > > Reset things back before HIPP and see if we still need that kind of > > separate in the Jenkins world. > > HIPP has given us a lot of good experience. If for no other reason than a > perfect separation of project privileges, JIPP would be the way to go IMHO > and we could do a HIPP->JIPP transition on a project-by-project basis. +1 to move from HIPP to JIPP (like this name :)
The 'IPPs do have some advantages. I just hate running out of executors on CDT when I know PTP has some free ones. Or if CDT builds are taking a long time and I'm only using one executor, I'd like to know why. Is it the build broken or someone sharing my underlying machine chewing up resources. Anyway, we can have that discussion over beers at EclipseCon. :) I wouldn't worry too much about the stability of Jenkins. The community is huge. We have a number of instances at my employer all performing well with hundreds of jobs and dozens of slaves. We trust our business with it.
a +1 for Jenkins, for the more wider and active community. Also I'm keen on renaming hudson.eclipse.org to jenkins.eclipse.org
Despite being stable, Hudson misses some important integration with modern tools and services such as GitHub Pull Request builder, Gradle or most recent versions of SonarQube IIRC. Some good things about Jenkins: it wouldn't require much effort in adoption for users, hopefully not too much from Foundation admins, and would make Eclipse CI infrastructure more open to the innovation happening very fast in the Jenkins ecosystem that is missing with Hudson. Despite the hype is on Travis currently, Jenkins still has a huge amount of satisfied users, there are many very big Jenkins instances working correctly (such as the Apache one), and seems to have a more active and efficient community when it comes to development of extensions and support. Also, Travis uses different style of configuration and different paradigm, which would make it more difficult to adopt (it's a bit like changing your IDE or your build tool, whereas Hudson->Jenkins is like doing a version change of the same tool). For all these reasons, I believe Jenkins is the best candidate for now. Let's go on a JIPP !
During 2016Q1 I will investigate if and how we can migrate from Hudson to Jenkins. Once I'll have done internal tests, I will probably ask for one or more volunteers for some test migrations. If you want to be one, please add a comment to this bug. I will keep you posted when we are ready for these test phase.
I would volunteer to try a JIPP instance for SWTBot.
(In reply to Mickael Istria from comment #43) > I would volunteer to try a JIPP instance for SWTBot. Thanks Denis! We should try Andmore there and test out the github PR verifier there.
I would highly recommend setting up JIPP to be capable of running Jenkins Job Builder [1] so that projects can self manage and update jobs via Gerrit code review. Typically our setup just needs 2 things installed on the Jenkins host: 1. Python 2. Python Virtualenv Then a builder-merge and builder-verify job can be created that setup up JJB in a virtualenv as part of the job startup. virtualenv venv source venv/bin/activate pip install jenkins-job-builder jenkins-jobs update|test --r -o jobs_output jjb/ Projects could store their Jenkins configuration files in a jjb subproject repo or a directory under releng or something. The reason for depending on virtualenv is that it allows projects to pin specifc JJB versions or upgrade to other versions of JJB should the find support for plugins they require. This setup significantly simplifies job maintenance and also backs up your job configurations to Gerrit in case anything goes wrong. I would be willing to volunteer time to help set up JJB if projects are interested. Hope this helps. [1] http://docs.openstack.org/infra/jenkins-job-builder/
Thanks. JJB is definitely something I would like to investigate if the move to jenkins is successful. However, I think it's premature to think about it before any migration path has been setup ;)
I would volunteer to try a JIPP instance for JGit and EGit
I'm a contributor on the Paho Project (Mainly the Java component). We're currently moving our source code to GitHub and so are really interested in taking advantage of the Jenkins GitHub Plugins to allow us to do Pull request builds. If you're in need of volunteers, It would be great to get our Java builds moved over please! (With more to follow once our other Repositories have moved to GitHub too)
I would volunteer to try a JIPP instance for EMF Parsley
I would volunteer to try a JIPP instance for Trace Compass. Ideally, we would keep the HIPP instance running for a while until we have tested the JIPP instance enough. Was there any recent progress on the JIPP effort?
JIPP has been in standby for some times now even if ECF is using it successfully (https://hudson.eclipse.org/ecf/). Effort will start again in 2016Q3. Thanks for your patience.
Is there more details available on the timeline for this work? EGerrit will be happy to be a guinea pig for for the initial roll out.
With all the zombie processes Hudson is leaving around for us, we'd be happy to switch to Jenkins as well.
We will run some migration tests in the coming weeks. Once this is done, we will provide JIPPs for guinea pigs.
(In reply to Frederic Gurr from comment #54) > We will run some migration tests in the coming weeks. Once this is done, we > will provide JIPPs for guinea pigs. Is there interest in setting up Jenkins Job Builder [0] to manage the jobs? I would love to help out with setting up JJB if there is. [0] http://docs.openstack.org/infra/jenkins-job-builder/
Thanks Thanh, once we have setup the basic JIPP functionality we will definitely have a look at the Jenkins Job Builder.
Btw, I assume that we are talking about Jenkins 2.x right?
Since Jenkins 1.x has reached end-of-life (https://jenkins.io/blog/2016/07/07/jenkins-2/) we are indeed talking about Jenkins 2.x.
So, one question that will come up is the hudson.eclipse.org hostname. I don't feel like creating a new jenkins.eclipse.org hostname and running two in parallel. Can we create something like ci.eclipse.org or buidfarm.eclipse.org or captainspock.eclipse.org and run both hipp and jipp under the same roof?
(In reply to Denis Roy from comment #59) > So, one question that will come up is the hudson.eclipse.org hostname. > > I don't feel like creating a new jenkins.eclipse.org hostname and running > two in parallel. Can we create something like ci.eclipse.org or > buidfarm.eclipse.org or captainspock.eclipse.org and run both hipp and jipp > under the same roof? ci.eclipse.org sounds good. Spock wasn't a captain for long, you'd be better using ambassadorspock.eclipse.org. :D
+1 for ci.eclipse.org
Ok I've added a record for ci.eclipse.org that points to the current hudson.eclipse.org site. The changes should be live by tomorrow morning. Once the dust settles with this bug we can look at retiring hudson.eclipse.org as a name. -M.
I'm also signing up for the JIPP beta template. :)
Hello, sorry for the noise. How is this effort going? Anything we can do to help?
ping
I'm currently working on scripts that translate Hudson config files to Jenkins config files. Stay tuned... and thanks for your patience.
Just to give you a long overdue update on this topic, here is what's happening at the moment. - As of the beginning of 2017 we will not provision any new Hudson instances, unless there's a special request and requirements that can not be met with Jenkins. So if a project requests a new CI instance, they will get Jenkins by default (the latest LTS version at that time). - We are in the finishing stages for a little tool that helps to convert the Hudson config file structure to the Jenkins config file structure. So when Hudson is replaced with Jenkins, most of the configuration still works. We will test this with a few guinea pig projects in the coming weeks. - Once that converter tool is battle tested, we will convert a certain number of smaller HIPPs (or HIPPs with simple jobs) first (e.g. 5 per week) and ramp up when possible. We will do this to reduce the risk and possible impacts of any roadblocks that we might face. - In the last stage we will convert HIPPs that are part of the SimRel and essential like the Shared or Platform HIPP. We can't give an exact time line for the whole HIPP to JIPP migration, but be assured that this is one of the main objectives in Eclipse CBI for 2017. I've also sent this comment as a post to the cbi-dev mailing list.
Awesome! Thanks Frederic. CDT is certainly interested in moving as soon as you think it's the right time.
Great, JGit and EGit are interested in moving. Can't wait to use Jenkins pipelines :-)
EMF Parsley is looking forward to as well!
Status update: -------------- Number of HIPPs: 161 Number of JIPPs: 31 Successfully migrated HIPPs: * app4mc * CBI * Eclemma * Eclipsescada * EGit * JGit * OMR * package-drone * SimRel The tool that is used for the migration is now on GitHub: https://github.com/eclipse/hipp2jipp Even though most of the common configurations/plugins are now covered and converted reliably, there are some issues (see known issues on the hipp2jipp Github page). To fix those and iron out issues in the tool, all jobs of the migrated HIPPs were checked/compared manually. Obviously this can not be done for all of the 161 remaining HIPPs with the limited resources of the Eclipse Foundation's IT team. Therefore we will have to rely on the support of the community. The current plan is to do a best effort migration and give projects a chance to still see the old configurations to compare it to the converted configurations (the old configurations are backed up anyways). If a project finds that a configuration option or plugin is not covered by the hipp2jipp tool (and is feasible to do with the tool), a bug can be reported. Pull requests are appreciated even more. :) To reduce the migration effort, we will look for dormant HIPPs and delete them after giving projects a chance to speak up if they still need it. We also encourage projects to clean out old jobs and convert cascaded jobs to normal ones (cascaded jobs are not supported in Jenkins). HIPPs with less jobs and less complex configurations are likely to be migrated first. If you have any ideas how the migration can be simplified, improved, made faster, please let us know.
Nice work! > To reduce the migration effort, we will look for dormant HIPPs and delete > them after giving projects a chance to speak up if they still need it. +1 on that. > We > also encourage projects to clean out old jobs and convert cascaded jobs to > normal ones (cascaded jobs are not supported in Jenkins). HIPPs with less > jobs and less complex configurations are likely to be migrated first. +1 also
FWIW, the Gyrex HIPP is no longer necessary and can be removed.
(In reply to Gunnar Wagenknecht from comment #74) > FWIW, the Gyrex HIPP is no longer necessary and can be removed. Thanks for the feedback. The first batch of HIPPs has been retired (see bug 522275). More to come soon.
I think this issue can be closed. We know that the way forward is migrating all existing HIPPs to JIPPs. Projects should create individual tickets to ask for the actual migration. Please re-open if you disagree or if anything is still missing.
