Once the promotion algorithm is implemented #195, we can fill in the promotion handlers by adapting the code currently used by the webhook server. The controller should record the fact of each promotion in the pipeline status so that it
does retry a promotion that failed; and,
doesn't retry a promotion that succeeded.
[ ] the webhook receivers should still work, but succeed trivially (i.e., no-op and return 200), so demos don't break immediately
[ ] test that promotions are triggered reliably; it's not a goal to prove that automated PRs work as expected, only that this code handles success and failures
not a goal to make promotion handling run asynchronously. In the reconcile loop is OK for now.
Once the promotion algorithm is implemented #195, we can fill in the promotion handlers by adapting the code currently used by the webhook server. The controller should record the fact of each promotion in the pipeline status so that it
does retry a promotion that failed; and,
doesn't retry a promotion that succeeded.
[ ] the webhook receivers should still work, but succeed trivially (i.e., no-op and return 200), so demos don't break immediately
[ ] test that promotions are triggered reliably; it's not a goal to prove that automated PRs work as expected, only that this code handles success and failures
not a goal to make promotion handling run asynchronously. In the reconcile loop is OK for now.