You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Interactive recipes can't be executed in automated workflows. There should be a way for the recipe to know if it is being executed non-interactively, and act accordingly. Now this is crudely possible already by using environment variables, i.e.
NON_INTERACTIVE=true npx tmplr
if: env.NON_INTERACTIVEsteps:
...else:
steps:
...
But is it worth adding better support for this? For example, all interactive expressions could have a fallback property, which would be used if the environment is non-interactive (basically, the command should get an error if they try to connect to an IO interface in such an environment, falling back to their fallback). Detecting whether the environment is non-interactive can be done via multiple ways: a flag (such as --force), environment variables for popular CI/CD pipelines (see this), etc. This could also result in a predetermined environment variable being automatically set, basically standardising the env var solution outlined above.
The text was updated successfully, but these errors were encountered:
Interactive recipes can't be executed in automated workflows. There should be a way for the recipe to know if it is being executed non-interactively, and act accordingly. Now this is crudely possible already by using environment variables, i.e.
But is it worth adding better support for this? For example, all interactive expressions could have a
fallback
property, which would be used if the environment is non-interactive (basically, the command should get an error if they try to connect to an IO interface in such an environment, falling back to their fallback). Detecting whether the environment is non-interactive can be done via multiple ways: a flag (such as--force
), environment variables for popular CI/CD pipelines (see this), etc. This could also result in a predetermined environment variable being automatically set, basically standardising the env var solution outlined above.The text was updated successfully, but these errors were encountered: