>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 <[email protected]> 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 <[email protected]> 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
>
