-
Notifications
You must be signed in to change notification settings - Fork 36
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
Reduces whitesource scan time #100
Conversation
Preventing Whitesource to resolve the dependencies through what they call 'the npm cycle', and enforcing to use our package-lock instead, reduces the build time. However, there seems to have bugs in the found dependencies (currently submitted to the support).
836e985
to
e134365
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@NSeydoux What was the solution to the bugs in the found dependencies? |
That's an excellent question. It seems that the I'll update the support ticket. |
Hmm, so you haven't heard back from Whitesource yet? Now that this is merged, it's blocking my other PR: https://github.com/inrupt/lit-solid/pull/81/checks?check_run_id=706413188 Shall we back this out until we have a fix? |
No, not yet. And I updated the branch protection rules so that the Whitesource CI check is not required anymore, so I don't think it should block other PRs. When I visit #81, I see the Whitesource scan fail, but it doesn't prevent merging. Do you have the same result ? |
Ah, right. Still feels kind sloppy to me that we have enabled a check that always fails - builds a culture of merging despite failures and overlooking warnings :/ |
I agree that this should be fixed as soon as possible: when the fix is in, I will re-enable this CI check to be mandatory. |
This PR fixes a whitesource CI bug, when whitesource takes up to 18minutes to run, mostly doing nothing/not showing what it does.
Preventing Whitesource to resolve the dependencies through what they call 'the npm cycle', and enforcing to use our package-lock instead, reduces the build time. However, there seems to have bugs in the found dependencies (currently submitted to the support).