Stabilize integration-test-result placement via filtering by external_id

[michaelfig]

This PR makes integration-test-result consistently placed as Integration tests / integration-test-result):

Past runs without this PR's changes have random placement of integration-test-result (a data race while creating checks that's really easy to lose):

• ci(mergify): upgrade configuration to current format #26 Normal tests / integration-test-result:
  

• feat(cosmos): IBCPacket type that round-trips to JS agoric-sdk#11209 Pre-merge checks / integration-test-result:
  

• feat(swingset-liveslots): Support adding optional top-level fields to stateShape records agoric-sdk#11216 Test Golang / integration-test-result
  

• ci(mergify): upgrade configuration to current format agoric-sdk#11188 Protobuf / integration-test-result
  

[michaelfig]

@mhofman, I accidentally merged this PR!

Feel free to revert if it's interfering with the repo... I mainly just wanted to get your feedback on it (and yours, too @frazarshad, since you appear to be doing CI tweaks as well) before proposing similar changes in a PR for Agoric SDK.

[mhofman]

This PR makes integration-test-result consistently placed as Integration tests / integration-test-result):

This would be great, but afaik, this is not something we get to control. I don't understand how this PR would do that?

[mhofman]

Feel free to revert if it's interfering with the repo...

Yeah we should revert and reproduce the issue here if you believe this is a fix.

I think we may need to create a few other workflows in this repo, see on which ones the "result" check attaches to.

My understanding is that there is no way to control which "check suite" a check run created through the API ends up attached to: https://docs.github.com/en/rest/checks/runs?apiVersion=2022-11-28#create-a-check-run

[mhofman]

This answers confirms there is no way to specify the suite: https://github.com/orgs/community/discussions/24616#discussioncomment-3244677

[michaelfig]

This PR makes integration-test-result consistently placed as Integration tests / integration-test-result):

This would be great, but afaik, this is not something we get to control. I don't understand how this PR would do that?

there is no way to specify the suite

Correct, but we can create and query by the external_id (embedding a run number and an attempt number in that ID to ensure we're not getting unrelated attempts when we query for it).

We had nearly all the ingredients; the old code does its best to propagate and limit the checks query to a specific external_id, which should attach the check to a specific workflow run. Turns out, upon rereading the octokit docs for github.rest.checks.listForRef, I had misunderstood its arguments (specifying the external_id as a property in the listForRef had no effect).

When digging deeper, that query was not filtering by external_id, and so I needed to filter the returned runs by it afterward. That worked.

Without that explicit filter, we'd get the newest check to update, but no guarantee that the check was the one we had stamped with the external_id.

[michaelfig]

Feel free to revert if it's interfering with the repo...

Yeah we should revert and reproduce the issue here if you believe this is a fix.

I did reproduce it, in the multiple runs on this PR, as well as by investigating other green PRs in this repro.

After this PR, there is no instability.

I think we may need to create a few other workflows in this repo, see on which ones the "result" check attaches to.

We have other workflows, and without this PR, it reproduces as unstable.

My understanding is that there is no way to control which "check suite" a check run created through the API ends up attached to: https://docs.github.com/en/rest/checks/runs?apiVersion=2022-11-28#create-a-check-run

I'm not creating a check in an explicit "check suite". I'm creating it in an explicit "workflow run".