The Google Summer of Code (GSoC) recently wrapped up. The Archiva project was one of the projects in the Apache Software Foundation that participated in the program. Eshan Sudharaka, a student from the University of Moratuwa in Sri Lanka, submitted a proposal in the GSoC to work on the staging repositories and artifact promotion support feature of Archiva.
You might wonder what staging repositories and artifact promotion are. Let me explain that a bit..
One of the important concepts in developing software is releasing. Releasing means freezing your code, versioning it and then publishing it to an artifact repository which can be consumed publicly or internally. Now, usually when you release software, it undergoes testing first before it gets officially published (e.g. pushed to a repository where users of the software or project can get it). That’s where staging repositories come in. It is the place where a release is first pushed where developers, testers and QA engineers get the release for testing before it is pushed and made available to the project’s official download repository.
Here’s how this feature currently works in Archiva..
When creating a new managed repository, you will be given an option to create a staging repository by ticking the Create stage repository checkbox as seen below.
The staging repository can be distinguished from the managed repository it is attached to by the -stage appended to it’s ID. So in the above example, since the ID of the managed repository is myproject.releases, the staging repository attached to it is myproject.releases-stage. While the former is accessible in the webdav URL http://mycompany.com/archiva/repository/myproject.releases/, the latter is accessible in http://mycompany.com/archiva/repository/myproject.releases-stage/.
So when you release your project, you can deploy it to the staging repository first where it can be obtained for testing (and in cases of open source projects, undergo voting in the community).
Once testing (and voting) is finished, and the release has been approved, it can now be promoted to the official repo, which is the myproject.releases repository in our example above. This can be done in Archiva by clicking the Merge button in the repositories page as seen below.
Archiva will then check for possible conflicts — artifacts in the staging repository with the same version already existing in the managed repository. If there are conflicting artifacts found, they will be listed where you can choose whether to merge everything (existing artifacts will be overwritten) or to skip the conflicting artifacts in the merge.
Once you selected an option, the contents of the staging repository will be merged to the managed repository.
This is still the initial implementation of the feature and there are still a number of enhancements to watch out for. One of these is the ability to select specific conflicting artifacts to merge as an additional option aside from just skipping everything or merging everything. The UI can also use some improvements. Access control on who can merge/promote artifacts can also needs to be improved. Right now only users with a System Administrator role can do this.