Prevent manually created Freight from being auto-promoted

[aayushsrivastava]

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

When a user manually creates a Freight from "Freight Assembly", it should not be auto-promoted to the left-most Stage. Instead, the user should explicitly promote it to a Stage and then it can auto-promote downstream from there.

Disclaimer: Maybe I am using the features wrong and there are alternative ways of achieving this behavior, please point me in the right direction if that's the case.

Motivation

Consider this simple example where we are developing a pet store. The Warehouse has the following definition:

spec:
  freightCreationPolicy: Automatic
  interval: 5m0s
  subscriptions:
    - image:
        allowTags: v*
        discoveryLimit: 20
        imageSelectionStrategy: SemVer
        repoURL: registry.example.com/pet-store
        strictSemvers: true

The CI increments the minor version for any new change and Kargo auto-promotes it to the dev stage.

There is an issue in production for which the fix is available in version v0.2.1. Kargo doesn't automatically create a new Freight for this version, which is okay. When the user manually creates a Freight for a hotfix, this Freight is auto-promoted to dev.

This is not ideal because the user would have to manually restore the dev to v0.3.0. Normally, the user would simply manually approve this Freight for staging, promote it there, and then promote it to prod.

Suggested Implementation

We can introduce a flag in the Freight called isAutoPromotable. Stages will ignore any Freight with this flag set to false for auto-promotions.

Freight created from manual freight assembly will initially have this flag set to false. When the user explicitly promotes the Freight to any Stage, we can flip the flag to true so that the Freight can automatically flow downstream after the first manual promotion.

[krancour]

Thanks @aayushsrivastava. I understand your issue and completely agree there's room for improvement here. I'm not sure about the proposed implementation:

we can flip the flag to true so that the Freight can automatically flow downstream after the first manual promotion

Freight that are eligible for autopromotion to any Stage are the newest ones "available" to it. Availability is based a variety of factors. If that logic were updated to additionally factor in a switch that indicates something is not auto-promotable, the problem is that once you flip that switch, that logic will no longer prevent it from flowing into the Stages that you didn't want to have it.

So I definitely would like to do something about the issue you've raised, but think we need to iterate a bit more on exactly how to achieve it. We're certainly open to any other ideas you may have.

Note some small bit of overlap with https://github.com/akuity/kargo/issues/3016

It might be possible to solve both problems in tandem. Or it may not. I'm linking to it just so that we don't lose sight of the potential for it.

[aayushsrivastava]

the problem is that once you flip that switch, that logic will no longer prevent it from flowing into the Stages that you didn't want to have it.

Yeah, I realize now that flipping the switch upon manual promotion to staging can auto-promote it to the dev stage as well in the original example.

Freight that are eligible for autopromotion to any Stage are the newest ones "available" to it.

Maybe we treat the manually created Freight differently for the left-most stage (the one requesting it "directly" from a Warehouse).

Manually created Freight will not be "available" to any Stage to start with.

Manually created Freight is "available" to a later stage since it is manually approved (I am guessing manual approval and verification upstream are two of the factors that make a Freight "available").

PS: I haven't read the source code yet so my understanding of "availability" in this thread may be incomplete due to lossiness of English.

[krancour]

Maybe we treat the manually created Freight differently for the left-most stage (the one requesting it "directly" from a Warehouse).

I think that's an idea worth exploring.

[gueux]

Hi, all. I've also faced the same issue with auto-promoted freight for prod hotfixes.

As a workaround I tried to use 2 warehouses - one with FreightCreationPolicy = 'Auto' that directly promoted to Dev stage and another with FreightCreationPolicy = 'Manual', that allow me to manually create Freight on demand. But in this case promotion steps doesn't work correctly because of ambiguous image detection between warehouses. I know there is argument warehouse() that might be passed to imageFrom(), but the 'freight' context is missed for PromotionTemplate steps. So its not possible to determine which of Warehouse current promotion belongs to.

Wouldn't it be an good option to have a FreightCreationPolicy per Warehouse subscription, and not for the whole Warehouse? It allows users to have multiply Freight streams for the same source, but for different purposes (for auto-promotion and for manual creation as example).

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

[lantern-sam]

We also suffer from this issue. Similar to above it is when we want to create specific hotfixes for an environment like Prod. We have quite an involved deployment process and trying to put a prod image into our dev environment can fail and take a very long time for Argo to report it back as failed which locks things up for some time.

A solution that could be good, at least as a stop gap, is to have a property like autoPromoteManualFreights inside promotionPolicies. It defaults to true but you could turn it off for a specific stage. It's likely most people would find benefit doing this for the left-most stage but this at least leaves some choice for different people / different use-cases.

Example:

apiVersion: kargo.akuity.io/v1alpha1
kind: ProjectConfig
metadata:
  name: example
  namespace: example
spec:
  promotionPolicies:
  - stageSelector:
      name: test
    autoPromotionEnabled: true
    autoPromoteManualFreights: false
- stageSelector:
      name: prod

You could then apply a k8s label (or similar) to tag any manually assembled freights and then each stage can take action / ignore based on that label.

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

[Michael-Wilson94]

Just wanted to bump this one - this is still a really useful and relevant feature request for teams managing multi-stage deployments.

Our use case is similar to what @lantern-sam described: we occasionally need to manually promote specific freights (like production hotfixes) without triggering downstream environments, and having a property like autoPromoteManualFreights would make this far cleaner than the current workarounds.

Would it be possible to remove the stale label and keep this issue open for consideration? Thanks!