Staging Profiles define the rules by which artifact deployments are staged in Staging Repositories. Staging Repositories are created as they are needed and are the primary mechanism by which Nexus users can promote or discard the contents of a staging repository to a hosted repository. A staging profile uses a Repository Target to match artifacts as they are deployed, if a matching artifact is deployed to Nexus, the Staging Suite will intercept this deployment and store the artifact in a staging repository.
The process for configuring a new Staging Profile is as follows:
-
Configure a Repository Target to match artifacts under the groupId you will be deploying artifacts to. If you are releasing all of your software under the groupId com.example, you would configure a target that matched the pattern ".*/com/example/.*".
-
Create a new Staging Profile using the target defined in the previous step. When you configure this staging profile, you will be defining a target repository group. When the Staging Suite intercepts an artifact and places it in a staging repository, this staging repository will be added to the target group.
-
Assign the appropriate Staging-specific roles to the appropriate users. When you create a Staging Profile, Nexus also creates two new roles that grant access and privileges to the repositories created by this Staging Profile.
The following sections provide a more detailed look at the process of configuring a single staging profile in Nexus Professional.
The Staging Suite intercepts deployments to repository
targets. For example, if you wanted to intercept all deployments to the
com.sonatype.sample groupId, you would create a Repository Target call
the "Sample Target" with a pattern expression of
".*/com/sonatype/sample/.*". Do this by clicking on
"Repository Targets" in the left-hand navigation menu in Nexus and then
clicking on the button.
Staging profiles control the process by which artifacts are selected for staging. When you define a Staging profile, you are defining a set of rules which will control the way in which Nexus intercepts an artifact deployment. When you click on Staging Profiles in the Nexus menu, you will see a list of configured staging profiles. Clicking on Add will display the dropdown menu shown in Figure 9.7, “Multi-level Staging and Build Promotion”.
Selecting Staging Profile will create a new Staging Profile and display the form shown in Figure 9.8, “Editing a Staging Profile”.
Figure 9.8, “Editing a Staging Profile” defines a Staging
Profile using a Repository Target configured in Section 9.3.1, “Configuring a Staging Target”. This target will match all
artifacts under the com.sonatype.sample group ID (or
the com/sonatype/sample repository path). This
staging profile uses the "Maven2 Hosted Release Repository" as a
template for newly created temporary staging repositories, and it will
automatically add closed staging repositories to both the Public
Repositories group and the Public Snapshot Repositories group.
This form allows you to configure a profile. Every profile has a name, is associated with a Repository Target, and points to a template to use when creating a new staging repository. The Staging Profile configuration panel contains the following fields:
- Profile Name
-
The Name of the Staging Profile. This can be an arbitrary value. It is simply a convenience for the Nexus Administrator, and it is also used to create Nexus roles that are used to grant permissions to view and manipulate staging repositories created by this profile.
- Staging Mode
-
This field contains the options "Deploy", "UI Upload", and "Deploy and UI Upload". This controls how artifacts can be staged to this staging profile. If Deploy is selected, artifacts can only be deployed using Maven to upload build artifacts. If UI Upload is selected, users can upload artifacts to Nexus using the Nexus user interface.
- Template
-
Defines a template for the temporary staging repository. The current version of Nexus Professional only allows for a single option in this dropdown "Default Release Hosted Repository Template"
- Repository Target
-
This is a reference to the target which we defined in Section 9.3.1, “Configuring a Staging Target”. When a developer deploys an artifact to the Staging URL, the Staging Suite will check to see if the artifact matches the patterns defined in the Repository Target. The Target defines the "trigger" for the creation of a Staging Repository.
- Release Repository
-
Staged artifacts are stored in a temporary staging repository which is made available via Target Groups. Once a staged deployment has been successfully tested, artifacts contained in the temporary staging repository are published to a hosted repository. The Release Repository setting configures the target release repository for this staging profile.
- Content Type
-
Nexus can create staging repositories for repositories of type maven1, maven2, and Eclipse P2 repositories. This chapter only deals with maven2 repository types.
- Target Groups
-
When a Staging Repository is "Closed" and is made available to users and developers involved in the testing process, the temporary Staging Repository is added to a Repository Group. This field defines that group.
- Close Repository Notification Roles
-
After a developer has deployed a set of related release artifacts, a staging repository is "closed". This means that no further artifacts can be deployed to the same staging repository. A repository would be closed when a developer is satisfied that a collection of staged artifacts is ready to be certified by a manager or a quality assurance resource. The Close Notification Role contains all Roles which should be notified of a staging repository being closed. All Nexus users in the specified Role will be notified via email that a staging repository has been closed.
- Promotion Repository Notification Roles
-
Once a staging repository has been closed and certified by a whoever is responsible for testing and checking a staged release, it can then be promoted or discarded. This list of roles defines the roles that need to be notified that a repository has been promoted or discarded. All users with the roles specified in this list will be notified when a staged repository is either promoted or discarded.
- Close Staging Repository Rulesets
-
This defines the rulesets which will be applied to a staging repository before it can be closed. If the repository does not pass the rules defined in the promotion rulesets, you will be unable to close a staging repository. For more information about rulesets, see Section 9.6.1, “Managing Staging Rulesets”.
- Promote Staging Repository Rulesets
-
This defines the rulesets which will be applied to a staging repository on promotion. If the repository does not pass the rules defined in the promotion rulesets, the promotion will fail with an error message supplied by the failing rule. For more information about rulesets, see Section 9.6.1, “Managing Staging Rulesets”.
Once you've created a Staging Repository with the values shown in Figure 9.8, “Editing a Staging Profile”, you are ready to perform a test deployment to the Staging URL.
A Build Promotion profile is used when you need to add an additional step between initial staging and final release. To add a new Build Promotion profile, open the Staging Profiles link from the Nexus menu and click on Add... to display the dropdown menu shown in Figure 9.9, “Multi-level Staging and Build Promotion”. Select Build Promotion Profile from this dropdown to create a new Build Promotion Profile.
After creating a new Build Promotion profile, you will see the form shown in Figure 9.10, “Configuring a Build Promotion Profile”. This form contains the following configuration fields:
- Profile Name
-
This is the name for the Build Promotion profile which will be displayed in the promotion dialog shown in Figure 9.26, “Multi-level Staging and Build Promotion”. This name will also be associated with repositories created from this promotion profile.
- Template
-
This is the template for repositories generated by this Build Promotion profile. The default value for this field is "Maven2 (group)".
- Target Groups
-
This is the most important configuration field for a Build Promotion profile. It controls the group that promoted artifacts will be made available through. Artifacts can be made available through one or more groups.
To perform a staged deployment, the user deploying the artifact must have the "Staging: Deployer (admin)" role or a "Staging: Deployer" role for a specific Staging Profile.
When you create a Staging Profile, Nexus will create two new Nexus roles that grant permissions specific to that staging profile. If you created the Staging profile from the previous section, Nexus would have created two roles:
- "Staging: Repositories (Release Staging Profile)"
-
This role grants a user read and view access to the staging repositories created by a specific staging profile.
- "Staging: Deployer (Release Staging Profile)"
-
This role grants all of the privileges from the Staging: Repositories role and it grants the user permission to deploy artifacts, close a staging repository, and promote a staging repository.
In addition to the profile-specific staging roles, the Staging Suite also defines two universal roles which grant read-only or deployer rights across all staging repositories. These roles are:
- "Staging: Repositories (admin)"
-
This role grants a user read and view access to all staging repositories.
- "Staging: Deployer (admin)
-
This role grants a user all of the privileges from the Staging: Repositories role and it grants the user permission to deploy artifacts to any staging repository, close all staging repositories, and promote all staging repositories.
To configure the deployment user with the appropriate staging role, click on Users under the Security menu in the Nexus menu. Once you see the Users panel, click on the deployment user to edit this user's roles. If the Staging Suite is installed, you should see the "Staging: Deployer (admin)" role listed in Available Roles. Select the "Staging: Deployer (admin)" role and then click the left arrow to add this role to the deployment user's list of assigned roles.
Once the deployment user has the "Staging: Deployer (admin)" role, you can then use this user to deploy to the staging URL and trigger any Staging Profile. Without this permission, the deployment user would not be able to publish a staged artifact. If you need to add a specific permission to activate a single Staging Profile, you would select that specific role in the Available Roles list shown in Figure 9.11, “Assigning the Staging Deployer Role to the deployment user”. In this figure, note that there are two "Staging: Deployer" roles: one for general administrative permission to deploy to any staging profile, and another which targets a specific staging profile.
