feat: helm concurrent deploys with cross dependency

[orlandoburli]

Fixes: #5417

Description
This PR is adding a option for concurrent helm releases to wait for other helm charts.

deploy:
  helm:
    concurrency: 3
    releases:
      - name: service1
        chartPath: charts/service1
      - name: service2
        chartPath: charts/service2
      - name: service3
        chartPath: charts/service3
        dependsOn:
          - service1
          - service2

On the following example, the service3 will wait until helm deploy for service1 and service2 to finish. If some of those services fails, the service3 deployment won't start.

User facing changes

User can add the dependsOn option to a helm release template.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[idsulik]

what about nested dependencies?
ServiceA depends on ServiceB and ServiceB depends on Service C

[orlandoburli]

I have not created a test for this case but, in theory, it should work the same way. Here's why:

• The first action is to check all services that has dependents, then create the channels to use as wait controllers;
• So, In the case you're suggesting:
  • If ServiceC starts first, it will hit the signal break with channels; It's gonna wait for Service B to continue;
  • If ServiceB starts in second, it will hit the signal break too, and wait for ServiceA
  • ServiceA does not depends on anyone, so it deploys and send the "all clear" signal to his dependents
  • ServiceB get's the "all clear" signal, and starts this deployment. When finished, it will also sends his signal for ServiceC
  • Finally, ServiceC get's his all clear and do this deployment.

One scenario that may happen is a deadlock. I did not think about it on this PR.

Another thing that I'm thinking is that this deserve a integration testing. I'm still learning about this repo and I will create a separated PR for that. This PR already has the label "size/L" 😱

[idsulik]

I suggest you to check this approach #9588 (comment), because the current approach will lead to deadlock(concurrency = 3 and 3 dependencies are waiting, for example).
don't worry about the "size/L", it's ok)

[orlandoburli]

Ok thanks for the feedback @idsulik . I'll work on that. Now I see the point, it's easy to get to a deadlock situation because of the lack of resources.

[idsulik]

@orlandoburli welcome! good feature!
I think you can use topological sorting to achieve this or a simpler way:

1. put releases in some data structure to extract them level by level.
2. lock each level using semaphore.

flow:

1. start installing deepest level dependencies
2. lock until all the releases will be installed
3. start installing next level dependencies
4. lock
5. etc.