Wait a workflow to finish before running another workflow

My Docker build workflow:

name: docker

    - 'Dockerfile'
    - 'setup.py'
    - 'install*.sh'

    runs-on: ubuntu-latest
    - uses: actions/checkout@master
    - name: Publish to Registry
      uses: elgohr/Publish-Docker-Github-Action@master
        name: dragoncomputer/dragonfire
        username: ${{ secrets.DOCKER_USERNAME }}
        password: ${{ secrets.DOCKER_PASSWORD }}

and my test workflow:

name: test

on: [push]


image: dragoncomputer/dragonfire:latest

    - uses: actions/checkout@v1
    - name: Install dependencies
      run: |
        sudo ./install-dev.sh --no-model
        sudo pip3 install pytest-faulthandler
        sudo apt install xvfb
    - name: Lint with flake8
      run: |
        sudo pip3 install flake8
        # stop the build if there are Python syntax errors or undefined names
        flake8 . --count --select=E9,F63,F72,F82 --show-source --statistics
        # exit-zero treats all errors as warnings. The GitHub editor is 127 chars wide
        flake8 . --count --exit-zero --max-complexity=10 --max-line-length=127 --statistics
    - name: Test with pytest
      run: |
        sudo pip3 install pytest pytest-cov codecov
        xvfb-run --auto-servernum python3 -m pytest --cov=dragonfire/ --capture=sys --disable-pytest-warnings -vv
        # send the code coverage report to Codeconv
        codecov --token=${{ secrets.CODECOV_TOKEN }}

But since my Docker build only runs when specific files are changed:

    - 'Dockerfile'
    - 'setup.py'
    - 'install*.sh'

it needs to be a separate workflow.

Since my Docker image is 5GB and it exceeds the GitHub Actions cache limit: https://github.com/actions/cache#cache-limits, I cannot use the cache either.

So my question: Is there a way to wait a workflow to finish before running another workflow? If there is none then how can combine these to workflows to single one?

By the way, I know there is jobs.<job_id>.needs but seems like it does not solve my problem because my Docker build/job runs when a specific criteria is met.

If you are wondering why do I need a comlicated workflow like this then you might want to check out the current situation of my repository:



1 Like

There is no method to wait a workflow to finish before running another workflow. There is a work around to combine these two workflows to a single one.

You can add a step to get file names which changed in the commit. And set it to an output variable: commitpath .

- name: check1
   id: filepath
   run: |
        echo ::set-output name=commitpath::$(git diff-tree --no-commit-id --name-only -r ${{ github.sha }})

Then judge the path in if condition using contains function for ‘publish to registry’ step. As contains( searchString, searchValue ) function doesn’t support to use wildcards, you need to specify all your exact file names as searchValue.

Such as:

if: Contains(steps.filepath.outputs.commitpath, 'Dockerfile') || Contains(steps.filepath.outputs.commitpath, 'install.sh') || Contains(steps.filepath.outputs.commitpath, 'setup.py')

Also, you need to use  jobs.<job_id>.needs in build job.

Please see my examples:

Note that there will be some additional time for this workflow to run docker job when commits don’t include changes in Dockerfile, setup.py etc.

Thank you @yanjingzhu  for your explanations.

That’s a very unfamiliar.

I would expect a CI/CD workflow to be sequential and a as easy as:

  • on every push: run this job/step/workflow/action/pipeline/whatever
  • only on master branch: run this other job,
  • if it’s a tag creation, then do this and that…

It’s weird that it’s such complicated in Github Actions. I hope this will get improved in the future.


Use the workflow_run event to chain workflow files together. The only caveat is all the workflow files have to be in the same repo.

I know this is an old topic but as far as i know there want any change on this so the problem still persists.

Atm i feel like workflow_run is just a step into the right direction, but there are mayor drawbacks that prevent the usage (for me):

  1. When using “workflow_run” the contexts are lost (the event/pull_request context for example). The example in “How to prevent pwning PRs Part1” shows that it is possible to re-obtain the kontext but it requires a lot of effort. Also many actions rely on the presence of the context like github.base_ref and so on
  2. When triggered by a “pull_request” workflow the “workflow_run” thing wont show up as check in the PR