-
Notifications
You must be signed in to change notification settings - Fork 7
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
Add fuzz target bucketization, more jobs #64
Conversation
eng/pipelines/jobs/fuzz.yml
Outdated
go run . -v -fuzztime ${{ parameters.fuzztime }} | ||
$(cdFuzzCrypto) | ||
go env | ||
$(setExperiment)${{ parameters.goExperiment }} |
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.
Could we use AzDO env
instad of setting the experiment via bash or cmd notation?
Lik this:
- script: |
go env
go run ...
displayName: Fuzz
env: ${{ parameters.goExperiment }}
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.
True. Also workingDirectory
to get rid of the other variable.
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.
Ah right, env
entries don't show up in the build logs. 😬 I usually stick with scripts with set -x
for reproducibility/comprehensibility. (Although only on Linux.)
In this case env
is perfectly fine because go env
prints out the value anyway.
Co-authored-by: Quim Muntal <qmuntaldiaz@microsoft.com>
We aren't sure we have enough fuzz time with one agent running through each target sequentially over an hour, so this PR distributes the targets between several jobs. (#63 (comment))
Distributing the targets between agents is generally more effective than running every target on multiple agents because Go fuzz testing builds up a local cache of interesting data points that it uses to refine its search for issues, guided by coverage.
This PR doesn't fix the existing issues we've been having with memory usage. These seem to actually be issues in the code under test, not the infra, so we can/will fix these as followup and hopefully end up with green fuzz test runs.
Test build I triggered: https://dev.azure.com/dnceng/internal/_build/results?buildId=2002188&view=results