-
Notifications
You must be signed in to change notification settings - Fork 212
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
test: detect regressions with build performance program #4973
base: master
Are you sure you want to change the base?
Conversation
Pull Request Test Coverage Report for Build 11297674229Details
💛 - Coveralls |
go.sum
Outdated
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.
On the master branch, these mods are still listed but have yellow squiggly marks, citing that they are no longer needed. I ran go mod tidy in the overall directory and now can't get them back in the go sum because they automatically disappear. Are we keeping them around for some reason?
vhdbuilder/packer/buildperformance/evaluate-build-performance.sh
Outdated
Show resolved
Hide resolved
f5f8f7c
to
7ddf5a8
Compare
5ecf3b4
to
34e5a8d
Compare
601ea45
to
b6a430f
Compare
729eb93
to
743f94c
Compare
What type of PR is this?
/kind test
What this PR does / why we need it:
This PR does the following:
metric
Which issue(s) this PR fixes:
This PR will prevent VHD Build time regression by notifying software engineers of their code changes effect on VHD build times. Additionally, it can illuminate problem areas in the build when retry logic is causing the build to take longer than expected.
Requirements:
Reviewer Notes:
Open to any suggestions related to testing and error handling specifically, as I would like this program to be as robust as possible. Currently, I am wrapping all errors and sending them back to main.
Kusto functions are not currently tested because they are just wrappers around the go SDK functions to keep main clean and readable.
Once code is approved, I will create a new cluster and change a couple variables as I am currently only using a dev/test kusto instance. After that I will merge the code.