Fix storage backend ID for TypeInstance from nested workflow

[mkuziemko]

Description

Changes proposed in this pull request:

• fix storage backend ID for TypeInstance from nested workflow

There was incorrect backend mapping - we find it by the name of output Type Instance relation which is ok where there is no nested workflow. In the nested workflow, we need to find it by the name of the artifact.

Testing

1. Checkout this PR
2. Create cluster using DISABLE_MONITORING_INSTALLATION=true USE_TEST_SETUP=true make dev-cluster
3. Change manifests source to my branch with no backend for psql:

kubectl set env deploy/capact-hub-public -n capact-system -c hub-public-populator MANIFESTS_SOURCES="github.com/mkuziemko/hub-manifests?ref=lost_bid"

4. Install Helm Storage and Mattermost
5. Verify uploaded TypeInstaces.

Related issue(s)

• Storage backend ID for TypeInstance from nested workflow is lost during TypeInstance upload #705

[mszostok]

I saw you branch with manifests changes, unfortunately it doesn't cover the whole story. Here is a valid fix to our manifests: https://github.com/capactio/hub-manifests/compare/main...mszostok:test-706?expand=1

I tested that with your change, and unfortunately I got such error:

Cannot render given action: while rendering Action: while adding TypeInstances to graph: while resolving backend ID for "mattermost-install-install-db-postgres-install-helm-install-helm-release": cannot find backend storage for specified "helm-release-storage" alias (will retry - 13/15) 

Please let me know if you need more info about my setup.

[mkuziemko]

Good point 👍

We don't need the alias for these manifests as we don't use it in the main workflow. I updated my fork.

The above error was caused by:

typeInstancesBackends, err := r.policyEnforcedCli.ListTypeInstancesBackendsBasedOnPolicy(ctx, rootimpl.Rule, rootimpl.Revision)

In the rendering we are checking if we have:

if step.CapactAction != nil {

based on which we are searching implementation and rules but for the looking of the backends, we passed always the ,,root" implementation which does not work for nested workflows.

Thus, when you removed the aliases from the Mattermost manifests, it couldn't resolve the backend.

Anyway, I verified it one more time installing Postgres and then the Mattermost, and it works.

[mkuziemko]

I took the newest manifests and add a v2 prefix. I created issue to mitigate/track this problem.

[mszostok]

I tested single psql and mattermost + psql. Both work as expected. Good job 🚀

Please submit a PR with manifest fixes too.