Documentation Nexus IQ Server 1.16

Our documentation site has moved. For the most current version, please see http://help.sonatype.com

11.8. Label Overview

Labels are one of the more powerful features of Sonatype CLM, though they operate similar to other label or tagging systems you have likely used. Basically you create a number of labels or tags as a set of available values and then assign them.

For example in a photo collection you could have labels for the content like sunset', mountain, ocean, waterfall and so on. An individual photo could then have multiple of these labels assigned. In a similar way you can use labels in Sonatype CLM to identify a particular type of component. An approved component or a component that needs research. Labels can be anything you desire and can have a number of contexts as well. Some labels might be architecture related, while others are related to legal and security properties and yet others are simply signaling ownership by a specific team. The flexibility of the label system allows you to design your own use cases and implement them.

Label creation and management is performed in the Sonatype CLM server organization and application configuration. Assigning those labels to a particular component is a function of the application composition report.

figs/web/clm-server-labels-overview.png

Figure 11.36. Labels at the CLM Server Level


11.8.1. Where do labels begin?

Initially, label assignment might seem like a task that deserves less process. It’s actually the opposite.

The label process actually starts at the Sonatype CLM server, where each organization, and in many cases application, have a specific set of labels.

Creating labels at this level means that they are available to users of the application composition report. So, before you label something, a number of things need to be considered, which might mean you need to go back to label and policy management. Let’s take a look at some questions that we can use to form a baseline to what labels we need and/or should have.

Do we have a process defining labels, as well as how and when they should be used? Every label should have a reason for using it. If it doesn’t you don’t need it. That’s because people will naturally infer meaning to the label. For example, if you have a needs review label, you should have a process for reviewing components with that label. It shouldn’t merely be a tag. You should also consider adding labels such as reviewed, so someone can tell if something was reviewed. The possibilities are endless, but this may mean you need to rethink the labels you have, or should create.

Should this label apply to only my applications, or all applications for this organization? We like to refer to this as the scope of a label. A good way to look at scope is the concept of macro and micro. At the macro level we have an organization that may have thousands of applications. If I apply this label to the component at the macro level (organization) it means the label will be seen by all applications under that organization. That’s a pretty sweeping change, and it could be the right thing to do. However, you might actually be better served by considering the impact at the micro level. In this case, maybe this is a label that should only be applied to a particular application.

[Note]

Only labels that have been created at the organization level, can be assigned to the scope of organization.

If I apply this label, is it part of a policy, and does it escape certain violations? Conditions in a policy can include values for labels. In many cases, this is best used as a way to prevent a certain component from violating the condition. For example, I could have a policy that requires a component to be no older than three years. However, a safe, and commonly used component is four years old. If I have a process built around reviewing a case like this, where an exception would be valid, I could first place labels to identify the component to be reviewed for an exception, and then another label once that exception is approved (or disapproved). In this scenario, if I have built policies correctly, including allowing them to flow through certain stages, even with a violation, development can continue. This of course should occur simultaneously to a review/exception process. It’s important to consider scenarios like this when creating labels, as well as policy.

There are more questions regarding labels that should be asked as well, but many of these you will discover as you develop your own processes. The key is that labels can be deceivingly simple, given their implementation in other systems. The reality is, that in Sonatype CLM, they are much more than just a component tag. Now that you have the word of warning, let’s take a look at how to assign a label.

11.8.2. Assigning a Label

When assigning a label, you will only have access to those labels created specifically for the application, or for that application’s organization. Given this, if you don’t see a label you need, speak with whomever is responsible for managing the labels for your application and the organization the application is associated to.

  1. Access the Application Composition Report for your application.
  2. Click on the Policy tab.
  3. Click a component you wish to assign a label to. The Component Information Panel (CIP) displays.
  4. Click the Label option from the CIP menu. Two boxes will be displayed:

    1. The Applied box on the left represents labels that have been assigned to the component already.
    2. The Available box on the right displays all labels.
  5. Clicking on the button on the right side of a label will move to the opposite side. Hovering over a label displays the description.
  6. Click on the + button on the right side of a label in the Available list to assign the label to the component.
  7. Click on the - button on the right side of a label in the Applied list to remove the label from the component.
figs/web/app-comp-report-label-assignment.png

Figure 11.37. Assigning a Label


If the label was created at the organization level, you will be presented with two options:

  • Apply the label to the current component in the current application
  • Apply the label to the current component within the organization, so that all applications within the organization gain access to the label assigned.