Support for no change promotions.

[shabbir-saifee-cmm]

Checklist

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

Proposed Feature

Support for no change promotions.

Motivation

We have this setup where our freight comprises of three artifacts (Image, Helm chart, helm values per environment)

So in some cases we have a freight that essentially has no change in a stage, for example staging. This happens where there is no image update, helm chart update, but the only update is in helm values for a different environment. In these cases we'd like to promote the freight in the upstream stage, but there wont be any changes or prs made.

I tried to compare the commit from git clone step with the new git commit step but unfortunately git clone has no outputs so we can get the commit id that was cloned.

This is one of the ways we are looking to solve for promoting the config files/helm values for our charts.

Suggested Implementation

Simplest way would be to add outputs to git clone where we can read the commit id and other details that was cloned.

[WZHGAHO]

Hi @shabbir-saifee-cmm , we workaround this by using copy promotion step to copy a promotion details yaml template file with placeholder values, and then we fill the promotion details yaml file with information using yaml-update step, and we use a timestamp key where the value is used as ${{ now() }} expression language date function. By this way, we always have a change what we can promote.

[krancour]

If most changes are ones that need to roll through all Stages and it's a relatively uncommon occurrence that Stage-specific configuration changes, I tend to just live with the reality that (for instance) something might pass through "dev" on its way to "qa" and might have no real effect on "dev".

If changes to Stage-specific configuration are a more frequent occurrence, you can use a variation of this pattern to give each Stage its own, dedicated Warehouse that's watching Stage-specific configuration only. (While the main Warehouse entirely ignores Stage-specific configurations.)

Separately, there are quite a number of otherwise unrelated issues open right now that would grant more fine grained control over (auto-)promotion policies and/or conditional execution of promotion steps or even entire promotions with a greater variety of outcomes than just success/failure supported. I would anticipate it being easy in the relatively near future to use expressions to dynamically block an auto-promotion or to permit it, but short-circuit if it's determined the promotion has no effect on the Stage -- something like, "let's not, but say we did," so that Freight can, for instance, flow through to "qa" without ever being promoted to "dev" first.

[shabbir-saifee-cmm]

Thanks! Gives something to think about but we may wait for new updates. Another question I had was is there any plan to add custom steps as part of promotion? It can be really useful if there is some custom logic that needs to execute as part of promotion.

[shabbir-saifee-cmm]

Hi @shabbir-saifee-cmm , we workaround this by using copy promotion step to copy a promotion details yaml template file with placeholder values, and then we fill the promotion details yaml file with information using yaml-update step, and we use a timestamp key where the value is used as ${{ now() }} expression language date function. By this way, we always have a change what we can promote.

Perfect. I wrote my own help-pull to get the helm charts in the freight coming from oci repos. These charts contain all the environment specific config as well so anytime there is an env specific change, we can update the value and increment helm version. And then did what you suggested. Having a promotion-details.yaml file that has date, chart and image version and date always gets updated. So in case of no-op change for an evnrionment it is still promotable

[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.