commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <mart...@apache.org>
Subject Re: [all][poll] How should nigthlies / CI work?
Date Sat, 25 Aug 2007 17:05:28 GMT
On 8/25/07, Phil Steitz <phil.steitz@gmail.com> wrote:
>
> On 8/25/07, Noel J. Bergman <noel@devtech.com> wrote:
> > Martin Cooper wrote:
> >
> > > > GUMP builds are deemed non-trusted, since GUMP downloads from
> > > > non-ASF sites and includes them in builds without any vetting
> > > > of the third party dependencies.
> >
> > > True, but it's not clear that everything in the public Maven repo
> > > should be considered as "vetted" either.
> >
> > Exactly.  Maven continues to be remiss in delivering on their goal of
> > ensuring authenticated packages.  I view anyone who uses the public
> Maven
> > repository as being foolish; competent Maven users have their own
> private
> > repositories.
> >
> > And, yes, the corollary that GUMP is building from the latest of
> everything
> > is another key reason not to use it for nightly builds.
> >
>
> Another reason is that it is a little easier for us to manage
> "publication" of the CI artifacts using Continuum / vmbuild.  We can
> publish both jars and zips/tarballs to a local maven repo on vmbuild
> and set up rsynch to people.apache.org, eliminating some of the
> ugliness in the bash setup.
>
> So can I get some feedback on the "what to publish" question?


I'd say #1. The nightly builds are purely a convenience. If someone really
needs something prior to the most recent nightly, they should be able to
build it themselves, and it's not clear that us picking an arbitrary number
would provide what they need in any case.

--
Martin Cooper


1. Most recent successful build only
> 2. A stack of the n (probably = 5) most recent successful builds
>
> I guess if we really want to hold on to the "nightly" idea, we could do
>
> 3. Symlink nightly the subset of 2 that correspond to the last n nights.
>
> 3. gets us back into bash/cron more deeply.  1. is bash/cron free
> (other than rsynch) and 2. requires cron cleanup.  All are simpler
> than the current bash script, though.  I am happy help implement any
> of these.
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message