Broken logic for pull request statuses in PR resource

[afrittoli]

Expected Behavior

When a check is updated in the PR pipeline resource, the corresponding check should be updated on github side.

Actual Behavior

The update may happen or not depending on the case.

Additional Info

The code in

pipeline/pkg/pullrequest/api.go

Lines 275 to 278 in 8f427a8

	csMap := map[string]scm.State{}
	for _, s := range cs {
	csMap[s.Label] = s.State
	}

makes the assumption that the label, or context in case of GitHiub, is a unique key to identify a "check". That is not the case for GitHub - the API model maintains a list of checks, which may have the same context, but different state and id.

The reason why this issue happens is that in some cases the code in the pullrequest/api packages makes a map of the checks based on the label, so the stated stored in the map may be that of any of the status available.

Even if it was considered responsibility of the CI system to manage these multiple states, the pull request resource does not make that possible by hiding the check id away.

When a process in the CI system sends an update to a status, it should get back the ID from github. That ID can then be used by the CI system to update the correct status once the CI job is complete.

Unfortunately the GitHub API docs don't really explain more in which cases a new status is created even if one exists already with the same name. It might be that that happens every time an update is sent without the ID. Or it may be that the API allows for multiple statues against the same job to allow for parallel checks. I would say the former is more likely, but I struggle to understand how we could end up then with 7 different IDs for the same context like in the example from the gist.

[vdemeester]

/kind bug

[afrittoli]

https://github.community/t5/GitHub-API-Development-and/Is-there-a-way-to-delete-a-GitHub-commit-Status-via-the-API/td-p/28778