Run external dependencies improvements

We were looking to adopt run external dependencies to use as additional checks for important stacks (e.g. ones that managed production resources) but ran into a couple of drawbacks that make us hesitant to use this push policy feature:

Run external dependency statuses reported via graphql API or spacectl cannot be updated after the first update.

When an external dependency reports FAILED, the tracked run moves to an error state. Re-running the external dependency checks (such as in the case of a network hiccup that caused a rare automated failure) require kicking off a new tracked run.

What we’d like instead: The status would show up as failed for the external dependency, but the tracked run would stay in a queued state until those checks were either skipped or set to passing. External dependencies could then be managed and retried out of Spacelift without needing to re-trigger anything on the Spacelift side of things.

Re-triggered runs (via UI or API) do not include external dependency checks.

Trying to retry a run that failed from an intermittent external dependency failure creates a run that skips setting external dependency checks — because the run wasn’t initiated from VCS, the push policy that adds those checks does not get applied to the run. This forces us to rekick off a new tracked run from Git to run external dependencies again — in the case of PR merge to mainline => tracked run, this is not a practical alternative.
What we’d like instead: Some way to include external dependencies that aren’t tied to a push policy that only applies on VCS push, or some way to evaluate push policies on triggered runs.

The alternative we’re considering now is to move any external checks to something that is tracked and notified outside of Spacelift, or move checks to the approval policy step, where automated processes instead leave an approval on run. These options are less than ideal when compared to how neatly external dependencies otherwise fit into our workflows.