Run a block step only if the build has failed

I’ve got a pipeline that deploys a cloudformation stack, runs tests against it, then cleans up that stack. I’d like to add a block step prior to the cleanup that, only when tests fail, prevents the cleanup from happening until I unblock it so that I can debug the stack in its failing state.

Unfortunately, it seems like if: build.state == 'failed' is evaluated at upload time, not when execution reaches that part of the dag. Is there anyway to do what I want using just pipeline syntax or do I need to add a dynamic pipeline upload step?

Here’s the relevant portion of my pipeline.yml:

  - label: ':jest: :cloudformation: Integration Tests'
      - 'reports/**/*'
    command: |
      ./scripts/stack-as-env npm test -- --selectProjects 'Integration Tests'
      - sam-deploy-test
    key: sam-jest-integration
      - ecr#v2.5.0: *plugins_ecr
      - docker-compose#v3.8.0: *plugins_docker_compose
      - check-run-reporter/check-run-reporter#main:
          report: 'reports/junit/**/*.xml'
          label: Integration Tests
          token: '$CHECK_RUN_REPORTER_TOKEN'
    retry: *retry

  - block: ':buildkite: Delay deletion due to build test failure'
    allow_dependency_failure: true
    prompt: |
      This build's cloud formation stack has been retained so you can debug it. Please click continue when finished to clean up the stack.
      - sam-jest-integration
      - sam-contract
    if: build.state == 'failed'
    key: sam-block-delete

  - label: ':cloudformation: delete'
    command: |
      sam delete \
        --config-env=test \
        --no-prompts \
        --region=$${AWS_REGION:-$$AWS_DEFAULT_REGION} \
      - sam-jest-integration
      - sam-contract
      - sam-block-delete
    key: sam-delete
    plugins: *plugins
    retry: *retry
    allow_dependency_failure: true

Hi @ianwremmel!

That is correct, the state of the overall build is not available when executing a job. If a job is executing, the state of the build can’t be failed or passed as well, because there’s still a job executing.

It’s not possible to evaluate build.state without using an API to fetch the build and look at the states of the finished jobs. If you’re within a job running within the build then the build is still running, too.