Allow workflow_run to wait for all workflows it depends on #16059
Replies: 6 comments 7 replies
-
|
Just to complete my example above, this is the way to achieve an equivalent flow today, which I must say results in much more code: # A sub-project workflow
name: project-x
on:
workflow_call:
inputs:
job:
required: true
type: string
jobs:
build:
runs-on: ubuntu-latest
if: ${{ inputs.job == 'build' }}
steps:
- uses: actions/checkout@v2
- run: build
deploy:
runs-on: ubuntu-latest
if: ${{ inputs.job == 'deploy' }}
concurrency: project-x-main
steps:
- uses: actions/checkout@v2
- run: deploy
# Infrastructure workflow that orchestrates everything
name: infra
on:
push:
branches: [main]
jobs:
run-project-1-build:
name: Project 1
uses: ./.github/workflows/project-1.yml
with:
job: build
secrets: inherit
run-project-2-build:
name: Project 2
uses: ./.github/workflows/project-2.yml
with:
job: build
secrets: inherit
run-project-n-build:
name: Project N
uses: ./.github/workflows/project-n.yml
with:
job: build
secrets: inherit
infra-check:
runs-on: ubuntu-latest
needs:
- run-project-1-build
- run-project-2-build
- run-project-n-build
steps:
- uses: actions/checkout@v2
- run: infra-check
infra-update:
runs-on: ubuntu-latest
needs: infra-check
concurrency: infra-main
steps:
- uses: actions/checkout@v2
- run: infra-update
run-project-1-deploy:
needs: infra-update
name: Project 1
uses: ./.github/workflows/project-1.yml
with:
job: deploy
secrets: inherit
run-project-2-deploy:
needs: infra-update
name: Project 2
uses: ./.github/workflows/project-2.yml
with:
job: deploy
secrets: inherit
run-project-n-deploy:
needs: infra-update
name: Project N
uses: ./.github/workflows/project-n.yml
with:
job: deploy
secrets: inheritThis means that, for each new sub-project in the mono repo, we have to add a call to And the resulting UI would contain many skips: |
Beta Was this translation helpful? Give feedback.
-
|
This conceptual inconsistency is annoying. If you specify multiple workflow dependencies, only one needs to run. If you specify multiple job dependencies, all of them have to run. |
Beta Was this translation helpful? Give feedback.
-
|
@miparnisari , |
Beta Was this translation helpful? Give feedback.
-
|
Looking for this feature too. We really need a deployment workflow to happen only after both frontend AND server test workflows have finished. |
Beta Was this translation helpful? Give feedback.
-
|
Try out this publicly accessible "wait for workflows" action from Chainlink that waits either for all workflows or only for the specified ones and then run your job. |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately is the "wait for workflows" action only a workaround for us. We also need to deploy code when and only when all tests and build steps are done, but we still have some flakyness in the process and may need to restart some jobs/workflows. So we can not just wait a specific time, like in "wait for workflows" action. We need something, what will trigger the workflow, when all conditions will be met, independent when it will happen. |
Beta Was this translation helpful? Give feedback.
-
|
This is a major thorn in my side at the moment, it would be very helpful to be able to wait for many workflows. |
Beta Was this translation helpful? Give feedback.
-
|
Hello Github, any update on this ? |
Beta Was this translation helpful? Give feedback.
-
|
I really need this as well GitHub |
Beta Was this translation helpful? Give feedback.
-
|
I'll add my voice here as well. This is a need for our projects. Our current solution is to "daisy-chain" the dependent workflows so that each triggers on completion of the previous. All because I just want the last workflow to run only if all the previous ones worked. |
Beta Was this translation helpful? Give feedback.
-
|
This is not a valid solution because triggered workflows are not by default visible in PR "checks". To make them visible one needs to manually post their result there, which makes it flimsy. Basically the only ones that are visible by default are the one triggered by pull_request events. It suck and it also means that the only working trick is to implement a looping wait in a first job. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I tried a looping wait as well with each parent job dispatching an event that the dependent job looks for. In the end it was too flimsy so we are still without a viable solution. |
Beta Was this translation helpful? Give feedback.
-
|
I’ve found a combination of creating a new branch and then pinging the API for what is the only run on that specific branch until there is a result works decently but has cons, such as sainting logic to create/cleanup the branches, extra cycles for polling, etc. In my case the dispatch is coming from an external service, not another GitHub Action. The pattern I settled on is a step at the end of workflows with if: always that sends the status back to the external service External service => GitHub API => dispatch GitHub Actions run => OIDC role => cloud provider => update Database |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello!
I've been using Github Actions in my personal projects with great success, so kudos for the awesome tool 🙌
One feature that my colleagues and I have been missing, though, is to be able to make
workflow_runwait for all the other workflows it depends on instead of resolving on the first completed one. Something like this would be awesome:The reasoning behind this feature request is that we would like to be able to keep the nice UI you built for separate workflows while being able to create dependencies between them in a more versatile way (eg. making sure a given job is only executed once in the entire build pipeline). Currently, the only way to achieve the same thing (afaik) is to make the "parent" workflow call all the "child"/"dependency" workflows using
workflow_calland put all of them in aneedsdirective. However that generates a worse UI since, at the end,workflow_callends up embedding the called workflow's steps into the caller workflow. Thus we have to scan through a lot jobs to understand what failed, whereas in the separate workflows case the failure reports are spot-on.Maybe an example would be better. Imagine a monorepo-like structure, where the repo's root contains many sub-projects. Also sitting on the root, there's a infra folder, containing code responsible for spinning up infrastructure somewhere (eg. terraform + AWS). Finally, the
.githubfolder contains workflows for each separate project:- root/ - .github/ - workflows/ - infra.yml - project-1.yml - project-2.yml - project-n.yml - infra/ - project-1 / - project-2 / - project-n /The idea is to create this flow:
Then a
project-x.yamlcould look like this:And
infra.ymlcould look like:Thanks in advance.
Beta Was this translation helpful? Give feedback.
All reactions