Having a separate /cancel endpoint … I’m not convinced
I agree, I’m not asking for both /cancel and /abort. We need one though, regardless of what it’s called. There are different use cases for why builds are aborted, lumping them all together isn’t helpful.
I can’t see a meaningful difference between aborting and canceling a build if done through the API,
These builds shouldn’t even be making it to bitrise. When there are no code changes, a build should not be triggered in the first place. The hack of doing git change detection is just a work around for lack of first class mono repo suppport.
if you have a use case where aborted vs canceled builds might be a useful distinction just let me know!
If we are cancelling a build because there are no code changes vs aborting a build manually on the UI, that’s important info to have.
I don’t think having multiple endpoints for “finishing builds early” is a good idea,
I’m not asking for multiple endpoints. Sorry that wasn’t clear. I’m asking for a differentation between build states. Using a magic string in “abort reason” seems like it’d work but isn’t ideal.