2011/11/8 Johannes Schlüter <johan...@schlueters.de> > On Tue, 2011-11-08 at 01:18 +0100, Ferenc Kovacs wrote: > > > Might also be nice to build (PECL) extensions as sub-tasks, so if > > they > > > fail they don't cause the whole build to fail, but just a single red > > > light between many green (or blue) ones. > > > > > > > > Yeah, thats a good idea, even for some of the core exts, as there are > > some > > exts which can't be built/loaded at the same time. > > If you do that for core extensions, is it possible to strucutre it in a > way that the overall PHP compile process turns red if a core extension > fails, but not if a PECL extension fails, in the later case the overall > build might fails. In an ASCII tree something like this: > > > +-build > +-PHP core > |+-ext/dom > |+-ext/simplexml > +-PECL > +-pecl/htpp > +-pecl/foobar > > So if pecl/http fails PECL turns read, as does "build" ... not sure > whether that's possible as "PECL" will depend on "PHP core". I'm not > sure where userland tests belong in that hierarchy, I think next to > "PECL". > > > johannes > > Sorry, I'm not sure that you are asking this, or stating it (maybe just the lack of question marks). If you are asking, then yes, it is possible. I would create an upstream project (for each branch), which would build the php binary with a set of standards extensions. I would then build every other core ext as a shared extension. With this, the php-src-$version-matrix-build job is finished. This would trigger the php-src job for that branch, which would use the artifacts (the binaries, shared objects compiled in the build job) then first execute the testsuite against the standard core extensions, then execute the test suite for each shared extension lastly aggragate the test results. With this, the php-src-$version-matrix-tests job is finished.
I would set up a matrix job for each pecl ext, and trigger it every time when that particular pecl extension is changed and at least once a day. We can check this, but imo triggering a build for every pecl extension every time when the php-src is changed would be a huge overkill, but I'm open for suggestions. So each pecl matrix job would fetch the changes and trigger a build for each php version. That build would fetch the binaries/artifacts from the php-src-$version-build job, and use those to phpize the pecl extension, and execute the tests for that particular pecl ext. So the structure would be something like this: - php-src-trunk-matrix-build (building each core ext, on each platform, non-default exts would be shared) -- platform1 -- platform2 -- ... - php-src-trunk-matrix-tests (running the testsuite against each platform, multiple execution, as the default exts and the non-default exts would have tested separately, but the results would be aggragated) -- platform1 -- platform2 -- ... - php-src-pecl-foo-matrix-build (this would build the pecl ext for each version and platform) - php-src-pecl-foo-matrix-tests (running the testsuite) (maybe the build and the task could be merged into one, I have to check what is the average build/test execution time for the pecl exts) - ... As you can seen, for the php-src, I would create a(two) separate job for each php version(branch) but for pecl exts, I would handle all versions in one matrix job. This can be changed, but this setup gives a better overall view that where is the ext is building successfully, but using the same logic would make the php-src jobs too big, it would take too long to get the result, so for those I think it is better to have a separate job for each branch, while for an ext, it is much more useful to see that it is working fine on each php version or not. Sorry if not making much sense, almost sleeping in front of my keyboard, so I call it a day, good night! ps: the jobs can be splitted into spearate views, as you can see the php-src and php-userland. We also planned a new view for the PEAR jobs especially (and maybe a different view for the PEAR2 jobs), so I think that the same should go for pecl, having it's own view would make much sense. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
