-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
--failon command does not return status 1 #71
Comments
For reference - my gitlab pipeline looks like this: ####################################################
# The docker image the jobs initialize with.
# We use nodejs, so a node image makes sense.
# https://docs.gitlab.com/ee/ci/yaml/README.html#image
####################################################
image: "node:latest"
####################################################
# The sequential stages of this pipeline.
# Jobs within a stage run in parallel.
# https://docs.gitlab.com/ee/ci/yaml/README.html#stages
####################################################
stages:
- metadata_scan
- apex_scan
####################################################
# Metadata Scanning Phase
####################################################
metadata_scan:
stage: metadata_scan
allow_failure: false
script:
- install_salesforce_cli
- install_lightning_flow_scanner
- scan_metadata
artifacts:
paths:
- metadata-scan-files/
when: always
####################################################
# Helper Methods
####################################################
.sf_helpers: &sf_helpers |
function install_salesforce_cli() {
# Salesforce CLI Environment Variables
# https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_cli_env_variables.htm
# By default, the CLI periodically checks for and installs updates.
# Disable (false) this auto-update check to improve performance of CLI commands.
export SF_AUTOUPDATE_DISABLE=false
# Set to true if you want to use the generic UNIX keychain instead of the Linux libsecret library or macOS keychain.
# Specify this variable when using the CLI with ssh or "headless" in a CI environment.
export SF_USE_GENERIC_UNIX_KEYCHAIN=true
# For force:package:version:create, disables automatic updates to the sfdx-project.json file.
export SF_PROJECT_AUTOUPDATE_DISABLE_FOR_PACKAGE_VERSION_CREATE=true
# Install Salesforce CLI
npm install @salesforce/cli --global
# Output CLI version and plug-in information
sf update
sf --version
sf plugins --core
}
#Install the flow scanner plugin - it is not digitally signed so we need to echo y to accept the prompt.
function install_lightning_flow_scanner() {
echo 'y' | sf plugins:install lightning-flow-scanner
}
# Function to run the metadata scan on the current branch
function scan_metadata() {
local OUTPUT_DIRECTORY=metadata-scan-files
mkdir -p $OUTPUT_DIRECTORY
sf flow:scan --failon error --config "scanner-config.json"
} |
thank you for reporting this. First of all, I think it would be -failon "error" instead of -failon error.(not sure if that makes a difference) I am wondering however, if you don't use failing it is error level by default as per my understanding. so in this case you don't need the argument, although it should work ofcoùrse. what are you trying to achieve with the failon argument specifically? |
Hey @RubenHalman ! I think I just put it because the documentation didn't specify if it was required for throwing a non-zero status code or not. It seems that even without the --failon flag, it still returns a status code of 1 (success). I also tried -failon "error", but no dice, it did not give me any errors however, so I guess it is an accepted param. |
I am sorry. Can you show the --JSON output? |
Sure thing
Interestingly, I can see the status here for each error, but it does not seem to exit the oclif process with the exit code - it seems possible based on a quick look here |
I probably need some input from @nvuillam here. Before v2, the core module threw an error resulting in an exit code, but it malformed the json. So I believe we changed it so the json is valid so it can be used for automation, but this is not really my expertise and requires a further deep dive |
@RubenHalman @SFDX-Sam sorry for the delay (vacations ^^), this issue should be solved in #72 :) |
Thanks both! |
Hello ! I am still having the same issue, either calling I am also using the last version
This is the response (it includes errors):
|
Hmmm it was supposed to be solved :( |
Thanks |
No pressure but do you have any idea on when this will be solved ? We are forced to stop using this fantastic tool in our CI because of this error |
@jorgesolebur Im sorry. I have don't understand how this parameter is supposed to be working. Im waiting for@nvuillam or someone to explain this to me so I can implement a fix! |
@nvuillam Please do not hesitate to details on how this works! From my understand, this issue is somehow related to #65, because if there is at least an error in the JSON output summary then the command should fail (returning error code 1). If the JSON output summary called "errors" = 0, then the command should return error code 0. |
I'll try to fix that this weekend:) |
@nvuillam Thanks. I am confused how the error level should impact the exit status. |
I think I found a fix :) |
My apologies for the delay on publishing these changes. It should now be resolved with the latest version thanks to Nicolas efforts. Thank you very much for your involvement @SFDX-Sam, @jorgesolebur @nvuillam |
Thanks! Let me test that! I will be very happy to be able to enable again this automation in my pipeline :-) will keep you posted! |
@jorgesolebur I integrated Flow Scanner within MegaLinter (it is still in the beta version) , and it requires exit code > 0 in case of errors, so it should work on your side too :) |
@nvuillam Maybe I am missing something, but I am trying to execute the following command: Which would mean that I only want the above command to return status 1 if they find any violation defined with a severity 'error'. I have defined in my config json file all rules with a severity warning:
When executing the above command, it is returning a status code 1. This is not consistent because the scan found 2 violations that had a severity warning. The scan did not find any violation with severity = error:
Does it make sense ? Shall I crate a new issue ? |
@jorgesolebur Thank you very much for your input and im sorry for my limited involvement in this matter. I believe I have now resolved this issue with 2.16, but if you would be so kind to have a look I would greatly appreciate it. |
Thanks! Will test it out soon |
It is working now, thanks ! |
@jorgesolebur thank you so much for your patience and involvement. we will have a look at that ticket ASAP. |
Good evening! I've implemented flow scanner on both a gitlab pipeline and my local windows machine, and I cannot get the scanner to return a status code of 1 when using the --failon command.
I run the following command:
sf flow:scan --failon error --config "scanner-config.json"
And it returns:
But does not seem to throw a status code of 1 - I have tried reducing the loglevel down to warning but still no luck.
The text was updated successfully, but these errors were encountered: