Versions Compared

Old Version 2

changes.mady.by.user Brett Porter

Saved on

compared with

New Version Current

changes.mady.by.user Maria Ching

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

Creating a repository where the users can deploy their artifacts and once the testing tasks are completed, a user can deploy the artifact to the common place where the we can use those artifacts as dependencies in pom POM files or remove the artifact from the temporary repository if it fails during the testing phase.

Proposal

Apache archiva Archiva is a repository management system where we can deploy our artifacts to a common location and later on we can make use of those artifacts (jar files, war files, zip files, ear files, etc.) in our projects by adding the artifacts as dependencies in the POM file. But here there is no any separate place to deploy the artifacts which are are not tested yet and also the artifacts of an ongoing project(modules).So we need to deploy them in to the common location where the official artifacts are deployed. So there can be some issues due to the use of those artifacts as dependencies in our projects since they are not properly tested.

So here my idea is to create a separate place (repositories) where the registered user can deploy the staging artifacts. Those artifacts are not visible to common users. Once the testing task is completed (ready for the public deployment), we can either merge in them to the common place where others can make use of those artifacts or remove them from the staging artifactarea (if it fails).

Description

First i I would like to give a brief introduction about my approach to adding the staging repository feature.

Adding a Staging Repository

currently archiva comes with two default permanent repositories.Those are internal repository Currently, Archiva has two permanent repositories called internal and the snapshots repository. My Here, my idea is to add another default repository called propose an intermediate staging repository where the developers can deploy their ongoing(to deploy artifacts which have not being been 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 attach it for a selected repository. The following example will illustrate that scenario.

Let's say the 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 attach this stage repository to his main repository called “data_repo”. (I hope to offer this function through the web interface). Here, user can add more than one stage repository so that simultaneous releasing function will be supported. 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. Here, for the QA, promotion and the developers, I am going to use current Archiva roles (Repository Manager and Repository Observer) and assign the permission for them.

I think by default 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 functionality. But those permissions should be configured to any role according to the requirementsSo the visibility of the repository should be only with in the archiva registererd users.

Creating Roles for this staging repository

...

Read and Write access to the repository

Here, registered users can read and write artifacts to the repository. Here , where 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. 2) Promotion Also QA guys should be able to mark the artifact as success one or a failure one. Then it will be useful for the merging part to take a correct decision.

Promotion of 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 merging artifacts from staging repository to the internal repository or the snapshot repository. It depends on the artifact(snapshot or a version). Here i I am going to consider the following things regarding the merging the artifacts:

  • If the artifacts artifact that are is going to deploy be deployed is not an existing one (new one), just deploy it with creating new meta data file. (User should be able to merge the artifact by clicking the merge button and then should receive a success/failure message from the Archiva side)
  • If the artifact is a new version of an existing artifact in the internal repository and then deploy the artifact and also update the meta data file.(exsisting one)

eg : lets say version 1.0 is available in internal repo and i need to deploy version 1.1 to the internal repository form the staging repository.

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

Steps:

...

  • one (in the case of re-release), we need to provide following options:
    • When the user clicks merge button (in the case of re-release), it should notify the user about the existing version in the release repository.(eg : version number + updated date).
    • Then we need to suggest to him the following options:
      • skip the re-release
      • merge the artifact while removing the older one. Here we should only allow the user to remove the latest artifact. Meanwhile, metadata updating should also be done.

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

Implementation

  • add stage repository function so that user can create a stage repository and attach it to a particular release repository. (This functionality is granted only for the admin level users). Proper UI should be provide to the user.
  • restrict this staging repository from being used

...

  • as a plugging repository from out user as mentioned in

...

  • the pom.xml files

...

  • implement the read action and the write actions and assign them to

...

  • existing roles. (Repository Manager and Repository Observer)
  • implement

...

  • the promotion role. (

...

  • Only the merging based on the assumption that a new artifact is being deployed. Not

...

  • an updated version)
  • implement

...

  • a searching algorithm to check the older

...

  • version of the

...

  • artifact which have already been deployed.
  • add searching feature (action) to the promotion role and do the merging part by providing the options regarding the version as mentioned above (with a proper UI). Here, metadata updating should be done.

...

  • implement logs for staging repository

Further enhancements

  • add the simultaneous deployment functionality for the stage repositories. (Here, need to find a way to check with repository is busy with a deployment)