archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: Staging repositories (was: Re: GSoC projects?)
Date Tue, 13 Apr 2010 02:26:12 GMT

On 12/04/2010, at 6:30 PM, Deng Ching wrote:

> On Mon, Apr 12, 2010 at 3:03 PM, Eshan Sudharaka <esudharaka@gmail.com>wrote:
> 
>> Hi brett,
>> as i understood if we create a new repo then a staging repo is
>> automatically created.And deployment is according to following order.
>> stage _ test_repo > test_repo > internal repo or snapshot repo
>> 
>> 
> I think this should be just stage_test_repo > managed repo (internal,
> releases, etc.)?

Yep. To better articulate what I was trying to say, maybe a diagram would help:
http://people.apache.org/~brett/staging-promotion.png

> 
> Also, as an additional comment to this line in the proposal..
> 
> *  "Here i am going to use archiva audit logs to determine what is the
> suitable option to follw and provide above functionalies to the user.*"
> 
> I think it would be best to have a UI to present or give the user an option
> which artifacts he/she may merge. I don't think you would need to
> necessarily base it on the audit logs since their purpose are mainly for
> tracking changes.

Yep. What I was thinking when promoting was that you'd start at a particular artifact and
if it is in a staging repository a promote button appears if you have permission. That would
bring up a page with some options:
- promote all children in the staging repository (that is, by traversing <modules> -
listed, and on by default)
- promote all dependencies / parents in the staging repository (listed, and off by default)

Alternatively there could be a repository option to promote the whole repo, probably accessible
from the sidebar and offering a dropdown of staging repositories with content and which you
have promote access.

Another use case is to delete a failed deployment - the existing delete option can be used
for that, and we might talk about improving it (possibly by reusing the above UI).

What do others think about this? Are there other use cases?

As an implementation detail, as much as possible should be contained to the repository-api
and a new plugin, with just the UI in the webapp.

I'll add some further comments on the proposal later.

- Brett

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/





Mime
View raw message