Can you confirm if this is a bug with interactive workflows and custom commands? Should the new interactive step types (eg,

choose

,

input

, etc support non-tty? I think it should. It would mean a single workflow could work for local and ci usage. Example:

workflows:
  build-manifests:
    dependencies:
      tools:
        kustomize: v5.0.3
    steps:
      - name: account
        type: choose
        prompt: "Account"
        options: [dev, prod]
        default: !env STACK_ACCOUNT dev
      - name: region
        type: choose
        prompt: "Region"
        options: [use1, euc1]
        default: !env STACK_REGION use1
      - name: tag
        type: input
        prompt: "Release tag"
        default: !env RELEASE_TAG latest
      - command: atmos kube build "{{ .steps.account.value }}-{{ .steps.region.value }}/tao" --tag "{{ .steps.tag.value }}" --env "{{ .steps.account.value }}" --output ".argocd/manifests/common-tao/kustomized.yaml"
        type: shell
      - command: atmos kube build "{{ .steps.account.value }}-{{ .steps.region.value }}/zen" --tag "{{ .steps.tag.value }}" --env "{{ .steps.account.value }}" --output ".argocd/manifests/common-zen/kustomized.yaml"
        type: shell

Help me understand the non-tty use-case for inputs?

Right now, I have 2 nearly identical workflows. One is basically the last two steps of the example workflow with the values coming envs (see below). There are nearly identical except one is interactive.

workflows:  
  build-manifests-ci:
    description: Build tao+zen manifests for ${STACK_ACCOUNT}-${STACK_REGION}
    dependencies:
      tools:
        kustomize: v5.0.3
    steps:
      - command: atmos kube build "${STACK_ACCOUNT}-${STACK_REGION}/tao" --tag "${RELEASE_TAG}" --env "${STACK_ACCOUNT}" --output ".argocd/manifests/common-tao/kustomized.yaml"
        type: shell
      - command: atmos kube build "${STACK_ACCOUNT}-${STACK_REGION}/zen" --tag "${RELEASE_TAG}" --env "${STACK_ACCOUNT}" --output ".argocd/manifests/common-zen/kustomized.yaml"
        type: shell

I think it would make sense if we introduced tolerance for downgrading to default if no, TTY or stdin available

Okay. I will put a new PR in to allow choose, input, confirm, and filter types to use default without erroring if non-tty. I am going to keep the current error behavior for those same types if non-tty without a default set.

Thanks, Brian! That makes sense