+ 1.

Another example:

$ /usr/local/coverity5/bin/cov-commit-defects --dir /storage/jenkins/coverity/TLINKSERVER_MAINLINE_COVERITY --host coverity55 --port 8080 --stream tlinkserver_trunk --user admin --description ${BUILD_TAG}

"${BUILD_TAG}" is a global variable

+1
--strip-path ${WORKSPACE}
or similar is extremely useful when using nodes with differing paths

I believe I've just sent a pull request on github for a patch that addresses this problem

Can we get an update as to whether this has been brought in yet? Also, I wonder if it would be possible to maintain a backported 1.2.4 branch for the folks who aren't using CIM v6 or greater...

Is there any plan to implement this capability?
It is very important for the plugin usage.

I believe this was resolved in more recent releases of the coverity plugin using the "advanced parsing mechanism". Part of my assumption is that there has been no activity on this issue for quite some time (and quite a few releases since last updated).

Please reopen if there's still an issue (or contact Synopsys (Coverity) support)

I am still not getting variables expanded properly when using the Synopsys Coverity Plugin v3.0.1 with Jenkins 2.332.3

At least, the fields for "Coverity project" and "Coverity stream" and not working. I'm trying to use this to create a generic downstream project to run Coverity tests after our CI builds have been run, as well as dynamically assign a stream name based on the git branch being built.

Agree to tyler_gustafson, we have been facing a similar issue with Jenkins 2.361.1 and Synopsys Coverity pluginVersion3.0.1
The fields "Coverity Project" and "Coverity Stream" are forced to be hardcoded rather than accepting dynamic values for reutilization of the same pipeline for various projects.

tyler_gustafson and shivangie_singh I assume you both are using the Synopsys Coverity plugin in a Jenkins Freestyle project? If so, I suggest opening a support ticket if you have not already.

Just a FYI... the plugin will properly expand variables when used in a Jenkins Pipeline (inline script or Jenkinsfile). For example:
https://github.com/chuckaude/hello-java/blob/main/jenkins/Jenkinsfile.coverity-plugin#L24

chuckaude shivangie_singh Thanks for the replies. I've opened a case with Synopsys and they have confirmed this is a bug. They are currently deciding when to fix it and have been for a few weeks.

If you can search their bug tracking system, the case number is #ICJ-239 and the title is: Jenkins Variables are not Expanded in Synopsys Coverity Plugin

I wouldn't be surprised if pipeline works as Chuck mentioned. For the time being I'm going to be duplicating projects with hardcoded values rather than rewriting our current ecosystem.

chuckaude Yes, as a workaround we have been using variables in the declarative pipeline script and it works perfectly fine, but we had to send considerate amount of time to figure out that the same is not working for freestyle job. Thanks for sharing the reference!

tyler_gustafson Thanks for raising the support ticket and sharing the details here.

The coverity plugin has been deprecated for many years. It is replaced with the Synopsys Coverity plugin. This issue will not be fixed in the Coverity plugin.