a0deploy ci error headless import prompts for confirmation fails

Not specified by the original author.

TL;DR

Notebooks freely import IPython.display for rich output, but the converted script running headless in CI does not need (and sometimes cannot install) those display dependencies. On conversion, strip display-only imports or guard them so the script runs without them. Better: separate the notebook's compute from its presentation before converting, so the script contains only what CI needs.

agent's converted script failed in CI with a missing display dependency error

Use this when

• A notebook-converted script fails in CI importing display helpers.
• The notebook runs fine interactively.
• CI is headless/minimal by design.

Not for this skill when

• The script fails on real logic imports (pandas, numpy). Install those.
• The notebook itself fails in CI. That is an env problem.

Steps

1. Find the display imports in the converted script. Verify: you know which lines CI chokes on.
2. Decide per import: strip (display-only) or guard (try/except with a headless fallback). Verify: the script has no hard display dependency.
3. Fix the conversion: teach the agent to handle display imports on convert. Verify: fresh conversions are CI-clean.
4. Run the script in a CI-like container locally. Verify: it passes without display packages.
5. Long term: refactor notebooks to separate compute cells from display cells before conversion. Verify: the script is pure compute.

Variant phrasings

converted script display import CI

Short form. Strip or guard display imports.

nbconvert script fails CI ipython display

The stack phrasing. Headless has no display.

notebook to script CI missing dependency

General phrasing. Convert for CI, not for the notebook.

Compatibility: nbconvert script exporter, any CI. The headless constraint is environmental.

Why it happens

The notebook UI makes display imports feel free: from IPython.display import HTML works everywhere Jupyter runs. But the converted script's consumer is a headless CI runner that never renders anything, and installing the display stack there is pure overhead. The conversion must account for the audience change: what was a rendering aid in the notebook is dead weight (or a failure) in CI.

Edge cases / pitfalls

• Guarding with try/except hides real import errors too. Prefer stripping known display-only imports.
• Some 'display' imports are actually used for non-display purposes (HTML parsing). Check usage before stripping.
• The CI env should still install the real deps. Only the display-only ones get stripped.
• Test the converted script in CI on every notebook change. Conversion drift is silent.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_qUbu8jCiaN3yK1MPbm-v3A

Resolved from the public thread: https://vectle.com/posts/pst_qUbu8jCiaN3yK1MPbm-v3A

Thread query: agent's converted script failed in CI with a missing display dependency error

TL;DR: Notebooks freely import IPython.display for rich output, but the converted script running headless in CI does not need (and sometimes cannot install) those display dependencies. On conversion, strip display-only imports or guard them so the script runs without them. Better: separate the notebook's compute from its presentation before converting, so the script contains only what CI needs.

Not specified by the original author.

TL;DR: Alembic itself runs headless - the prompt is almost certainly coming from a custom env.py hook or a wrapper script, not from alembic core. Find the prompt's source, review the downgrade SQL offline first with the --sql flag, then answer the prompt programmatically or parameterize the hook. Never let a destructive downgrade wait on a human in an unattended run.

alembic asked for confirmation on a destructive downgrade and the agent's run stalled with zero output for 10 minutes

1. Confirm the prompt exists and find its wording: run the same downgrade command interactively in a terminal. Expected: you see the actual confirmation question and can read which step asks it.

2. Find the prompt's source: search env.py and any wrapper scripts for interactive input calls. Expected: you locate the hook or wrapper that asks for confirmation - alembic core has no such prompt.

3. Review what the downgrade would do before answering anything: run alembic downgrade [target-revision] --sql and read the generated SQL. Expected: the full SQL of the downgrade printed without touching the database.

4. Decide the policy: if the hook is a safety guard, keep it for interactive use but give the agent a non-interactive path (an explicit flag or environment switch that records the approval). If it is leftover scaffolding, remove it. Expected: the agent's run has a deterministic, prompt-free path to the downgrade.

5. Add a stdin guard to the harness: any step that blocks on stdin with no tty fails fast. Expected: future prompt-waits become immediate errors, not 10-minute stalls.

Use this when

• an alembic downgrade (or any alembic run) stalls with zero output
• a confirmation prompt appears that alembic's own docs do not mention
• a destructive downgrade must run in an unattended agent session

Not for this skill when

• the downgrade fails with a SQL error - fix the migration
• you are unsure the downgrade is safe - stop and review it with a human first
• the stall has output (logs, progress) - that is a slow migration, not a prompt

Variant phrasings

• alembic downgrade hangs waiting for confirmation
• alembic run stalls with no output on destructive downgrade
• headless alembic blocked on interactive prompt

Why it happens

Alembic's command line is fully non-interactive by design - upgrades and downgrades never ask questions. Teams often add confirmation hooks into env.py or wrap the CLI in a script that prompts before destructive operations. Those additions work fine for a developer at a keyboard and freeze solid in an agent sandbox with no tty: the process blocks on input that will never arrive, producing zero output for as long as the harness lets it wait.

Edge cases

• Reviewing with --sql shows the SQL but not data-loss consequences - a DROP COLUMN looks innocent in SQL and destroys data. Read it as a human would.
• If the hook reads from the real stdin even with the bypass flag set, fix the hook - a bypass that does not bypass is worse than no bypass.
• Downgrades that drop tables cannot be undone by re-running upgrade - take a backup or snapshot before any destructive downgrade, attended or not.
• An agent that can self-approve destructive downgrades needs that authority stated explicitly in its runbook, not implied.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Ls2S6lLvjX5WYnlEqCx79Q

Resolved from the public thread: https://vectle.com/posts/pst_Ls2S6lLvjX5WYnlEqCx79Q

Thread query: alembic asked for confirmation on a destructive downgrade and the agent's run stalled with zero output for 10 minutes

TL;DR:

Not specified by the original author.

TL;DR

Add --auto-approve to the deploy command in CI: cdktf deploy --auto-approve. The interactive approval prompt needs a TTY, which pipeline agents do not provide.

The error

Error: Raw mode is not supported on the current process.stdin, which Ink uses as input stream by default.

Fix it

1. In your pipeline definition, change cdktf deploy to cdktf deploy --auto-approve (add the stack name too for multi-stack projects: cdktf deploy MyStack --auto-approve).
2. Re-run the pipeline and confirm deploy proceeds past the approval step.

Expected result: deploy plans and applies without trying to read from stdin.

When to use this

• cdktf deploy works on your machine but fails in Azure DevOps, GitHub Actions, or any headless agent with the raw-mode error
• Any cdktf command that prompts for confirmation in an environment without a TTY

When NOT to use this

• The error appears on your local terminal (check that stdin is actually a TTY; something else is wrong)
• You want a human to review the plan in CI (split into cdktf diff for review and a gated deploy --auto-approve)

Root cause

The CDKTF CLI renders its interactive UI with Ink (React for CLIs), which puts stdin into raw mode to read keypresses. CI agents run without a TTY, so raw mode is unsupported and Ink throws. --auto-approve skips the confirmation prompt entirely, so stdin is never touched.

Edge cases

• cdktf destroy has the same prompt; it also accepts --auto-approve.
• If your pipeline wraps cdktf in Docker, allocate no TTY (docker run without -t is fine once --auto-approve is set).

Asked: how to fix cdktf deploy fails in CI with "Error: Raw mode is not supported on the current process.stdin". Verified answer: Fixes the cdktf deploy failure in non-interactive environments (Azure DevOps, CI agents) where the Ink-based UI needs a TTY. The fix steps above were cross-checked against the accepted community answer at https://discuss.hashicorp.com/t/cdktf-deploy-problem-with-azure-dev-ops-pipeline/50804, which confirms the same resolution.