Add option for PR based promotion to support to PRs per commit?

[zbialik]

Checklist

• [x] I've searched the issue queue to verify this is not a duplicate feature request.
• [x] I've pasted the output of kargo version, if applicable.
• [x] I've pasted logs, if applicable.

Proposed Feature

I'd like Kargo to have the ability to setup multiple github PRs per commit made to repo. I'm also curious to know what others think of this so feel free to debate as maybe there's another use-case that fits what I'm trying to do better. More information in the next section...

Motivation

I am looking to use Kargo to streamline upgrade maintenance of my core k8s applications in a production env (e.g. prometheus, ingress-nginx, etc.). For production, I want to guardrail changes with PR's, which I think Kargo should be able to create for me.

I have the following setup:

• a gitops repo with the following branches:
  • main
    • umbrella chart pattern (e.g. /node-exporter/Chart.yaml in repo which points at upstream prometheus-node-exporter chart version)
    • Kargo controls these chartVersions
  • homelab-staging
    • plain text manifests that are generated as part of Github Actions (CI) when commit is made to main branch (e.g. bumping node-exporter chartVersion in umbrella pattern).
    • Github Actions auto-maintains these manifests when commits are made to main
  • homelab
    • plain text manifests that are actually deployed to production env (this is the branch I have Kargo creating PRs to)
    • Kargo auto-creates PRs to this repo when commits are made to homelab-staging

I realize this might not be possible, but I was wondering if we can have Kargo setup PRs per commit so that I can have multiple PRs open when multiple commits are made to homelab-staging before merging the original PR that Kargo created. The reason is because if we're lagging behind in merging PRs for upgrades, I don't want to have to perform the minor upgrades 1 at a time -- I'd rather jump straight to the latest patch version available. I can't do this using the current PR promotion mechanism.

I like the PR based approach because I can easily see what will change in my production env upon merge.

Suggested Implementation

I'm not sure. This might not even fit the initial use-cases for Kargo, but figured I'd ask anyway :)

[zbialik]

I think one approach would be to be able to templatize the writeBranch for the commits made during a Promotion.

[krancour]

@zbialik before I try to wrap my head around what you're requesting, I want to take a step back and try to understand the motivations a little bit better.

Specifically, I am wondering why you are using github actions to render manifests from main into homelab-staging when that's something that Kargo can easily do. (And which you are using Kargo for for homelab.)

i.e. you're building half your pipeline with GH actions and half of it with Kargo. It seems things would be quite a bit less complex if you used Kargo for the entire pipeline instead, no?

[github-actions[bot]]

This issue has been automatically marked as stale because it had no activity for 90 days. It will be closed if no activity occurs in the next 30 days but can be reopened if it becomes relevant again.