Closed amfred closed 3 years ago
Re: vulnerableCheckRunConclusionLevel
, do you know where that original value of "false" came from? When I look at the documentation it indicates that the default value is "failure", not "false".
In theory with displayMode=diff it should only fail a branch/PR if it increases vulnerabilities compared to the base branch, which is what I'd recommend. But if you are looking for a short term workaround to be able to merge then setting it to "success" could be good, but don't forget about it.
Next topic: if you look at the docs for config:base
you can see that group:monorepos
and group:recommended
are both included already, so there is no need to add them to your extends
array if you already have config:base
.
Finally back to the original question: no PRs.
Just so you know, WhiteSource for Developers (W4D), which I believe you're running, includes three components: the controller, the vulnerability scanner, and Remediate/Renovate combined. The controller is responsible for creating issues that are found by the vulnerability scanner, and not Remediate. So for example if you are seeing issues and not PRs then it's even possible that you don't have Remediate running at all.
I'd suggest:
The default INFO logs may be enough to advise if there's some catastrophic failure causing it to fail, but usually for smaller failures it's necessary to add LOG_LEVEL=debug
to the containers environment so that it logs at a debug level.
On a side note, I edited your title/description a little for readability. You might be interested in how to use the code block feature yourself: https://docs.github.com/en/github/writing-on-github/creating-and-highlighting-code-blocks
The example I worked from had "vulnerableCheckRunConclusionLevel": "false", instead of "vulnerableCheckRunConclusionLevel": "failure",
I'm not sure if that had something to do with it.
I'm not sure it would explain everything, but it could explain something. At the very least, please re-test with "failure"
to confirm if anything changes. Also if that example came from any of our documentation then please make sure I or someone at WS knows to fix it.
I made sure the documentation I used (it was internal documentation) was corrected to say "failure" instead of "false". Now I am able to merge PRs even if the whitesource check fails, so that's a start.
I'm going to try that today and then see if we can get some issues created... I'll check back.
I have this enabled on a few repos now, but we haven't had any new vulnerabilities in the past few days, so I'm just waiting to see if I get PRs or issues.
Make sure you have set up the workflow rule for Remediate also: https://whitesource.atlassian.net/wiki/spaces/WD/pages/710444101/WhiteSource+Remediate#WhiteSourceRemediate-WhiteSourceWorkflowRules
I enabled Renovate on a repo where Whitesource is running, but it's only opening issues and not pull requests. What are the conditions that must be met to open PRs (and fewer of them) instead of issues?
For reference, the project started out as a fork of: https://github.com/carbon-design-system/gatsby-starter-carbon-theme But we're using Yarn, so there's a yarn.lock file.
The .whitesource config file was like this when it opened the issues:
It opened dozens of issues, so my next proposed change is to try to get it to be less annoying by changing the .whitesource file to this:
Unfortunately it won't let me merge that PR, because the Whitesource check is still failing when I re-run it. Arg. Do I need to force-push the PR to get the "vulnerableCheckRunConclusionLevel": "success" flag to take effect?
Sorry, I guess that's two problems in one issue, but it's gotten me into a bit of a catch-22.