The excludeFile filter should work on the absolute path name. It expects a regular expression, e.g. .*/path/to/exclude/.*.

Do all your warnings have an absolute path resolved? I think someone did report an issue with the gcc parser in the wiki: seems that only relative files are reported.

Does the plugin report errors in the console log (or in the UI, you need to click on the exclamation mark icon).

If you have errors about not resolvable files it might help to use the parser GnuMakeGcc.

Ahhh. I didn't realise that it was REs since the docs said pattern which usually means _glob_s. I'll try using REs.

If you have errors about not resolvable files it might help to use the parser GnuMakeGcc.

Does this actually require that make be used to drive the gcc commands though?  We're not using make here.

Surely the RE for your example should be:  .*\/path\/to\/exclude\/.*, yes? Or is / not considered special in whatever RE module you are using?

But that doesn't seem to be working either.  I have:

filters: [excludeFile('.*\\/_build.external\\/.*')]

But still seeing this when I click the exclamation mark:

Can't resolve absolute paths for some files:- topology-linux.c- topology-linux.c- topology-linux.c- topology-linux.c- topology-linux.c  ... skipped logging of 761 additional errors ...Can't create fingerprints for some files:- 'topology-linux.c', IO exception has been thrown: java.nio.file.NoSuchFileException: topology-linux.c- 'topology-linux.c', IO exception has been thrown: java.nio.file.NoSuchFileException: topology-linux.c- 'topology-linux.c', IO exception has been thrown: java.nio.file.NoSuchFileException: topology-linux.c- 'topology-linux.c', IO exception has been thrown: java.nio.file.NoSuchFileException: topology-linux.c- 'topology-linux.c', IO exception has been thrown: java.nio.file.NoSuchFileException: topology-linux.c  ... skipped logging of 767 additional errors ...Can't create blame requests for some affected files:- Skipping non-workspace file topology-linux.c- Skipping non-workspace file topology-linux.c- Skipping non-workspace file topology-linux.c- Skipping non-workspace file topology-linux.c- Skipping non-workspace file topology-linux.c  ... skipped logging of 761 additional errors ...Git blame reported several errors:No blame results for request <@2/_build.external/mercury/Testing/util/test_atomic_queue.c - [32, 31]>.
Git blame reported several errors:No blame results for request <_build.external/mercury/Testing/na/na_test.c - [517]>.
Git blame reported several errors:No blame results for request <_build.external/pmix/src/mca/gds/gds.h - [320]>.
Git blame reported several errors:No blame results for request <_build.external/mercury/src/util/mercury_atomic_queue.h - [158]>.
Git blame reported several errors:No blame results for request <@2/_build.external/pmix/src/mca/gds/gds.h - [320]>.
Git blame reported several errors:No blame results for request <@2/_build.external/mercury/Testing/na/na_test.c - [517]>.
Git blame reported several errors:No blame results for request <@2/_build.external/mercury/src/util/mercury_atomic_queue.h - [158]>.
Git blame reported several errors:No blame results for request <_build.external/mercury/Testing/driver/kwsys/ProcessUNIX.c - [1477]>.
Git blame reported several errors:No blame results for request <@2/_build.external/mercury/Testing/driver/kwsys/ProcessUNIX.c - [1477]>.

I would think I shouldn't be seeing those <@2/build.external/mercury _git blame issues if the filter was working correctly should i?

On the other hand I also see:

Information Messages
Parsing console log (workspace: '/var/lib/jenkins/workspace/daos-stack-org_daos_PR-13-XSYVVAKVRRCIRZBUBQLEPYMVXQHYAQV52HHPQR55EURLM5NXUHMA')
Post processing issues on 'wolf-53vm10' with encoding 'UTF-8'
Resolving absolute file names for all issues
-> 0 resolved, 766 unresolved, 14 already absolute
Copying affected files to Jenkins' build folder /var/lib/jenkins/jobs/daos-stack-org/jobs/daos/branches/PR-13/builds/394
-> 0 copied, 5 not in workspace, 176 not-found, 0 with I/O error
Resolving module names from module definitions (build.xml, pom.xml, or Manifest.mf files)
-> resolved module names for 780 issues
Resolving package names (or namespaces) by parsing the affected files
-> resolved package names of 181 affected files
Creating fingerprints for all affected code blocks to track issues over different builds
-> created fingerprints for 8 issues
Invoking Git blamer to create author and commit information for all affected files
GIT_COMMIT env = 'HEAD'
Git working tree = '/var/lib/jenkins/workspace/daos-stack-org_daos_PR-13-XSYVVAKVRRCIRZBUBQLEPYMVXQHYAQV52HHPQR55EURLM5NXUHMA'
Git commit ID = 'a290947bd9eccd688aa6dbdd0654bd8e755a4aad'
Job workspace = '/var/lib/jenkins/workspace/daos-stack-org_daos_PR-13-XSYVVAKVRRCIRZBUBQLEPYMVXQHYAQV52HHPQR55EURLM5NXUHMA'
Created blame requests for 9 files - invoking Git blame on agent for each of the requests
-> blamed authors of issues in 9 files
Parsing console log (workspace: '/var/lib/jenkins/workspace/daos-stack-org_daos_PR-13-XSYVVAKVRRCIRZBUBQLEPYMVXQHYAQV52HHPQR55EURLM5NXUHMA')
Applying 1 filters on the set of 780 issues (14 issues have been removed, 766 issues will be published)
Using reference build 'daos-stack-org/daos/PR-13 #391' to compute new, fixed, and outstanding issues
Issues delta (vs. reference build): outstanding: 766, new: 0, fixed: 14
No quality gates have been set - skipping
Health report is disabled - skipping

and it does say 14 issues have been removed, but there should be many many more than 14.

As an aside, is there any easier/quicker way to test different include/exclude filters against existing output rather than have to run the whole job again, complete with an actual compile, etc.?

I've tried GnuMakeGcc since in fact the files I want to exclude in in projects under the excluded subdirectory built with make.

I have also added a second filter to match non-fully-qualified path names in addition to the fully-qualified-path filter I already had:

filters: [excludeFile('.*\\/_build\\.external\\/.*'),
          excludeFile('_build\\.external\\/.*')] 

Neither of those has eliminated the bulk of those 700+ compiler warnings that I want to exclude.

Currently the filter is invoked after all preprocessing steps. I.e. after absolute paths have been detected, etc. Maybe it makes sense to move this step to the beginning (or after the absolute path resolving).

From the log I see that almost every warning has no absolute path (0 resolved, 766 unresolved, 14 already absolute). I.e. the parser seems not to work as expected.

What makes me wonder: the log says: applying 1 filter, but in your example you have 2.
But anyway, I think you need to change the regular expression so that it matches the entire file name, not only a portion. I.e. in your example the .* is missing in the front. See the new test that shows that the filter works.

Maybe it makes sense to add an example text box in the UI of the snippet generator so you can experiment with the filter regexp.

Should I change the name of the 'pattern' box to 'regular expression'? I can clarify as well that the whole property text must match. Java regular expressions are a little bit different since they match the entire string. I'll check if there is something available that matches only a part of the string.

From the log I see that almost every warning has no absolute path (0 resolved, 766 unresolved, 14 already absolute). I.e. the parser seems not to work as expected.

If filenames are always supposed to be absolute, then, yes, I would agree that the parser is not quite working correctly. I'm not sure how it's supposed to calculate absolute pathnames when gcc output looks like:

[Build on CentOS 7] keyval_lex.c: In function ‘pmix_util_keyval_yylex’:
[Build on CentOS 7] keyval_lex.c:947:23: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
[Build on CentOS 7]     for ( yyl = 0; yyl < pmix_util_keyval_yyleng; ++yyl )

I think you need to change the regular expression so that it matches the entire file name, not only a portion. I.e. in your example the .* is missing in the front

I believe had subsequently added that. as noted in this comment. If those expressions are not covering both relative and absolute, let me know what you think needs to be different about them.

Should I change the name of the 'pattern' box to 'regular expression'?

IMHO, yes. Maybe qualify it as a Java Regular Expression if they are different and for bonus points, point the Java Regular Expression text at a reference for what they are if you can.

Can we make any further progress here at getting the exclude functionality to work?  Is there any additional information I can provide?

I’m on vacation till end of October. Maybe you can try the gccmake parser in the meantime...

I have.  It doesn't seem to help.  Currently I am using:

recordIssues enabledForFailure: true,
 aggregatingResults: true,
 tools: [
 [tool: [$class: 'GnuMakeGcc']],
 [tool: [$class: 'CppCheck']],
 ],
 filters: [excludeFile('.*\\/_build\\.external\\/.*'),
 excludeFile('_build\\.external\\/.*')]
 }

at the end of my  parallel step which contains two builds, one each for CentOS and Ubuntu.

I am not using the gcc compilers on my own. I need to setup a test project that compiles some c files first. Do you have an example project? Or a link to a good OSS project that I can build locally in Jenkins?

Here's the project and branch/PR that I am reproducing these results in, complete with a  Jenkinsfile to build it.  It's probably more in-depth and complicated than you need, but you can strip back the parts you don't need easily enough.

Alternatively, I can provide you a Jenkins console log of a run of the above Jenkinsfile if that's useful and easier.

Are you asserting that JENKINS-14064 is why I cannot seem to exclude and entire directory's worth of files/warnings?

That issue seems quite old.  Is it ever going to be resolved?  Or is there any other kind of workaround I can use?

I don't think I am doing anything special/different.  Why isn't this affecting everyone using make and gcc?

Sorry, maybe I did not understand correctly. I thought the filter is now working as no file that contains build.external is in the report anymore. So this part of the problem is solved.

The remaining problem is: some files do not have an absolute path attached. This is something that needs to be checked (different issue but still an issue!). Why does your build produce a warning log that does not resolve all absolute filenames. This has been implemented for GCC and Make and should be pulled up for all make based parsers (JENKINS-14064).

In order to investigate that in more detail I need to analyze an actual GCC project (see your comment). I won't have time to start to work on this issue in the next time, first of all the 1.0 release needs to be finished.

Can I change the description so that it describes the missing absolute paths issue?

Ahhh.  So yes, maybe it is working now.  I was just seeing the same approximate (~700) number of files being identified and thinking it was the filtering.

Why does your build produce a warning log that does not resolve all absolute filenames

This I am not sure of. Our project is building a number of other projects/software packages under it's build, but those should pretty much all be standard Autotools/Make/GCC based projects.

Can I change the description so that it describes the missing absolute paths issue?

Absolutely. Whatever you need to help organise this and get it resolved.

If it is possible, please also attach one of your console log files, then I just can see if I can fix it without setting up a C project. (Or send it via mail if it contains sensible data.)

Build console log consoleText.txt has been attached.

Much thanks!

Was the console log I attached helpful?

Ping?

Sorry for the delay... Yes the log file is helpful, I can use it (or a snippet) to create a test case to fix the resolving of the names.

I'm still struggling with the 1.0 release so please be patient, I did not forget your issue. Just a lot of other things to do.