On Tue, Jun 3, 2014 at 7:51 AM, Anatol Belski <[email protected]> wrote: > On Tue, June 3, 2014 03:24, Hannes Magnusson wrote: >> On Sat, May 31, 2014 at 2:40 AM, Anatol Belski <[email protected]> wrote: >> >>> Hi, >>> >>> >>> On Fri, May 30, 2014 18:25, Hannes Magnusson wrote: >>> >>>> Hi >>>> >>>> >>>> >>>> >>>> What is the status on the Windows build infrastructure? >>>> Anything I can work on to get "snapshot" functionality implemented? >>>> >>>> >>>> >>>> >>>> I believe the infrastructure itself is all in place, it just needs >>>> taping some pieces together and decide on security policy (e.g., >>>> upload a archive.tar.gz? build from a git/svn branch? how to verify >>>> its real?). Maybe we could even trigger these builds from pull >>>> requests on github in the long term? :) >>>> >>>> >> [..] >> >>>> >>> It's still on todos, too many other tasks around. There are several >>> approaches, imho which make sense. >>> >> [..] >> >>> >>> 2.1 Snapshot triggered on PECL without upload directly from a VCS >>> >>> >>> - it could look like a button in the user account like "build a snap >>> now" on PECL. Plus it needs to store the VCS location, branch, etc. - >>> when clicked, an item would be added to an RSS feed similar to what >>> exists now with releases - a cronjob on the buildhost would read that >>> RSS and handle >>> >> [..] >> >> >> >> There are plenty pecl extensions hosted on git.php.net now - and >> mirrored on github - so I think the proof-of-concept could be to build a >> branch from git sources - the sources are already available as "browse >> source" links, so it would only need to provide the branch (free text for >> that matters in the first round). Then we can expand on it. >> > That were probably a good way to start, one can download revision > snapshots from the git web via http. Also from github. Not sure it's > possible with the SVN repo. That's probably the detail we have to clear - > either to rely on such "download revision" web thing, or say we do > literally a "svn checkout" or "git clone" every time. Former is easier of > course, good if it were available everywhere. > >> I don't think we want to list it as a release or add an entry to the >> RSS announce feed. This should only be meant for developers of the >> package to "see if it still builds on Windows before release", or debugging >> windows specific build issues (which can be expanded into making it >> automatically run 'make tests' upon successful build). >> > Yes, I didn't mean snapshots to be handled like releases with > announcements and co. Just to use the RSS to export the entries to build. > Say if user would click "build a snap", a new RSS entry were added to the > feed. Or for example, as Johannes suggested - on a commit there could be a > commit hook triggering an RSS entry export (IMHO were great for continuous > integration). Then the build host can pick it up and handle. This is the > way how it works currently with the releases, so the functionality in > rmtools can be adapted which would spare time. That's effectively a > cronjob to run.
Oh. I didn't realize the build hosts were tailing the release rss. I thought they got a poke when uploading the archive. That explains why the build seem to start on random intervals after release :) > > Also that's fine with security - PeCL exports just the necessary info in > the feed (even as a plain xml file), like ext:repo:revision:branch ... > then the build host reads it and does the build. After the build snap is > uploaded and leads are mailed. > > Clear, that RSS would be visible to the outta world, but that's actualy no > issue. The RSS feed should be just rotated to pop the older entries. As > well, the snapshot builds would be put to > http://windows.php.net/downloads/pecl/snaps/ and visible to the outta > world. What we would need later probably to configure through an UI to > config that finer, say for example there are exts incompatible with > windows, or users who don't care or whatever, so they should explicitly > activate snaps in their pecl accounts. > >>> I don't know the pECL infrastructure well actually, maybe one who knows >>> it cann suggest something better. So please comment and post ideas. >>> >>> Right now this topic is stalled, at least on my side. I probably don't >>> get to it somewhen before July, at least. But it's good to discuss it to >>> have a clear roadmap when the time comes. >> >> >> What is blocking me from contributing is knowing where I can find the >> code that does the current builds on release packages.. If its ok to use >> those same servers then it shouldn't be an issue for me to stick another >> frontend on that for these snap builds on pecl.php.net in the form of a >> button "build snapshot now". >> > The code is available in the http://git.php.net/?p=web/rmtools.git repo. > Though it'll need some effort to setup and to get some tools and co. No > big docs on that as usual as nobody was interested to work on that till > now :) Ok. Is the build host running master? Does it automatically update? Are there logs on the build hosts I can tail to see if I broke something? I noticed you pushed bunch of changes to the repo just which seem to actually have been live for a while.. Does the build host update from some other repo I would need to merge up to? -Hannes -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
