Confusion around Promotion Gating and CommitStatus

[dsiebel]

We are currently evaluating gitops-promoter to augment our CD workflow based on Skaffold and pre-rendered manifests (hydration). This tool looked really promising as it fit our vision of a CD process with promotion pretty much.
There is one thing we don't quite understand around promotion gating, hence this discussion / question:
How are commit statuses supposed to work in promotion gating?
I understand that, in order for them to gate promotions in a PromotionStrategy we need to place actual CommitStatus resources into the cluster which, depending on the SCM provider, in our case GitHub, get posted to the API and show up on the commits as well.
Is that understanding correct?

If so: how would we go about publishing existing GitHub Actions checks? If we were to create a provider for that, gitops-promoter would again publish them to the same commit, which would leave us with two checks doing the same thing, right?

Our idea was that we would use our existing GitHub Actions workflows to run all sorts of tests once the promotion to e.g. staging is done. These checks could be integration test, smoke tests and alike. We would like these checks to end up as CommitStatus in the cluster so we can use them in our PromotionStrategy configurations.

Is this feasible?
Are there any plans for the controller to automatically publish commit status from the SCM provider?

We would love to hear your thoughts on this.

[zachaller]

You can actually do just that, as long as you configure the repo so the checks are required you don't even have to inform the promoter of the checks because the promoter can not override the required checks.

There are some nice things though about having github only checks registered as commit status k8s resources and we have briefly talked about creating a controller to do just that query github and copy the checks configured there into commit statuses but we haven't spent a lot of time thinking about it either.

[dsiebel]

Thanks for getting back to me.
We already played around with required checks on the promotion PRs using pull_request_target triggers. They kind-of work okay, but from promoter perspective it wasn't as transparent as having the commit status resources in-cluster. Looking at the resources' status didn't give any clue as to why a PR wasn't being merged.
We're looking forward to what might be coming in the future in this area or even contribute a feature like this, if deemed useful.

[crenshaw-dev]

@dsiebel wanna open an enhancement request? I think we could call the feature something like ReflectionCommitStatusController.

[dsiebel]

Sure!
By "enhancement request" you mean a GitHub issue?

[crenshaw-dev]

Yep!