Hanging forever in several pipeline configurations

[corporateuser]

Description

If pipeline starts docker container with -a stdin parameter then, stdin will always be a pipe and not a char device, so this check will always be true, however if no process is writing to the stdin, then this read will be hanging forever if you're trying to deploy a deployment descriptor.

Your environment

• MultiApps CF CLI Plugin version - 3.2.2

Steps to reproduce

• create any valid mtad.yaml file, e.g:

ID: "my-mta"
_schema-version: 3.3.0
version: 0.0.0

resources:
- name: my-cf-service-instance-resource
  type: org.cloudfoundry.managed-service
  parameters:
    service-plan: "lite" # set the service plan to use
    service: application-logs #set the service offering (label)

• create script

cf login -a ${$.env.CF_API} -u ${CF_USERNAME} -p ${CF_PASSWORD} -o ${CF_ORG} -s ${CF_SPACE} # replace with proper values
DEBUG=1  cf deploy

• create a Dockerfile

FROM ppiper/cf-cli

WORKDIR /app
COPY mtad.yaml /app/
COPY runme.sh /app/

CMD [ "/bin/bash", "/app/runme.sh" ]

• build docker image with docker build -t test:test .
• run a container with docker run -i -a stdin test:test, and notice the container id
• check docker logs with docker logs 332f45a33eb583f08da40b4ec3cc5bfe5ef7be5e9163f00d38959944fe2ae52e, where 332f45a33eb583f08da40b4ec3cc5bfe5ef7be5e9163f00d38959944fe2ae52e is the id from the previous step
• you'll see hanging forever deployment with output similar to:

API endpoint: https://api.cf.BTP


Authenticating...
OK

Targeted org YOUORG.

Targeted space your-space.

API endpoint:   https://api.cf.BTP
API version:    3.159.0
user:           CF_USERNAME
org:            YOUORG
space:         your-space
Initializing command "deploy"
Executing command 'deploy': args: '[]'
a
abort-on-error false
all-modules false
all-resources false
delete-service-brokers false
delete-service-keys false
delete-services false
do-not-fail-on-missing-permissions false
e
f false
i
keep-files false
m []
namespace
no-restart-subscribed-apps false
no-start false
r []
retries 3
skip-idle-start false
skip-ownership-validation false
skip-testing-phase false
strategy default
t
u
version-rule

I'm thinking that actually waiting forever for anything in the code is generally a bad practice, so you may want to add some type of timeout for waiting for input and command line parameter like --ignore-stdin not to try to read from stdin at all.