Re: Minor enhancement: CI server now builds trunk packages
| From: | Brett Bieber | Date: | Mon, 23 Aug 2010 13:33:54 +0000 |
| Subject: | Re: Minor enhancement: CI server now builds trunk packages | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-53714@lists.php.net to get a copy of this message | ||
On Sun, Aug 22, 2010 at 8:35 PM, Daniel O'Connor
<daniel.oconnor@gmail.com> wrote:
> I just tinkered around with the CI server, and now it'll build (via pyrus) a
> package off of trunk; and publish it.
>
> For instance:
>
> http://test.pear.php.net:8080/cruisecontrol/artifacts/Auth/20100822212117/package/
>
> I plan to add links from
> http://pear.php.net/qa/packages_closed_reports_no_release.php
> to the
> relevant build artifacts; or... perhaps even on the package homepages for
> successful builds.
>
This is great btw. Just one thought — do you know what the version
number/stability labels are for these builds?
I'm a little concerned that something built from trunk might get out
as a stable version and pear upgrade could easily get confused.
Perhaps a stability level of -dev? with some date as the version
suffix? I'm not sure the best way to name a snapshot built from trunk,
but it might be worth thinking about.
>
>
> As a side note, I don't suppose that anyone with a bit of time would like to
> look at a qa-package-script?
>
> IE:
> 1. Grab list of bugs closed since last release / svn changelog since last
> release (message + author)
> 2. Open up the package.xml and create a new release, adding the changelog
> info.
> 3. Build with pyrus / pear
> 4. Optionally svn commit && svntag as appropriate
>
> There's only so many hours in a day; and if a lot of the QA tasks we do
> within PEAR can be fully or semi automated; I think we could actually make a
> dent in the growing lists of tasks without burning out our volunteers.
>
Very good work. This shouldn't be too difficult with Pyrus. One
alternative approach might be tag, then and then build & release from
the tag. That might be useful to a wider PEAR audience than just the
QA team.