-
Notifications
You must be signed in to change notification settings - Fork 5
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
refactor: use reusable workflow for semgrep #311
refactor: use reusable workflow for semgrep #311
Conversation
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.
Regarding GHAS and failing job when blocking issues are found - let's postpone on that once we figure out possible solutions.
@pawel-dabro are you also fine with releasing this change?
edit: @dvarasani-crest please extend description of the PR with issues with triggering true positives and limitations of failing job that you faced
This error was observed when I tried to add |
@kdoroszko-splunk It's strange that this issue is reported there; Just to be sure I triggered another wf and looks good: |
🎉 This PR is included in version 4.17.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Updated the build-test-release workflow to use sast-scan owned by product security team instead of using custom implementation.
Ref: https://splunk.atlassian.net/browse/ADDON-72309
Test workflow run: https://github.com/splunk/splunk-add-on-for-servicenow/actions/runs/10596615468
Tested on PR: https://github.com/splunk/splunk-add-on-for-servicenow/pull/751
Workflow is not tested for the failure scenario because we need to have blocker findings by the semgrep in order to fail the workflow. Currently all rules are in monitor mode so any findings by the semgrep will be non-blocker resulting in semgrep stage to pass everytime.
Discussion with the semgrep team: https://splunk.slack.com/archives/C011ELTV7FG/p1724923496371529