jenkinsci/dependency-track-plugin

Polling limit exceeded with repositories without dependencies

Opened this issue · 7 comments

Deleted user commented

Describe the bug

After update dependency track from 4.2.2 to 4.3.1 we receive this error in the pipelines without dependencies.

[DependencyTrack] Polling Dependency-Track for BOM processing status
[DependencyTrack] Polling Dependency-Track for results is taking longer than expected - polling limit exceeded

Environment

  • Plugin Version: 3.1.1
  • Jenkins Version: 2.250
  • Java Version for Jenkins:
  • Type of Jenkins Job: scripted pipeline
  • Dependency-Track Version: 4.3.1

To Reproduce

Steps to reproduce the behavior:

Only in the git repositories without dependencies.
In the BOM.xml upload after update de file and create the project, if is the case, we receive this message:

[DependencyTrack] Polling Dependency-Track for results is taking longer than expected - polling limit exceeded

The BOM.xml file is like this: (I delete some info)

<?xml version="1.0" encoding="utf-8"?> <bom xmlns="http://cyclonedx.org/schema/bom/1.2" serialNumber="urn:uuid:xxxxxxxxxxxxx" version="1"> <metadata> <timestamp>2021-08-06T09:10:58.715Z</timestamp> <tools> <tool> <vendor>CycloneDX</vendor> <name>Node.js module</name> <version>2.0.2</version> </tool> </tools> <component type="library" bom-ref="pkg:npm/api@1.174.0"> <name>api</name> <version>1.174.0</version> <description> <![CDATA[Repository containing the specification for the API.]]> </description> <licenses> <license> <id>ISC</id> </license> </licenses> <purl>pkg:npm/api@1.174.0</purl> <externalReferences> <reference type="website"> <url>https://api#readme</url> </reference> <reference type="vcs"> <url>git+ssh://git@api</url> </reference> </externalReferences> </component> </metadata> <components/> </bom>

I update the Polling Timeout with the same error

Expected behavior

In the previous version 4.2.2 with the same BOM.xml file the process works fine.

[DependencyTrack] Polling Dependency-Track for BOM processing status
[DependencyTrack] Looking up id of newly created project with name "api" and version "latest"
[DependencyTrack] Processing findings

sephiroth-j commented

In the previous version 4.2.2 with the same BOM.xml file the process works fine.

Then it would be a bug in DTrack itself and not in the Jenkins plugin, since the API for this check has not changed.

I have tested your bom with a clean setup of DTrack 4.3.1 and it returned the expected response with status code 200.

{
  "processing": false
}

As long as processing is still true, it means there is some sort of processing (mainly vulnerability analysis) being performed on the BOM. If this is still the case when the configured polling timeout is reached, then you get the "polling limit exceeded" error from the plugin.

Maybe DTrack just needed more time than you configured as polling timeout. Check your DTrack log, you should see something like this. The UUID is the ID of the project to which the BOM is uploaded. Watch for the line with "Completed analysis" and your projects ID.

dtrack-apiserver_1  | 17:59:27.932 INFO [BomUploadProcessingTask] Processing CycloneDX BOM uploaded to project: 253958c1-37e2-4ba5-95c6-8bf52c34fe1b
dtrack-apiserver_1  | 17:59:28.136 INFO [BomUploadProcessingTask] Processing CycloneDX dependency graph for project: 253958c1-37e2-4ba5-95c6-8bf52c34fe1b
dtrack-apiserver_1  | 17:59:28.140 INFO [VulnerabilityAnalysisTask] Analyzing portfolio
dtrack-apiserver_1  | 17:59:28.151 INFO [VulnerabilityAnalysisTask] Analyzing 0 components in project: 253958c1-37e2-4ba5-95c6-8bf52c34fe1b
dtrack-apiserver_1  | 17:59:28.154 INFO [BomUploadProcessingTask] Processed 0 components and 0 services uploaded to project 253958c1-37e2-4ba5-95c6-8bf52c34fe1b
dtrack-apiserver_1  | 17:59:28.154 INFO [VulnerabilityAnalysisTask] Completed analysis of 0 components in project: 253958c1-37e2-4ba5-95c6-8bf52c34fe1b
dtrack-apiserver_1  | 17:59:28.155 INFO [VulnerabilityAnalysisTask] Portfolio analysis complete
sephiroth-j commented

It suppose to process in 30 seconds max.

Check the DTrack logs to see how long the processing took. DTrack obviously took more time than the configured polling timeout. It is not uncommon that the processing time varies depending on the total load of DTrack. Versions prior to 4.3.0 also had a bug that caused high load and long processing times (DependencyTrack/dependency-track#1026).

There a several options to workaround this:

  • increase the polling timeout in the global options (default 5 minutes)
  • disable synchronous publishing mode
  • for pipline jobs: wrap the call of dependencyTrackPublisher in a try-catch block and ignore any errors that your DTrack server may has. You can find examples in the README and here.
msymons commented

@sephiroth-j, I have been able to duplicate this. I have several Maven projects that contain only dependencies with scope test. In DT 3.8.0 (which I was running until last week) there was no problem with using synchronous publishing mode for dependency-track-plugin. Every single one of these projects now fail with "polling limit exceeded" when using DT 4.3.1 (or 4.3.3). Increasing the polling timeout does not help.

To test things I created a simple maven project with a single dependency:

    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.13.2</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

In Jenkins, I used goal:

verify org.cyclonedx:cyclonedx-maven-plugin:2.5.2:makeBom

..and set up dependency-track-plugin as normal.

As expected, the build failed.

Editing the project POM and changing the scope for junit to compile resulted in a passing build.

I also tested with cyclonedx-maven-plugin 2.4.1 and 2.5.0 and 2.5.1 but this made no difference.

So, I think it might be a problem with Dependency-Track... but want to double-check that you see the same thing.

sephiroth-j commented

@msymons, yes, I see it the same way. The plugin simply uploads the file and waits for Dependency-Track to complete the processing of the newly uploaded BOM. The thing is that DTrack performs an analysis of the complete portfolio - that takes some time and there seems to be another performance issue there specifically.

I have checked it again using your example and DTrack v4.3.1 (Docker) with H2 DB. No problem with that combination. Apparently, either a sufficiently large portfolio and/or a different DB type such as PostgreSQL is required.

All I can do is create an upstream ticket on your behalf. But I would prefer if you do this because you can provide more details about your setup than I.

bom.xml

<?xml version="1.0" encoding="UTF-8"?>
<bom serialNumber="urn:uuid:3b9117c6-3a77-4540-a2c4-d21d685fe689" version="1" xmlns="http://cyclonedx.org/schema/bom/1.3">
  <metadata>
    <timestamp>2021-08-24T17:36:54Z</timestamp>
    <tools>
      <tool>
        <vendor>CycloneDX</vendor>
        <name>CycloneDX Maven plugin</name>
        <version>2.5.2</version>
        <hashes>
          <hash alg="MD5">c771d88878e3f655b4bbffcb2070721e</hash>
          <hash alg="SHA-1">1a001ec9d1a9c94e40a172f99c85c8f1c139461e</hash>
          <hash alg="SHA-256">e7eac6ba9d45ffdb2a3d5db326d3e5712efd1e02fa2f371e1e624e7eda48d0ed</hash>
          <hash alg="SHA-384">caf8d197889197b922a6cd85dc7cf4d9fb8f2e605abdd93b76fe0b9b4838a4bafa8461a0f3664a5d725ff07a1406f11f</hash>
          <hash alg="SHA-512">70d828c605929f48df9960214a573e7b3c73edd2eceb2ea683e20c9d84a18650508f221cadea84cca9561ef3b491eff15f6ec89988bd8005047ca561503a602c</hash>
          <hash alg="SHA3-256">72ba849fbbdaee309f27dfd0f045e8ce972cdfa10c9c1d832938ba7ae5f500af</hash>
          <hash alg="SHA3-384">dd4d5090f5176d6f121853453cd663a93ceaf56a79a64845a6c2f7ce03b4454eddd45fd3666d0f746d9c3ed067ecb20d</hash>
          <hash alg="SHA3-512">2bf61d8807438c7055cd5639ce646410e9af102249b09292f53d104fc44d6d7f576bac12f75794c6699c33f45d0ccb97249c4fdf334e7d3314a5f1b410289860</hash>
        </hashes>
      </tool>
    </tools>
    <component type="library" bom-ref="pkg:maven/com.example/demo@0.0.1-SNAPSHOT?type=jar">
      <group>com.example</group>
      <name>demo</name>
      <version>0.0.1-SNAPSHOT</version>
      <licenses/>
      <purl>pkg:maven/com.example/demo@0.0.1-SNAPSHOT?type=jar</purl>
    </component>
  </metadata>
  <components/>
  <dependencies>
    <dependency ref="pkg:maven/com.example/demo@0.0.1-SNAPSHOT?type=jar"/>
  </dependencies>
</bom>

DTrack log (UTC times)
2a4ecc77-1bb2-41db-b30e-99d8e30b31be is the project that was created during the BOM upload. The other two whre already present from earlier tests.

dtrack-apiserver_1  | 18:16:45.630 INFO [BomUploadProcessingTask] Processing CycloneDX BOM uploaded to project: 2a4ecc77-1bb2-41db-b30e-99d8e30b31be
dtrack-apiserver_1  | 18:16:45.673 INFO [BomUploadProcessingTask] Processing CycloneDX dependency graph for project: 2a4ecc77-1bb2-41db-b30e-99d8e30b31be
dtrack-apiserver_1  | 18:16:45.677 INFO [BomUploadProcessingTask] Processed 0 components and 0 services uploaded to project 2a4ecc77-1bb2-41db-b30e-99d8e30b31be

dtrack-apiserver_1  | 18:16:45.677 INFO [VulnerabilityAnalysisTask] Analyzing portfolio

dtrack-apiserver_1  | 18:16:45.687 INFO [VulnerabilityAnalysisTask] Analyzing 0 components in project: 253958c1-37e2-4ba5-95c6-8bf52c34fe1b
dtrack-apiserver_1  | 18:16:45.687 INFO [VulnerabilityAnalysisTask] Completed analysis of 0 components in project: 253958c1-37e2-4ba5-95c6-8bf52c34fe1b

dtrack-apiserver_1  | 18:16:45.687 INFO [VulnerabilityAnalysisTask] Analyzing 0 components in project: b59d8c4b-1a0e-4e8f-950e-db4ae37eff41
dtrack-apiserver_1  | 18:16:45.688 INFO [VulnerabilityAnalysisTask] Completed analysis of 0 components in project: b59d8c4b-1a0e-4e8f-950e-db4ae37eff41

dtrack-apiserver_1  | 18:16:45.688 INFO [VulnerabilityAnalysisTask] Analyzing 0 components in project: 2a4ecc77-1bb2-41db-b30e-99d8e30b31be
dtrack-apiserver_1  | 18:16:45.688 INFO [VulnerabilityAnalysisTask] Completed analysis of 0 components in project: 2a4ecc77-1bb2-41db-b30e-99d8e30b31be

dtrack-apiserver_1  | 18:16:45.688 INFO [VulnerabilityAnalysisTask] Portfolio analysis complete

Plugin Log (UTC times + german)

18:16:45.510  [Pipeline] {
18:16:45.555  [Pipeline] dependencyTrackPublisher

18:16:45.572  [DependencyTrack] Hochladen von Artefakt in Dependency-Track - http://localhost:8082
18:16:45.638  [DependencyTrack] Das Artefakt wurde erfolgreich hochgeladen. Sie können nun http://localhost:8080/projects/ aufrufen, um die Ergebnisse anzusehen.
18:16:45.638  [DependencyTrack] Warte auf Ende der Analyse in Dependency-Track
18:16:55.657  [DependencyTrack] Ermittle ID des eben erzeugten Projekts mit Namen "issue-47-test" und Version "0.0.1"
18:16:55.666  [DependencyTrack] Verarbeite Ergebnisse

18:16:55.685  [Pipeline] }
18:16:55.739  [Pipeline] // withCredentials
18:16:55.753  [Pipeline] }
18:16:55.793  [Pipeline] // stage
18:16:55.803  [Pipeline] }
18:16:55.846  [Pipeline] // node
18:16:55.863  [Pipeline] End of Pipeline
18:16:55.904  Finished: SUCCESS
  • 👍1
msymons commented

@Mariano-geko, @sephiroth-j

The defect is fixed in Dependency-Track v4.3.6. I have tested it and things look good.

sephiroth-j commented

@msymons, that's good news, thanks for the confirmation.