-
Notifications
You must be signed in to change notification settings - Fork 13
Refactor build queueing, add new perf pipeline under new name #29
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
Conversation
|
PR is not quite right; the old perf builds should be running in a specific pool so I have to figure out if the new API supports that. Maybe it doesn't matter and I can just stick my new perf change into this PR. |
|
Yeah, seems like you can't set the build queue in this new API. I guess I'll either have to revert this and make it able to use both APIs, or just bite the bullet and put my new change in here with the assumption that we'll never need to specify a queue again. |
|
Is this ready to review now? |
|
Yes, after one change I just pushed. |
|
I'd recommend reading the diff without whitespace: https://github.com/microsoft/typescript-bot-test-triggerer/pull/29/files?w=1 |
This changes the code to use the new pipelines run API rather than the old build queueing API. The new API gets rid of the wart that required parameters be stored as strings (my favorite comment, "This API is real bad") in favor of an object. The downside is that they haven't exposed this API directly in the Node client yet (microsoft/azure-devops-node-api#519), but it wasn't hard to figure out via watching the UI requests and reading the Go API client which does support this API.This allows allow me to change the perf run tasks to specify the new pipeline and use new repo resources (which I've chosen over what typescript-error-deltas does via a param as it works better in the UI; we could change the error deltas pipelines at some point too).From what I can tell, the new API should still work on the old builds; I tested a few by hand and they worked, but it's a little hard to tell for the old-style UI pipelines which don't exactly have a "real" parameters set. I'm going to try and double check for each of these, though.This PR has changed since I sent it, but it effectively abstracts away the pipeline/build triggering sep a bit, leaving the original ones unchanged, and adds a new pipeline trigger for the new perf stuff, which will eventually just replace the old one.