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, 05 Apr 2010 08:01:50 GMT
On Mon, Apr 5, 2010 at 12:18 PM, Deng Ching <oching@apache.org> wrote:

> On Mon, Apr 5, 2010 at 8:55 AM, eshan sudharaka <esudharaka@gmail.com
> >wrote:
>
> >
> > As all of u guys mentioned a separate repository is a must for staging
> > artifacts.
> > Then all the registered archiva usrs have the access to that.
> >
> > In most of the companies projects are done by modular basis and those
> > modules are assign to developers.So i thought that tech lead should
> access
> > archiva stage repository and then assign a project location for his
> > group.(This location should be only access by only team members)
> >
> > once the development has done it is the tech lead's task to notify the
> sys
> > admin and ask the permision for merge the content in to common
> repository.
> >
>
> As Wendy pointed out in her previous email, Archiva currently only have 2
> roles: a repository manager (read & write access to repo) and a repository
> observer (read access only). Will you be introducing a new set of roles
> and/or permissions for this?
>        > I guess that we can handle this through the permission levels.Hope
> that we can change the access (for a repo) time to time...
>
> >
> >      * Here we need to search through the common repo for the projects
> > which has the same name  and give options to user to override them or
> keep
> > the older version on the repo.
> >
>
> Sounds good :) How will these options be presented to the user?
>
>


>        >   currently archiva has the search option for a particular repo.So
> we can use this facility and just notyfy the user where a duplicate is
> found.
>
> >
> >   *  question : can you explain me where these kind of overriding things
> > are happening...is this due to merge same repo repeating ?
> >
>
> The blocking of re-deployments for released artifacts happens in the
> archiva-webdav module, particularly the ArchivaDavResourceFactory class.
> But
> given that this is different from a regular artifact deployment, I think it
> should be put in a separate component.
>

     > we can have a seperate component.I have a problem.Letz say we need a
redeplyement what we have to do....do we need to delete the original copy
and then deploye the latest one..??? and also still cannot understand what
is the important of meta data update...

(are we going to merage only the changes in to the common repo?? i mean for
a redployement..)
and when we deploye a fresh artifacts  what is the point of updating meta
data...um confusing here..

>
>
> >
> >  * It is the tech lead task to release the project for the QA ppl.(Since
> he
> > is the current admin for the project on the staging repo.Developers
> access
> > should be restricted before the QA release)
> >
> > Eshan.
> > thank you.
> >
>
> Thanks,
> Deng
>
>
> >
> > Deng Ching-2 wrote:
> > >
> > > I agree with Dan. I think it should be kept as simple as possible.. :)
> > >
> > > In addition to what Dan listed below, I think the following should be
> > > addressed in the design:
> > > - creation of the staging repository (should it be distinguished and
> how
> > > will it be distinguished it from a regular repository?)
> > > - merging of the staged artifacts to the final repository
> > > - deletion of the staging repository (should Archiva do this after the
> > > merging? or should the user manually delete it?)
> > > - security (who will be able to promote artifacts? will the granting of
> > > access to the staging repo be just the same as what is currently
> > > implemented? or will batch assignment of permissions to a group/set of
> > > users
> > > be supported?)
> > >
> > > Thanks,
> > > Deng
> > >
> > > On Sat, Apr 3, 2010 at 5:25 AM, Dan Tran <dantran@gmail.com> 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
> > >>
> > >> 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
> > >>
> > >>  I think Archiva should keep the requiment as simple as these.
> > >>
> > >> Thanks
> > >>
> > >> -Dan
> > >>
> > >> On Fri, Apr 2, 2010 at 1:47 PM, Wendy Smoak <wsmoak@gmail.com> wrote:
> > >> > (I changed the subject line so it doesn't get lost in the generic
> > >> discussion)
> > >> >
> > >> > On Fri, Apr 2, 2010 at 4:15 PM, eshan sudharaka <
> esudharaka@gmail.com
> > >
> > >> wrote:
> > >> >
> > >> >> * Assign a Temporory reposotory for a group.(eg :
> > >> com.MyTempRep.example)
> > >> >
> > >> > How do you think this should happen?  Currently an admin has to
> create
> > >> > a repo and assign permissions before it can be used.
> > >> >
> > >> >> * Only they are allowed to publish artifacts and the tempo rory
> repo
> > >> is
> > >> only
> > >> >> open to them untill deploye the all artifacts to        be
> > tested.(not
> > >> visible to
> > >> >> the common repo with have tesed modules)
> > >> >
> > >> > How would you determine that all the artifacts have been deployed?
> > >> >
> > >> >> *  once the temporory reposotory is closed it should me prevented
> > from
> > >> the
> > >> >> developers being updating and it should be opened to QA people
to
> > >> >> testing(Same temporory repo will be used.only acces grants should
> be
> > >> chaged
> > >> >> and assing the acces for the QA         group)
> > >> >
> > >> > Archiva doesn't currently know anything about 'developers' vs. 'QA'.
> > >> > It just has users with roles like repository manager or observer.
> > >> >
> > >> > Is this something you want to introduce?
> > >> >
> > >> >> * once testing is done > if it success then merge the temp
repo to
> > the
> > >> >> common repo(where the tested modules are located)
> > >> >> if it fails then manually removed from the repo.
> > >> >
> > >> > IMO, this is the most important part (the promotion/merge step) and
> it
> > >> > could be addressed separately from the roles/repo access part.
> > >> >
> > >> > In fact I'd like to be able to merge any two repositories,
> separately
> > >> > from any staging/promotion workflow. See
> > >> > http://jira.codehaus.org/browse/MRM-980
> > >> >
> > >> >> I dont understand how the audit log is linking with this project
> > >> idea.could
> > >> >> u please explain it?
> > >> >
> > >> > The audit log needs to record all changes to the repositories.
> > >> > who/what/where, etc.  That would apply to these staging repos as
> well.
> > >> >
> > >> > Unless it's already been changed, I remember the audit logging being
> a
> > >> > rather complex event driven thing.  Don't get too bogged down in it
> if
> > >> > it looks scary, it probably needs to be reworked as a separate
> > >> > project.
> > >> >
> > >> >> and also are we need to wary about the changes that are done in
the
> > >> >> artifacts in temporary repo (by developers).I mean whether we
> should
> > >> provide
> > >> >> a facility like svn diff ?
> > >> >
> > >> > Once an artifact is deployed, it should not change.  (I believe
> > >> > Archiva already prevents re-deploying a released [non-SNAPSHOT]
> > >> > artifact.)  So no, I don't think a diff utility is needed.
> > >> >
> > >> > --
> > >> > Wendy
> > >> >
> > >>
> > >
> > >
> >
> > --
> > View this message in context:
> >
> http://old.nabble.com/Staging-repositories-%28was%3A-Re%3A-GSoC-projects-%29-tp28122839p28133873.html
> > Sent from the archiva-dev mailing list archive at Nabble.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