CI/CD Pipeline Broken Due to --target Parameter Enforcement in Version 4.3.2

[adityasfdev]

Have you tried to resolve this issue yourself first?

Yes

Bug Description

• We are experiencing issues with the Salesforce Scanner plugin (version 4.3.2) in our CI/CD pipeline. The pipeline, which previously worked fine with version 4.3.0, is now failing due to the enforced requirement of the --target parameter to contain at least one file. - Our pipeline runs three separate commands to validate Apex classes, Aura components, and LWC components. This is necessary because we cannot predict which files a developer might commit. The enforced --target parameter now requires each command to include at least one file, causing the pipeline to break when there are no files in one or more of these components.

Pipeline Commands:

1. sfdx scanner:run --target "classes" --format json
2. sfdx scanner:run --target "aura" --format json
3. sfdx scanner:run --target "lwc" --format json

• Error (1): No files were found in the target. --target must contain at least one file.

Output / Logs

No response

Steps To Reproduce

1. Set up a CI/CD pipeline with the Salesforce Scanner plugin version 4.3.2.
2. Run the commands for each component (Apex classes, Aura components, LWC components) in the pipeline.
3. Ensure one or more of these components have no files.
4. Observe the error due to the --target parameter enforcement.

Expected Behavior

The commands should run successfully even if one or more components have no files, as it worked in version 4.3.0.

Operating System

ubuntu-latest in Azure pipeline

Salesforce CLI Version

@salesforce/cli/2.47.6 linux-x64 node-v18.20.3

Code Analyzer Plugin (@salesforce/sfdx-scanner) Version

v4.3.2

Additional Context (Screenshots, Files, etc)

No response

Workaround

As a temporary fix, we have downgraded the Salesforce Scanner plugin to version 4.3.0. This allows our pipeline to run successfully without requiring the --target parameter to contain at least one file.

Urgency

High

[stephen-carter-at-sf]

Thanks for letting us know. For now instead of moving back to 4.3.0, you can use the latest but specify your project directory --projectdir with your call to run. If it is just the present working directory, then use --projectdir .

We'll fix soon.

[adityasfdev]

Thanks for the quick update will try this --projectdir parameter in our command.

[git2gus]

This issue has been linked to a new work item: W-16162277

[stephen-carter-at-sf]

Since this only impacts users targeting empty files without supplying a --projectdir, we will not rush out a patch release for this fix. Instead, this fix will go out with out 4.4.0 release at the end of this month.

[rosangelys-pfm]

@adityasfdev
Hi, I faced the same problem, and as it is a high priority on my side because I am using the sfdx scanner in my CI/CD github pipeline for specific files I found this workaround:

Use the following extension to check the existence of the files in your workflow:
https://github.com/marketplace/actions/file-existence

This is how I use it:

1. Check in my changed-sources library if there are any .cls files changed (changed files provided by git-delta)
2. If I have .cls files changed, I will run the scanner other wise skip that step.

 # Check if cls files are present in the changed sources directory.
            - name: 'Check CLS file existence'
              id: check_files
              uses: andstor/file-existence-action@v3
              with:
                  files: 'changed-sources/**/*.cls'

            # The .xml file can later be uploaded to github, so that we can see the
            # results of the scan directly from the PR.
            - name: 'Scan code'
              id: scan-results
              if: steps.check_files.outputs.files_exists == 'true'
              run: |
                  cd changed-sources
                  sfdx scanner:run --format csv --target './**/*.cls' --severity-threshold 3 --outfile 'apexScanResults.csv'  
                  cd ..

[adityasfdev]

@rosangelys-pfm thanks for your help. but we are having some scripting tasks(which is sending an automated deployment status mail to the respective dev's outlook who committed those changes in git) which is running based upon the json results that we get from the scanner commands and that's where our pipeline is mainly got affected so if we start to use this then will have to change our entire workflow which is bit of headache for us.

[johnbelosf]

@rosangelys-pfm can you confirm that the above workaround works for you?

Thanks for letting us know. For now instead of moving back to 4.3.0, you can use the latest but specify your project directory --projectdir with your call to run. If it is just the present working directory, then use --projectdir .

[johnbelosf]

@adityasfdev were you able to use the above workaround?

[rosangelys-pfm]

@johnbelosf -- Could you post an example of how to use a specific target along with the --projectdir flag?

I am targeting this inside a directory (changed-sources) located at the root of my project. In order to do that I step my VM command line in the changed-sources dir before running the sfdx scanner:

- name: 'Scan code'
              id: scan-results
              if: steps.check_files.outputs.files_exists == 'true'
              run: |
                  cd changed-sources
                  sfdx scanner:run --format csv --target './**/*.cls' --severity-threshold 3 --outfile 'apexScanResults.csv'  
                  cd ..

can you confirm that the above workaround works for you?

Thanks for letting us know. For now instead of moving back to 4.3.0, you can use the latest but specify your project directory --projectdir with your call to run. If it is just the present working directory, then use --projectdir .

[adityasfdev]

@johnbelosf you can use projectdir parameter like this *** sf scanner run --projectdir src/ --target "/lwc/" --json *** and yes it is working for me.

[johnbelosf]

@rosangelys-pfm have you tried adding --projectdir . to your existing command?

[stephen-carter-at-sf]

@rosangelys-pfm The --projectdir is basically the folder that is the root directory of your project. It differs from the --target files in that the target files are the list of files within your project that you would like to specifically scan for violations.

With the run dfa command both have historically been needed because the Salesforce Graph Engine needs the entire context of the project in order to do its analysis - even if only a few files were targeted. But this typically has not been required for the run command since it typically can work at the file level instead of at the project level.

But we introduced a change with a recent patch (to allow code analyzer to run in jenkins environments) that required the projectdir information to be known also by the run command. This should have posed zero problems for users who have non-empty target folders because we auto calculate the projectdir to be the longest common parent of all the target files found. But when no target files exist, then we can't calculate projectdir. This is why the run dfa command always has given the error message requiring at least target file. But consequently this is where we accidentally introduced the breaking change.

The workaround is to simply for users to provide a --projectdir to the run command so that we don't attempt to calculate one on your behalf from the target files.

We are working to fix this and fully test this to be released at the end of the month because it is actually going to remove the error message from both the run command and the run dfa command. We prefer to avoid patch releases when a workaround exists and we would like to to do a full round of testing since we'll be introducing yet another behavior change.

So on behalf of the team, we apologize that we introduced this error message (behavior change) on this edge case and we thank you for your patience and understanding as you apply the workaround.

#1538 will contain the fix, but first I'm working to add in another test or two which we had missing before which considered the zero target file scenario.

[vkrishna01]

Hi @stephen-carter-at-sf , when is the issue expected to be resolved?

[jfeingold35]

@vkrishna01 , the fix has been merged into our dev branch, and it will be released in our v4.4.0 release, currently scheduled for July 30.

[stephen-carter-at-sf]

We have release v4.4.0 - For those of you who were impacted by this, you may now remove any workarounds you had in place and install the latest:

sf plugins install @salesforce/sfdx-scanner@latest