archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eshan Sudharaka <esudhar...@gmail.com>
Subject Re: Staging repositories (was: Re: GSoC projects?)
Date Mon, 12 Apr 2010 07:03:52 GMT
Hi brett,
  as i understood if we create a new repo then a staging repo is
automatically created.And deployment is according to following order.
 stage _ test_repo > test_repo > internal repo or snapshot repo

On Mon, Apr 12, 2010 at 11:53 AM, Brett Porter <brett@apache.org> wrote:

>
> On 12/04/2010, at 3:25 PM, Eshan Sudharaka wrote:
>
> > hi Brett,
> > i have already posted my proposal to the gsoc site.Could you please check
> it
> > and if there are any unclear parts or conflicts things please let me
> > inform.I saw deng has already put comment on it.
>
> Yes, I've seen it - but not everyone on this list can :) I thought it might
> be best to summarise here instead (or on the wiki when it is back up).
>
> My main comments would be the same as below - I'd like there to be at least
> one staging repo per managed repo and minimal admin work.
>
> For permissions, I'm not sure we need new ones, just separate ones for
> staging & managed resources (when the wiki is back up, I can point to the
> document that says what roles, permissions and resources are). As an
> example, say you have repo "releases" and attached repo "releases-staged".
> There's no need to block read access to stage - you can give out the normal
> repo read permission (and limit it to QAs or keep it as the same as the main
> repo). Whoever has write perms to releases-staged can stage a release,
> whoever has write permissions to releases can promote a release. I would say
> write permissions to "releases" implies r/w permissions to
> "releases-staged", but nothing else is implied.
>
> - Brett
>
> >
> > On Mon, Apr 12, 2010 at 10:15 AM, Brett Porter <brett@apache.org> wrote:
> >
> >> Any further thoughts on this? Eshan, could you perhaps summarise your
> >> proposal so far with the comments incorporated? Unfortunately, our wiki
> is
> >> still down which is the normal place to document the current state
> between
> >> discussions, but we can continue using the mailing list in the mean
> time.
> >>
> >> On 06/04/2010, at 1:36 PM, Brett Porter wrote:
> >>
> >>>
> >>> On 03/04/2010, at 8:25 AM, Dan Tran wrote:
> >>>
> >>>> From a build admin perspective, this what I would like to have:
> >>>>
> >>>>
> >>>> 1. Create a permanent staging repository on archiva where I can
> >>>> release/deploy all my projects one at the time.
> >>>>
> >>>>  I can have multiple staging repos so that I can release multiple
> >>>> project at the same time
> >>>
> >>> I agree to them being permanent - I'd prefer to be pointing Maven at
> >> deploying to a staging repository, rather an automatically creating a
> >> temporary one, and the staging repository should be available to Maven
> users
> >> without having to change it all the time. I think they must be attached
> to a
> >> particular managed repository, though, and this needs to be easy to do -
> I
> >> wouldn't want a lot of manual work each time and I definitely wouldn't
> want
> >> to be reconfiguring Maven for different deployments.
> >>>
> >>> This makes some sense for us since the permissions are currently
> aligned
> >> to the repositories, so we can grant a merging permission.
> >>>
> >>> The tools here should be reusable for similar use cases - for example
> if
> >> a proxy connector had a staging repository, we would be able to have an
> >> approval process for third party artifacts that are requested.
> >>>
> >>>>
> >>>> 2. Once the artifacts at a staging repos, I'd like it to merge the
> >>>> staging repo into the official release repo. Finally wipe out the
> >>>> staging repo's content
> >>>
> >>> It might be worth having the option of selecting which artifacts to
> merge
> >> (with default being all), then deleting those artifacts from the staging
> >> repository.
> >>>
> >>> In the future, this could be made more intelligent by grouping
> artifacts
> >> automatically for merging (by using the modules, parents and
> dependencies
> >> elements to detect related artifacts that need to be moved together).
> >>>
> >>> Cheers,
> >>> Brett
> >>>
> >>> --
> >>> Brett Porter
> >>> brett@apache.org
> >>> http://brettporter.wordpress.com/
> >>>
> >>>
> >>>
> >>>
> >>
> >> --
> >> Brett Porter
> >> brett@apache.org
> >> http://brettporter.wordpress.com/
> >>
> >>
> >>
> >>
> >>
> >
> >
> > --
> > P.A.Eshan Sudharaka
> > Dept of Computer Science and Engineering
> > University of Moratuwa
> > Sri Lanka
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>
>
>
>
>


-- 
P.A.Eshan Sudharaka
Dept of Computer Science and Engineering
University of Moratuwa
Sri Lanka

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