Artifact fingerprinting
DevOptics value streams track artifact creation and use by fingerprint. If an artifact is created, but does not have a fingerprint recorded, tickets related to builds of that artifact won’t leave their initial gate.
Fingerprints are generated in:
-
Jenkins Pipeline with the
fingerprint: trueargument toarchiveArtifacts -
Jenkins Freestyle jobs with the
Record fingerprints of files to track usagepost build action -
Jenkins Freestyle jobs with the
Archive the artifactspost build action, using the advanced checkboxFingerprint all archived artifacts
Rule: Fingerprint the artifacts
Ticket assignment
Tickets are assigned to a gate when they are mentioned in a commit. They move from the gate when the artifacts created in the gate are used in the next gate.
If artifacts are not used in a later gate, then the ticket won’t move to the later gates.
If an artifact is embedded completely into another artifact (source code for a library compiled into a different library, or a Java jar file is placed inside a WAR file), then that artifact may not be detected as "used" in later gates. For example, if a library gate creates a library, a service gate embeds that library into the service, and an integration gate embeds the service, then tickets assigned to the library gate initially will not move to the integration gate unless the integration gate directly uses the library gate artifact.
Rule: Use the fingerprinted artifacts
Git commits
Commits refer to tickets by including the ticket identifier (like EXAMPLE-12345) in the commit message.
Tickets won’t be assigned to their initial gate unless they are mentioned in a commit.
Rule: Include the ticket ID in the commit message
Git links
Summary descriptions of commits are displayed in the delivery stream view. Clicking the summary of the change will open the URL of the source control change.
If the summary does not open or opens the wrong URL, the gate job is not configured with the correct repository browser.
Rule: Configure the git repository browser in the gate job
Jira® servers
Tickets are identified by a "project key" when they are mentioned in a commit. The list of known project keys is displayed in the DevOptics settings page (from the "gear" icon). If the list of project keys is empty, the Jira® server URL is not configured or is incorrectly configured. Use system configuration to define Jira® server URLs.
If an organization uses multiple Jira® servers, they can all be included in the system configuration. If multiple Jira® servers are defined, earlier servers in the list are given precedence over later servers when selecting project keys.
Thus, if an internal Jira® server is listed first, and a public project Jira® server second, project keys from the internal server will be matched first. When both servers define the same key (for example, "SECURITY-" is defined in both the internal Jira® server and the public Jira® server), the first server in the list is used for those links.
Visibility to Jira® server project keys can also be limited by choosing the credentials used to access the Jira® server. The same Jira® server URL may be included multiple times if different credentials are needed for access to specific Jira® project keys.
Rule: Configure the Jira® server URL(s)
Diagnostics
The events plugin reports the status of its connection to the DevOptics service through Jenkins > Manage Jenkins > DevOptics.
The plugin reports On-line and Configured and associated with the CloudBees account, when the plugin is correctly licensed, configured, and operating correctly.
If the plugin is unable to connect to the DevOptics service, it reports Not enabled and This master is NOT enabled for connections to the DevOptics service.
Licensing
DevOptics is a licensed product. The DevOptics plugins will not operate without an active subscription. If the subscription is not activated, the Jenkins > Manage Jenkins > DevOptics menu option will not be available.
Thread pooling and performance issues
If you have a busy Jenkins master that processes many jobs, you may notice a decrease in performance due to thread pooling for run insights. To increase performance, a Jenkins administrator can change the way in which tasks for run insight metrics are tracked to a less resource-intensive option.
To change the way tasks are tracked for run insights:
-
Go to Jenkins > Manage Jenkins.
-
Select Configure System.
-
Under DevOptics, in Metrics Sub-Task Tracking Strategy, select one of the following options:
-
Automatic - This is the default option and is the recommended option for most Jenkins masters. With this option, DevOptics switches between the High Accuracy option and the Large Master Mode option based on the number of threads in the thread pool versus the number of processors that are available to the Jenkins master. This provides a balance between performance and accuracy of metrics.
-
High Accuracy - With this option, you receive the most accurate metrics for run insights. However, it might be resource-intensive, and therefore might impact performance. This option uses a thread pool.
-
Large Master Mode - With this option, you receive less accurate metrics for run insights than you receive with the High Accuracy option. However, it is not as resource-intensive as the High Accuracy option and therefore does not have as much of an impact on performance. This option uses a polling mechanism.
-
-
Click Save.