rudymatela
commented
2 years ago @FPtje This is a fix for the multiple-comment issue you and Bert reported yesterday. Can you please review when you have the time?
GitHub's documentation isn't super clear of what's the criteria for including the branch in the branches list: https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#status. Here's what it says:
"An array of branch objects containing the status' SHA. Each branch contains the given SHA, but the SHA may or may not be the head of the branch. The array includes a maximum of 10 branches."
If that's true in the most straightforward interpretation, there is no way to actually identify the "canonical" build for a sha in a branch! In this PR I assume the list only includes the branches for which the build refers to (this would make more sense). In the case of Semaphore, there can be multiple builds for the same commit sha if they are on different branches.
My plan is to see in practice what happens after we deploy this change:
- if it only includes the relevant branch, the issue is fixed;
- if it includes all branches containing the sha (even those that do not refer to the build, the issue will still be present, but Hoff will continue working "as-is".
In case of "2.", I will have to prepare a second PR where different URLs for the same SHA are simply ignored. This will make Hoff "internally inconsistent" but at least we will not get duplicate comments. Either way, we will get a clarification of what exactly GitHub does because the webhook PR branches will be logged.
FPtje
OpsBotPrime
closes: #147
If there are two builds on different branches but with the same hash, GitHub reports these at least twice! (Once per branch.) This makes it so that we only consider build status changes on the actual relevant testing branch. There's a detailed explanation here.