Pull request (GitHub) promotion mechanism

[jessesuen]

Today, we support a git promotion, which will make a commit directly to a branch, followed by the Argo CD sync.

We need to support a promotion that goes through GitOps PR approvals. So instead of doing a direct git commit, the promotion would:

1. Open a pull request against the branch
2. Wait for that PR to be merged or rejected
3. Fail the promotion if the PR was closed without merging
4. Otherwise, once merged, perform Argo CD sync

To start, we will support GitHub, with support for other git providers later.

[krancour]

with support for other git providers later.

If we don't highly prioritize those other providers, this might be a really good area to enlist help from the community.

[jessesuen]

@alexmt has questioned what it means for a promotion to be "long-lived". The PR use case is my rationale for the need for long-lived promotion. IMO, I think it's justification enough because the act of waiting for the PR to be merged, and syncing the app, is part of the overall promotion process. Also, with a fire-and-forget-based approach, I don't think we can effectively achieve the semantics of: only one promotion process should be happening at a time.

I think I am willing to cede that testing and analysis is something that probably should not be part of Promotion job (in favor of a more continuous approach), but I think the PR create + wait for merge is strong justification for a long-lived promotion job.

@alexmt - since you had ideas of something more event-driven (fire and forget). I will put the onus on you to describe how you propose the UX to be for the PR use case.

[krancour]

@jessesuen assigned to you because I think you were already working on this. Correct me if I am wrong.