archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deng Ching <och...@apache.org>
Subject Re: Staging repositories (was: Re: GSoC projects?)
Date Mon, 05 Apr 2010 06:48:17 GMT
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?


>
>      * 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?


>
>   *  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.


>
>  * 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.
>
>

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