Feat: Provide support for multiple configure workflows

[SaphMB]

At present, Promise writers can only write a single configure workflow for their Promise or Resource Request. The workflows.configure key already takes a list of Pipelines to execute but at present, Kratix only selects the first one and executes it.

Expectation: The Pipelines run in the order they are specified

Given a Promise or Resource Request has the following specification:

workflows:
    resource/promise:
      configure:
      - apiVersion: platform.kratix.io/v1alpha1
        kind: Pipeline
        metadata:
          name: configure-a
          namespace: default
        spec:
          containers:
          - image: ghcr.io/syntasso/kratix-marketplace/a-configure-pipeline:v0.1.0
            name: configure-a-pipeline
      - apiVersion: platform.kratix.io/v1alpha1
        kind: Pipeline
        metadata:
          name: configure-b
          namespace: default
        spec:
          containers:
          - image: ghcr.io/syntasso/kratix-marketplace/b-configure-pipeline:v0.1.0
            name: configure-b-pipeline

When the Configure Workflow runs, the configure-a Pipeline will run and upon it's completion (as indicated by the status), the configure-b Pipeline will run.

Expectation: The Pipelines infer completion from the Pipeline status

Given the above Configure Workflow When configure-a runs, configure-b will identify that it has completed via the Pipeline status

[aclevername]

Once finishd lets look into replace all references to kratix-promise-id to kratix.io/promise-name

[aclevername]

We are changing the behaviour so that only scheduling specified in the promise.yaml is applied to both the promise and resource requests. Dynamic scheduling within the promise configure workflow is not also passed onto the resource configure workflow.

[aclevername]

main branch is multiple-workflows, which ATM just contains the nice commit for https://github.com/syntasso/kratix-docs/issues/51. There is another WIP branch based from this branch with a dirty commit history that contains the next steps of implementing multiple workflows https://github.com/syntasso/kratix/tree/multiple-workflows-for-reals

[aclevername]

WIP Task:

• Move commented out tests from dyanmic/promise_tests to the manager tests
• refactor all the things to have sensible names
• backfil tests for the new manager
• manager today doesnt handle multiple pipelines well- it could accidentally run two jobs in parallels

  // Create request
  // A starts
  // A finished
  // B starts
  // Requests gets updated
  // A-new starts
  // B and A-new are now both in parallel?

• replace all references to kratix-promise-id to kratix.io/promise-name

[richcooper95]

Context dump for Monday...

Where we stand today

• We no longer pass Promise deps into the Promise Configure workflow, so #92 is done - it lives on the multiple-workflows branch and is not yet merged to dev
  • This also changes the way we manage Works: we now retrieve them via labels, rather than a concatenated name
  • Also no longer pass through the dynamic scheduling from Promise Configure workflow to Resources (no longer have the Work saved in the dynamic Controller)
• We're working on the actual multi-pipeline implementation on multiple-workflows-for-reals - this is based off multiple-workflows
  • We have a for-loop implementation in workflow.ReconcileConfigure which works in the simple scenario but may not work with updates etc. (see the list below)
  • We intend to squash and merge this branch into multiple-workflows so we have two nice commits, which can then be merged into dev

TODO

• [x] Handle the case where a RR is updated whilst Pipelines are running:
  • Request created
  • Pipeline 1 starts
  • Pipeline 1 finishes
  • Pipeline 2 starts
  • Request updated
  • Pipeline 1 (new) should not start until Pipeline 2 finishes from the first run (and if there was a Pipeline 3, do not run this at all!)
• [x] Backfill workflows package tests:
  • [ ] Existing functionality
  • [ ] New functionality where multiple Pipelines are handled (e.g. searching for all Jobs with matching labels)
• ~[ ] Consolidate deletion of all Promise k8s resources within the Promise Controller into a single finalizer (i.e. Jobs, ServiceAccounts, ClusterRoles, ClusterRoleBindings, ConfigMaps, Works) - everything with a matching kratix.io/promise-name label~ syntasso/kratix#99
• ~[ ] Potentially consolidate deletion of all Resource Request resources within the dynamic Controller into a single finalizer (check if there's a similar pattern there)~ syntasso/kratix#100
• [ ] Move label-related logic when finding resources (i.e. knowledge of label names) into the workflows package - either via a GetLabelsForObject, or keep labels as an implementation detail and have e.g. DeleteObjectResources in the package instead
• [ ] (breaking change) replace all references to kratix-promise-id to kratix.io/promise-name (potentially look at any other labels which don't start with kratix.io and rename those too!)
• [ ] Check if there are any other breaking changes to bundle in, so our customers get them all at once!
• [ ] Verify if syntasso/kratix#84 is implemented

[kirederik]

Promise Workflow

• configure

  • single workflow to configure and delete ✅
  • workflow is executed at installation ✅
  • workflow is executed at delete ✅
  • multiple configure workflow ✅
  • workflows are executed sequentially ✅
  • all files produced are stored in the state store ✅

• updates

  • from N to N+1 workflows ✅
  • workflows are executed sequentially ✅
  • all files produced are stored in the state store ✅
  • from N to N-1 workflows ✅
  • N workflows are executed ✅
  • all files produced are store in the state store ✅ (if the pipeline even runs)
  • any extra files are deleted ✅
  • Renaming pipeline names: see syntasso/kratix#98

[kirederik]

Resources

• configure

  • single workflow to configure and delete ✅
  • workflow is executed at installation ✅
  • workflow is executed at delete ✅
  • multiple configure workflow ✅
  • workflows are executed sequentially ✅
  • all files produced are stored in the state store ✅

• updates

  • Resource updates
  • Re-executes all the pipelines, update the files on the state store ✅
  • Promise updates
  • from N to N+1 workflows ✅
    • workflows are executed sequentially ✅
    • all files produced are stored in the state store ✅
  • from N to N-1 workflows
    • N workflows are executed ✅
    • all files produced are store in the state store ✅
    • any extra files are deleted ✅

• manual reconciliation

  • triggers all the pipelines ✅

[SaphMB]

Implementation complete with system tests updated and passing. Remaining task:

• [ ] system test of multiple resource request configure pipeline (the current test only tests Promise configure workflows)

[richcooper95]

Docs PR here: https://github.com/syntasso/kratix-docs/pull/47