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 <[email protected]> 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 <[email protected]> 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 > >>> [email protected] > >>> http://brettporter.wordpress.com/ > >>> > >>> > >>> > >>> > >> > >> -- > >> Brett Porter > >> [email protected] > >> http://brettporter.wordpress.com/ > >> > >> > >> > >> > >> > > > > > > -- > > P.A.Eshan Sudharaka > > Dept of Computer Science and Engineering > > University of Moratuwa > > Sri Lanka > > -- > Brett Porter > [email protected] > http://brettporter.wordpress.com/ > > > > > -- P.A.Eshan Sudharaka Dept of Computer Science and Engineering University of Moratuwa Sri Lanka
