### User story The developer uploads a package and there's an unexpected build failure. This can be due to using another architecture (arm, s390x...), or hitting a peculiarity of the build/autopkgtest environment (unshare, overlayfs, tmpfs, network isolation, eatmydata, disk space, available memory... speaking for experience? ;)). SSH/shell access, to investigate build and test failures, would be time-saving for the developer, and resources-saving for debusine (since the dev won't have to re-run a full lengthy workflow from scratch to test every single fix attempt) :) SourceHut has been providing this for a few years: https://drewdevault.com/2019/08/19/Introducing-shell-access-for-builds.html https://yotam.net/posts/sourcehut-build/ ``` [#1273143] 2024/07/11 00:17:50 Build failed. [#1273143] 2024/07/11 00:17:50 The build environment will be kept alive for 10 minutes. [#1273143] 2024/07/11 00:17:50 To log in with SSH and examine it, use the following command: [#1273143] 2024/07/11 00:17:50 [#1273143] 2024/07/11 00:17:50 ssh -t builds@fra01.builds.sr.ht connect 1273143 [#1273143] 2024/07/11 00:17:50 [#1273143] 2024/07/11 00:17:50 After logging in, the deadline is increased to your remaining build time. ``` GitLab has a "Web Terminal" feature: https://docs.gitlab.com/ci/interactive_web_terminal/ though not available on shared runners (e.g. Salsa CI). There are similar open tickets for Salsa CI: https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/363 https://salsa.debian.org/salsa/support/-/issues/148 We waste far too much time investigating CI failures, rather than actual regressions. Many times in LTS/ELTS I saw tests disabled rather than being investigated due to time constraints, sometimes missing regressions. I believe this would be a killer feature and contribute to attract people to Debusine.