docs: no longer pass Promise dependencies into Promise Configure Pipeline

[richcooper95]

Background

It's currently possible to define static dependencies in a Promise via the dependencies field. If there are no workflows for the Promise, these dependencies are scheduled via a Work that's created separately (outside of the WorkCreator).

If the Promise does have a Promise Configure workflow, we pass the Promise dependencies into the Pipeline as /kratix/output/static/dependencies.yaml (see docs here). This is so that the Pipeline is responsible for creating the Work that will schedule these dependencies. This works for a single Pipeline.

Problems

As part of the pre-work for multiple Pipelines (#90) we decided this no longer made sense because it's unclear which Pipeline should be responsible for scheduling the dependencies.

Even without considering multiple Pipelines, we saw some issues with passing static dependencies into the Pipeline:

1. When adding a workflow to a Promise which previously only had static dependencies, and the responsibility of creating the Work is shifted to the WorkCreator, it's unclear what should happen to the old Work that was created for the static dependencies. (It should probably be deleted, but that's destructive.)
2. When dependencies are passed into the Pipeline, it blurs the responsibility of the dependencies; users may make their Pipelines dependent on the static dependencies, when this wasn't an intended use-case.

For these reasons, we decide to no longer pass in the dependencies to the Pipeline(s).

Solution

Instead of passing dependencies into the Pipeline(s), we will maintain the separate Work created for the static dependencies, and manage this outside of the Pipeline(s).

This enforces separation between the static dependencies in the Promise definition, and the dynamic dependencies output at the end of the Pipeline. The Pipeline dependencies will still be scheduled via the WorkCreator.

Users

Who is affected?

Anyone who uses Promises which have both static dependencies and a Promise Configure workflow.

How are they affected?

The dependencies will no longer be passed into the Pipeline, meaning they're no longer accessible from any Pipeline containers at /kratix/output/static/dependencies.yaml.

What should they do?

If the dependencies weren't accessed during the Pipeline, you don't need to do anything - the static dependencies will continue to be scheduled as before.

If dependencies were accessed during the Pipeline, you should move the static dependencies into the Pipeline instead of defining them in the Promise dependencies. You can do this by generating the dependency manifests via a container image that runs as part of the Pipeline.

[aclevername]

syntasso/kratix@a801ce8

[kirederik]

code for this is already implemented in the multiple-workflows branch; updating this to become a documentation of release notes