Once you complete the process outlined in Section 9.4, “Performing a Staged Deployment with Maven”, you will then have an automatically generated Staging Repository. In this section, you will walk through the process of managing staging repositories. Once a staging repository has been created, there are two steps in the lifecycle of a staging repository. Once you have deployed a set of related artifacts, you must "Close" the repository moving it from an "Open" to a "Closed" state. Once a repository is in the "Closed" state it is added to a Repository Group and is made available for testing purposes. Once testing is completed, a Nexus administrator can either Promote or Drop a Closed repository. If the repository is Dropped, the repository is discarded and removed from the Repository Group. If the repository is Promoted, the Nexus administrator can select a Hosted repository and publish the contents of the temporary staging repository to a Hosted repository.
Once you deploy an artifact that triggers a staging profile, Nexus Staging Suite will create a repository that contains the artifacts you deployed. A separate staging repository is created for every combination of User ID, IP Address, and User Agent. This means that you can perform more than one deployment to a single Staging Repository as long as you perform the deployment from the same IP, with the same deployment user, and the same installation of Maven. You can perform multiple deployments to an "Open" staging repository, to see a list of these temporary "Open" Staging repositories, select "Staging" from the Nexus menu and click on the appropriate Staging Profile to browse a list of staging repositories which correspond to a staging profile.
Once you are ready to start testing the staging repository, you will need to transition the staging repository from the "Open" state to the "Closed" state. This will close the temporary staging repository to more deployments. To close a repository, right-click on the repository in the Staging Repositories panel and select "Close". This will bring up the following dialog for a staging deployer to describe the contents of a staging repository. This description field can be used to pass essential information to the person that needs to test a deployment. In Figure 9.16, “Confirmation and Description Dialog for Closing a Staging Repository”, the description field is used to describe the release for the user that needs to certify and promote a release.
Confirming this state transition will close the repository and add the repository to a repository group. Once a repository has been closed, it will be listed as "Closed" in the Profile's Repositories tab.
Once the Staging Repository has been closed, it will automatically be added to the Repository Group that was specified in the Staging Profile. Figure 9.18, “Staging Repository Added to the End of a Repository Group” shows an instance of a staging repository appended to the end of a group named "Public Repositories". This has the effect of making the staged artifacts available to everyone who is referencing this public group. Developers who are referencing this public repository group can now test and interact with the staged artifacts as if they were published to a Hosted repository. While the artifacts are made available in a repository group, the fact that they are held in a temporary staging directory gives the administrator the option of promoting this set of artifacts to a Hosted repository or dropping this temporary staging repository if there are problems discovered during the testing and certification process for a release.
Once a staging repository is closed, you can also browse and search the repository. To view Staging Repositories, click on Browse Repositories and then select Nexus Managed Repositories as shown in Figure 9.19, “Viewing Nexus Managed Repositories”.
Once you've selected Nexus Managed Repositories, Nexus will then show you all of the repositories that have been created by the Nexus Staging Suite. You can select and browse this temporary Staging Repository as you would any other repository.
You can browse the contents of a staging repository from the Staging Repositories panel. Click on Staging Repositories in the Nexus menu, click on a Staging Repository to browse the contents and perform operations a staging repository.
Once you are finished testing or certifying that the contents of a Staging Repository are correct, you are ready to either Release or Drop the Staging Repository. Dropping the Staging Repository will delete the temporary staging repository from Nexus and remove any reference to this repository from the groups it was associated with. Releasing the Staging Repository allows you to publish the contents of this temporary repository to a Hosted repository.
To release a Staging Repository select Staging from the Nexus menu and then click on the appropriate Staging Profile. This will display a list of Staging Repositories associated with that Staging Profile. To release the contents of a repository, load the list of Staging Repositories, check the box next to the staging repository you which to promote and then click the Release button shown in Figure 9.22, “Promoting a Staging Repository”.
Once you click Release, the Nexus Staging Suite will ask you to supply a description for this release action.
Supplying a description and clicking on Release will publish the contents of a Staging Repository to a Hosted repository and delete the Staging Repository from Nexus.
If you have a staging repository that you want to promote to a Build Promotion profile, open the list of Staging Repositories by selecting Staging Repositories from the Nexus menu, select the repository you intend to promote, and click the Promote button as shown in Figure 9.25, “Promoting a Staging Repository”.
After clicking the Promote button the Promote Staging Repository shown in Figure 9.26, “Multi-level Staging and Build Promotion” will be displayed. In this dialog, you can choose the Build Promotion profile to promote the staging repository to, and you can supply a short description of the promotion. Clicking on the Promote button in this dialog will promote the staging profile to a build promotion profile and expose the contents of the selected staging repository through a group associated with the build promotion profile.
After you promote a staging repository to a Build Promotion profile the build promotion profile will create a temporary repository which contains the contents of the promoted staging repository. The staging repository will be a Group Member of the Build Promotion repository. One more more staging repositories can be promoted to a single Build Promotion profile, and you can browse the Group Member by selecting the Build Promotion reposiotry and viewing the Group Member tab as shown in Figure 9.27, “Multi-level Staging and Build Promotion”.
When you configure a Build Promotion profile and promote Staging Repositories to promotion profiles, each Build Promotion profile creates a repository which contains one or more Staging Repositories. Just like you can promote the contents of a Staging Repository to a Build Promotion profile, you can also promote the contents of a Build Promotion profile to another Build Promotion profile. When you do this you can create hierarchies of staging repositories and build promotion profiles which can then be dropped or released together.
When you promote a staging repository to a build promotion profile, you make the contents of a staging repository available via a repository group associated with a build promotion profile. For example, if you staged a few artifacts to a QA Staging Repository and then subsequently promoted that repository to a Closed Beta Build Promotion group, the contents of the QA Staging Repository would initially be made available via a QA Repository Group. After a build promotion, these artifacts would also be available via a Closed Beta repository group. You can take it one step further and promote the contents of the Closed Beta Build Promotion profile to yet another Build Promotion profile. In this way you can have an arbitrary number of intermediate steps between the initial staging deployment and the final release.
If you drop the contents of a build promotion profile, you roll back to the previous state. For example, if you decided to drop the contents of the Closed Beta build promotion group, Nexus will revert the status of the Staging Repository from promoted to closed, and make the artifacts available via the QA Staging Repository. The effects of promoting, dropping, and releasing artifacts through a series of Staging Profiles and Build Promotion Profiles is shown in Figure 9.28, “Releasing, Promoting, and Dropping Build Promotion Profiles”.
When you perform a release on a Build Promotion profile, each Staging Repository is going to release artifacts to the Release Repository configured in Figure 9.8, “Editing a Staging Profile”. Because a Build Repository can contain one or more promoted staging repositories, this means that releasing a Build Promotion profile can cause artifacts to be published to more than one Release Repository. Build Promotion profiles are not directly related to release repositories, only staging profiles are directly associated with target release repositories. Figure 9.29, “Promoting Multiple Repositories to the Same Build Promotion Profile” illustrates this behavior with two independent Staging Repositories each configured with a separate Release Repository. Releasing the Build Promotion profile causes Nexus to publish each Staging Repository to a separate hosted repository.
