This is a separate use case from #15790 (closed) (which applies to canceled jobs). This applies to jobs which time-out, rather than being intentionally canceled by the user.
Problem
If a job times out before completion, the artifacts are not available. The user does not have information on 1) where the job stopped and 2) any test failures.
This issue's description does not seem to have a section for "Implementation Guide".
Please consider adding one, because it makes a big difference for contributors.
This section can be brief but must have clear technical guidance, like:
Hints on lines of code which may need changing
Hints on similar code/patterns that can be leveraged
Suggestions for test coverage
Ideas for breaking up the merge requests into iterative chunks
If a job times out before completion, the logs are not available. The user does not have information on 1) where the job stopped and 2) any test failures.
@jocelynjane is this referring to artifacts, or logs? As far as I'm aware, if the job times out, the logs are still visible.
Contributions like this are vital to help make GitLab a better product.
We would be grateful for your help in verifying whether your bug report requires further attention from the team. If you think this bug still exists, and is reproducible with the latest stable version of GitLab, please comment on this issue.
This issue has been inactive for more than 12 months now and based on the policy for inactive bugs, will be closed in 7 days.
Thanks for your contributions to make GitLab better!
@shampton do you know if there is a difference between canceled and timed-out from the runner POV? I'm wondering if the same solution applies to both this and #15790 (closed).
@jocelynjane@shampton Timeout is harder because it happens when the job stops talking to the server, unlike cancel where there is still an open line of communication. So we separated them into two separate issues to tackle.
But ideally, both would benefit from artifacts being uploaded and after_script being called.