-
Notifications
You must be signed in to change notification settings - Fork 197
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
Disable CodeQL from pipeline level and add it in job level #2698
Conversation
tools/yaml-templates/ios-test.yml
Outdated
@@ -87,6 +87,13 @@ steps: | |||
script: 'nohup pnpm start-test-app --server-options-cert $(localhostSSLCertificate.secureFilePath) --server-options-key $(localhostSSLKey.secureFilePath) &' | |||
workingDirectory: '$(ClientSdkProjectDirectory)' | |||
|
|||
- task: CodeQL3000Init@0 | |||
inputs: | |||
${{ if eq(variables['Build.SourceBranch'], 'refs/heads/main') }}: |
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.
According to codeQL, it should only run default branch (master or main)
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.
I don't mind setting it explicitly but I think codeQL by default checks branch. That is to say, in your branch, codeQL would not be triggered (because it isn't running on main) maybe and this inputs setting can be saved?
Also I cannot think of other way we can do something except checking this in and then monitor main branch to see if it fails or not. Hopefully it is not.
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.
CodeQL will by default check for changes to main
. Using the inputs tag here is to add additional branches. I would recommend modifying this to look for both main
and release/*
branches instead of just main.
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.
ok, I think you guys have a point and I also observed the skipping of run on non-default branch. Let me remove it since it doesn't seem doing anything better.
To clarify my understanding, we will still be running codeQL, just at a later point in the pipeline? Will this have any impacts on its scanning capabilities? |
azure-pipelines.yml
Outdated
codeql: | ||
compiled: | ||
enabled: false | ||
justificationForDisabling: 'CodeQL has some know issues with arm64 macos. Disabling auto-injection and using manual task' |
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.
nit: known
@noahdarveau-MSFT , this is a really good question, and also the core of changes. I have added some details in the PR description, let me see if I can add more details.
Down there there is "CodeQL3000Init@0" task, which is the manual task we are adding now, to ensure the coverage.
This ensures the scan coverage, without interferring other stages. As a comparsion of how auto-injected task works, 1ES template always injects at very beginning of the job, which we don't have control. So you can image the order is something like below. So any tasks/tool setting up between "CodeQL init" and "CodeQL Finalize", can be interfered by CodeQL in an unexpected way. This is also the reason why we see intermittent failure.
|
For more information about how to contribute to this repo, visit this page.
Description
What is codeql, and what the persistent issues it has currently?
From what I understand in a briefly way, it is static analysis tool, runs on source codes for all kind of languages, and also traces the build process during to build, to capture any security vulnerability issues. It creates a DB during its run, which I believe records the scan result, and the DB will be uploaded in the pipeline to be source of different reporting/dashboards.
CodeQL currently has some issues arm64 macos image, which has been known for a while and in the back of codeQL team. This is not super clear what is the issues to me, and there is an existing ICM on codeql
When it runs in 1ES template?
CodeQL is injected task if the pipeline is on 1ES template. From our observations, 1ES always injects the run at the beginning of each task, i.e, before it runs any other tasks like tool installing. When the tool is installing, it may be interferred with codeql, causing the failure (Not exactly know the reason)
How manual run is different from codeql auto-injection task?
There is no difference between auto-injected codeQL and manual codeQL task themselves. The only difference is with manual, we/our team can decide when to inject. The workaround is to inject after the tool setup has completed, to let codeql have less interruptions with the build process. A recommended order from CodeQL team:
What is our solution here?
Disable from pipeline level, and then add manual task at each job level. Please note, Codeql doesn't support job level disable as of today, so in order to disable, we have to do it at pipeline level.
Will we receive the S360 alerts?
Given we are disabling the CodeQL at pipeline/repo level. Will we receive S360 alerts?
The answer should be No. We have confirmed with CodeQL team. As long as DB is uploaded, S360 will have some results to process, meeting the requirement. It doesn’t track where the DB is created (from 1ES template, or manual run doesn't matter)
Main changes in the PR:
Validation
Validation performed:
Unit Tests added:
<Yes/No>
End-to-end tests added:
<Yes/No>
Additional Requirements
Change file added:
<Yes/No>
Related PRs:
Next/remaining steps:
Screenshots: