SSH for all failed builds by default
N
Nico Schloemer
A frequent peeve for me is that I have a failed test and need to SSH into it to see what’s wrong. For this, I’ll have to rebuild it all over again which may take a while.
Suggestion:
Enable SSH on all builds, close immediately if the test succeeds and keep open for a little while (say 5 mins) if it fails, and 1 hr if the SSH connection is actually used.
CCI-I-457
Aidan Carson
Any updates here?
Y
Yury Lvov
Yes. We want it too! In most cases once our UI tests fail during ordinary build, we rebuild it with ssh so we can access logs, page snapshots etc. However it always succeeds with ssh, and we cannot debug!
N
Nathan Dintenfass
That's fair feedback -- in this case there are very few SSH rebuilds across all builds, but adding a few minutes on to EVERY build would be a big enough hit that we'd likely need to change pricing to reflect that somehow. We're now looking into whether we can make this an option on our usage-based plans, allowing project owners to decide their own cost/benefit analysis.
N
Nico Schloemer
> One issue is that SSH rebuilds are relatively expensive because they need to be kept open.
I would have thought that keeping a port open for a short while is less expensive than all the repeated "builds with ssh" that have to be done because of the absence of this feature. But that's only my personal perspective. It certainly _is_ more expensive for me as a user.
T
Tim Schindler
I think there could be a configurable option so you can enable this feature for specific builds on demand where you already know you need it. No need IMO to enable this by default for just everything. Further, I am not sure how resource efficient it is to let people spawn twice as much workloads in order to get SSH access.
N
Nathan Dintenfass
One issue is that SSH rebuilds are relatively expensive because they need to be kept open. Having all failed jobs linger for extra time would become a non-trivial cost that we'd likely have to price in somehow. Also, as we move towards making usage-based pricing widely available, such extra compute would also directly burn credits that many would not want. It's possible we'd make it some kind of opt-in at the configuration or project level for those who would want to spend the extra credits or container queuing risk to keep these jobs open.
T
Tim Schindler
A big +1 on that. My current favourite with debugging e2e tests nowadays is to wait an hour to see them fail and then rerun them again with SSH enabled and wait another hour in order to actually be able to debug the thing. Hashtag fun at work.
P
Paul Ecclestone
+1 for me, this would be incredibly handy, right now it just wastes time having to re-run just to get SSH enabled.