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 00:55:33 GMT

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.

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

   *  question : can you explain me where these kind of overriding things
are happening...is this due to merge same repo repeating ?

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


 


  








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
View raw message