Re: [E-devel] base_pyefl_build on Jenkins
Il giorno sab 29 set 2018 alle ore 22:15 Stefan Schmidt < ste...@datenfreihafen.org> ha scritto: > Hello. > > On 29/09/2018 08:19, Davide Andreoli wrote: > > Il giorno mer 26 set 2018 alle ore 10:17 Stefan Schmidt > > mailto:ste...@datenfreihafen.org>> ha > scritto: > > > > Hello Dave. > > > > I have recently disabled all builds on Jenkins. The only job I left > > enabled is your base_pyefl_build job. > > > > > > Disabling the jobs was only the first step towards shutting down > Jenkins > > on our server completely. > > > > That leaves the question open what do do with the pyefl job. Is this > > something you are still actively using? Something that produces > tarballs > > or artifacts you need? > > > > > > Yes, the pyefl build is actively used for 3 main tasks: > > 1. Tests after each commit that everything build and unit-tests pass on > > various python version > > 2. Artifacts: the build create tarball and documentation that are public > > (and linked in various places) > > for in-development snapshot release. > > 3. I use the final artifacts to roll-up each stable release > > So its used and needed. Fair enough. We will have a place for it. > > > > > > > If it is something actively used and needed we need to find a new > home > > for it. If it is just a left over we can simply drop it. > > > > > > well, I'm quite surprised that we are shutting down our CI infra without > > an alternative > > ready to migrate to. Do the efl project can live without CI? I don't > > think any decent project can. > > Where did you jump to the conclusion that we will not have any CI? I did > not wrote that at all. > > Together with Mike and Marcel I have been working on using TravisCI as > our new system for many, many months. The config and scripts are even in > the main efl repo under .ci/. Not sure how you could have been able to > miss these with all the commits going into that. But be assured we want > to keep CI going and even improve it (we have mac os builds going on on > Travis and I am working on mingw cross builds for windows as well right > now). > Ugh, sorry then. I'm not actively reading the commit list lately > > > Of course it doesn't make sense to keep up jenkins only for pyefl, so if > > you are going to trash it > > just do it, I will remove any link around, change the release procedure > > and everything else needed. > > > > But we really need a new CI infra, I don't know how can I decently > > manage the python-efl project without a working CI. > > We will get something working for you. For now your Jenkins python efl > job stays as it is. > ok, good to hear, let me know if you need some help from my side :) > > regards > Stefan Schmidt > ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] expedite: remove it from Buildroot ?
Hi, Le 30/09/2018 à 12:00, Carsten Haitzler (The Rasterman) a écrit : > On Sat, 29 Sep 2018 15:20:40 +0200 Romain Naour said: > >> Hi, >> >> >From the latest commit [1] "this is a dead project". >> This does not encourage to keep expedite in Buildroot, should I remove it? >> [2] >> >> Best regards, >> Romain >> >> [1] >> https://git.enlightenment.org/tools/expedite.git/commit/?id=27e5e02370799b4e9246fe6dde893207d1ac3f3b >> >> [2] https://git.buildroot.net/buildroot/tree/package/expedite > > yes. this is the kind of tool we should maintain in the efl tree if we > maintain > it. > Ok, thanks. Best regards, Romain ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
On Thu, 27 Sep 2018 00:17:53 +0100 Bertrand Jacquin said: > > OH amount of CPU is indeed not "infinite". We have plenty of disk and RAM > > to go around. The way I see it is "keep build jobs in the background and > > they take however long they take". Developers should be able to run builds > > on their own boxes far faster than the shared infra and all this kind of > > QA/CI should be easily reproducible in a more minimal form on developer > > workstations. This scales out the load. I have a feeling we're just trying > > to do too much in a central service that SHOULD be being done by developers > > already as they build/develop etc. > > Agreed > > > > > compared to a raspberry pi .. e5 runs rings around it so many times > > > > it's not funny and an rpi can do this easily enough. yes - jenkins adds > > > > infra cost itself, but a single vm for linux builds (with multiple > > > > chroots) would consume very little resources > > > > > > That is true, the VM overhead is not negligible. VM were the initial > > > design and we stuck on this. I am far from being against that as I'm far > > > from being against containers, finding the right time to work on this is > > > a different matter. > > > > Indeed VM's are not free. they cost a whole new OS instance in RAM etc. - > > thus why I mention chroots for example. Containers add some more isolation > > but a single "builder VM" with just chroots should do the trick for any > > Linux builds. > > > > I'm trying to just point out that when you try and do "too much" you create > > work and trouble for yourselves. If you try and behave like you have > > infinite access to infrastructure then you will get into trouble. Behave > > like your infra has limits and you use it sensibly and everything can work > > just fine. > > > > I'm OK having infra that is not on e5/our hw that we can "live without". For > > example - if someone wants to have build slaves scale out across > > hosted/sponsored machines to get more builds done per day... that's fine. If > > they go away we turn them off and just do fewer builds per day (like above). > > THAT I'm OK with. IT allows a fairly painless degrade in service when that > > happens. :) > > > > > > as it would only need a single build controller and just > > > > spawn off scripts per build that do the chroot fun. > > > > > > > > sure - need a vm for bsd, and windows and other OS's that can't do the > > > > chroot trick. > > > > > > > > > the hosting instances. Even still, current ressources are too limited. > > > > > You will not be able to have more than 10 instances running at the > > > > > same time. > > > > > > > > 10 build instances? if they are properly ionice'd and niced to be > > > > background tasks vs www etc... i think we can,. they might take longer > > > > as the xeons are old on the server, but they can do the task still. i > > > > regularly build efl/e on hardware a tiny fraction of the power of e5. > > > > > > We don't just instances for build, we have instances for web, mail, git, > > > phab etc .. Which by the way were moved to e6 last year after the > > > website was pretty much unsable and the disk issue we had, server that I'm > > > still paying myself. This was meant to be a temporary solution, but I > > > did not find the appropriate time to allocate on putting stuff back. > > > > Yeah. I know things moved to e6. I'd like to move stuff back too. I don't > > want you paying for this... We have infra. I just ordered a replacement > > disk BTW for e5... :) > > Appreciated > > > Maybe it'd make sense to set up that single "VM" on e5 and then move stuff > > into it. so it's just e5 -> VM and this VM just tuns shared hosting and/or > > chroots and containers? > > That would be the right thing to do from what we have available today. Let's > fix the fan and disk issue before touching anything to avoid mixing > different problems at the same time. absolutely. we're on the same page. :) -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] expedite: remove it from Buildroot ?
On Sat, 29 Sep 2018 15:20:40 +0200 Romain Naour said: > Hi, > > >From the latest commit [1] "this is a dead project". > This does not encourage to keep expedite in Buildroot, should I remove it? [2] > > Best regards, > Romain > > [1] > https://git.enlightenment.org/tools/expedite.git/commit/?id=27e5e02370799b4e9246fe6dde893207d1ac3f3b > > [2] https://git.buildroot.net/buildroot/tree/package/expedite yes. this is the kind of tool we should maintain in the efl tree if we maintain it. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
