When is Login Debugging Needed?

User scripts execute inside a Docker container. Differences between local and CI environments may cause build failures that don't occur locally. In such cases, use the "Login Debugging" option on the logs page to access the container for troubleshooting.

How to Use?

A Docker container is started during pipeline execution to run user scripts. The container is destroyed after the build completes by default, so debugging must be done while the environment is still alive.

Login debugging is available in two scenarios:

1. During the build: Click "Login Debugging" directly
2. After the build: Check the Debug option (next to Rebuild) on the logs page, then click Rebuild. The environment is retained for 5 minutes after the newly triggered build completes. The system periodically checks if anyone is logged in: if not, the environment is destroyed; if yes, it continues to be retained for a maximum of 1 hour.

Debugging Tips

When clicking Rebuild, you can select which Pipeline, Stage, or Job to execute, helping to reproduce the problem environment.

For example, if the build fails at the install stage and you suspect the dependency install command behaves differently than locally, you can select only that stage to re-run, then click "Login Debugging" to enter the container and check whether the artifacts (such as node_modules) match the local ones.

Tip:

• When you select specific Pipeline, Stage, or Job, the unselected jobs are not executed, which helps quickly locate which step fails.
• If the selected Stage depends on preceding tasks (such as artifacts or dependencies), select those preceding tasks together as needed. Otherwise, the re-run may fail due to missing prerequisites.

Previous pageSkip Pipeline Execution

Next pageManually Trigger Pipeline