# \[SOLVED\] Run docker pipeline after failed exec pipeline

**URL:** <https://drone.discourse.group/t/solved-run-docker-pipeline-after-failed-exec-pipeline/8957>\
**Category:** Drone Support\
**Created:** [December 10, 2021, 10:59am UTC](https://drone.discourse.group/t/solved-run-docker-pipeline-after-failed-exec-pipeline/8957 "2021-12-10T10:59:26Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![cbix](https://yyz1.discourse-cdn.com/flex003/user_avatar/drone.discourse.group/cbix/32/2436_2.png) [@cbix](https://drone.discourse.group/u/cbix)\
**Post date:** [December 10, 2021, 10:59am UTC](https://drone.discourse.group/t/solved-run-docker-pipeline-after-failed-exec-pipeline/8957/1 "2021-12-10T10:59:26Z")

</div>

Hey, I’m rather new to Drone but so far really like working with it!

For one project we’re using an exec pipeline for E2E tests because it needs to set up a docker-compose environment. The test framework automatically creates videos and other output files (which are useful for debugging) that need uploading to an external server in a separate step.

This uploading step should be done using a docker container, so I created a second “normal” pipeline that `depends_on` the first exec pipeline. The problem I have now is that the 2nd pipeline gets skipped whenever the first pipeline fails, however failure of the 1st pipeline would make the uploaded output files even more interesting.

My current workaround is to ` || true` the test step so it always passes, but this is only good for debugging and should be removed later.

Is there any way to never skip the 2nd pipeline, but only running it after the 1st one finishes?

---

<div class="post-metadata">

**Author:** ![bradrydzewski](https://yyz1.discourse-cdn.com/flex003/user_avatar/drone.discourse.group/bradrydzewski/32/3513_2.png) [@bradrydzewski](https://drone.discourse.group/u/bradrydzewski)\
**Post date:** [December 10, 2021, 3:00pm UTC](https://drone.discourse.group/t/solved-run-docker-pipeline-after-failed-exec-pipeline/8957/2 "2021-12-10T15:00:14Z")

</div>

> My current workaround is to `|| true` the test step so it always passes, but this is only good for debugging and should be removed later.

Drone natively has syntax to execute pipeline steps and pipelines on failure.

Further reading on executing pipelines steps on failure:  
[https://docs.drone.io/pipeline/docker/syntax/conditions/#by-status](https://docs.drone.io/pipeline/docker/syntax/conditions/#by-status)

And executing pipelines on failure:  
[https://docs.drone.io/pipeline/docker/syntax/trigger/#by-status](https://docs.drone.io/pipeline/docker/syntax/trigger/#by-status)

> This uploading step should be done using a docker container, so I created a second “normal” pipeline that `depends_on` the first exec pipeline.

If you ever expand Drone to more than a single machine, this will be problematic, because Drone makes no guarantee that two pipelines will execute on the same machine. For this reason, if it were me, I would create a small shell script that uploads artifacts and I would invoke that from a step in my exec pipeline, as opposed to using a separate Docker pipeline.

---

<div class="post-metadata">

**Author:** ![cbix](https://yyz1.discourse-cdn.com/flex003/user_avatar/drone.discourse.group/cbix/32/2436_2.png) [@cbix](https://drone.discourse.group/u/cbix)\
**Post date:** [December 10, 2021, 4:14pm UTC](https://drone.discourse.group/t/solved-run-docker-pipeline-after-failed-exec-pipeline/8957/3 "2021-12-10T16:14:12Z")

</div>

Good point regarding multiple nodes. Thanks for the “trigger by status” reference, I now got it working as intended by using `depends_on` + trigger for failed status, also had to add the triggers from the first pipeline again.

```auto
---
kind: pipeline
name: First
type: exec
# ...
trigger:
  ref:
    include:
      - refs/heads/master
      - refs/pull/**
      - refs/tags/**

---
kind: pipeline
name: Second
depends_on:
  - First
# ...
trigger:
  ref:
    include:
      - refs/heads/master
      - refs/pull/**
      - refs/tags/**
  status:
    - failure

```