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 Sat, 03 Apr 2010 02:25:58 GMT
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
> >
>

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