Page History

...

Adding a Staging Repository

currently archiva comes with has two default permanent repositories .Those are called internal repository and the snapshots repositorysnapshot. My Here my idea is to add another default repository called propose intermediate staging repository where the developers can deploy their ongoing(to deploy artifacts which have been not being tested yet) . It is the admins task to grant access to the repository to users.Also no one(archiva artifacts users) is allowed to use this repository as in the pom files as mentioned in following.

...

<pluginRepository>
<id>internal</id>
<url>[http://192.168.0.7:8080/archiva/repository/staging/]</url>
</pluginRepository>

archiva user's task to create this permanent staging repository and attached it for a selected repository. Following example will illustrate that scenario.

Lets say user has a repository called “data_repo” and he needs to get the support of staging repository. Then he has to create staging repository instance called “data_repo_stage” and he can attached this stage repository to his main repository called “data_repo”.(hope to offer this function through the web interface).Here user can add more than one stage repositories so that simultaneous releasing function will support. Promotion is done through the following path.

data_repo_stage >>> data_repo

I think in the stage repository we should limit the access. Nobody should allow to download the artifacts in the staging repositories other than the developers,QA people, archiva admin user ,and the the guy who have the permission for the promotion.

I think it is the repository manager's task to create the stage repositories and attach it to the main repository that he want to add the staging functionalitySo the visibility of the repository should be only with in the archiva registererd users.

Creating Roles for this staging repository

...

Here registered users can read and write artifacts to the repository. Here registered users mean developers and the QA people.Developers Here developers should have both read and write access where while the QA people guys have only the read access. Also QA guys should be able to mark the artifact as success one or a failure on. Then it will be useful for the merging part to take a correct decision.

Promotion the Artifacts(merging to the common place)

This is the most important part in this project. Once the testing tasks are done this role is responsible for merge artifacts from staging repository to the internal repository or the snapshot repository. It depends on the artifact(snapshot or a version).Here i am going to consider following things regarding the merging the artifacts
If the artifacts that are going to deploy is not an existing one(new one) just deploy it with creating new meta data file. (user should me able to merge the artifact bu clicking the merge button and then should receive to success/failure message from the archiva side)
If the artifact is

...

an existing one(latest version) we need to provide following options.
when the user clicks merge button it should notify the user about the older versions in the release repository.(eg : version numbers + updated date)
then we need to suggest him following options.

• 1. merging the artifact while keeping the older version
  2. merging the artifact while removing the older version. Here we should only allow to remove latest artifact.
     Eg : in the main repo we have versions 1.1, 1.2, 1.3.And we are going to merge version 1.4.If there are significant changes in version 1.3 and version 1.4 it is better to keep 1.3 version and add 1.4.
     But if there are no significant changes in both artifacts then it is better to remove the version 1.3 and add 1.4.
     Mean while meta data updating also should be done.

In above I have mentioned only the success scenario of a artifact. There can be a fail scenario as well. If an artifact is failed then the user should manually delete the artifact

• There is another possibility in merging an artifact.Lets say in internal repository we have version 1.1.x and we need to merge version 1.1.y(new one) to the internal repository from the staging repository.Here i propose to have following functions.
  1. Remove older one and deploy the latest version.(with updating meta data files)
  2. Deploy the latest version while keeping the older version.(with updating the meta data files)

Here i am going to use archiva audit logs to determine what is the suitable option to follow and provide above functionalities to the user.Also additional logs should be implemented for the staging repository.

Implementation

1. adding a default staging repository and assign the all permissoin configurations of that repository to the admin user
2. restricted this staging repository from being using as a plugging repository from out user as mentioned in above in the pom.xml files
3. implementing the read action and the write actions and assign them to the developer(role)and the QA person(role) as mentioned in above.
4. Testing the roles(developer) with the staging repository.
5. implementing the promotion role.(only the merging based on the assumption that new artifact is being deployed.Not a update version)
6. implement the logs and make use them for the searching algorithm to check the older versions of the artifacts which have already deployed.
7. add searching feature(action) to the promotion role and do the merging part by providing the options regarding the version as mentioned above.
8. implementing logs for staging repository