Interactive web terminals All tiers All offerings
Introduced in GitLab 11.3.
Interactive web terminals give the user access to a terminal in GitLab for running one-off commands for their CI pipeline. You can think of it like a method for debugging with SSH, but done directly from the job page. Since this is giving the user shell access to the environment where GitLab Runner is deployed, some security precautions were taken to protect the users.
Configuration
Two things need to be configured for the interactive web terminal to work:
- The runner needs to have
[session_server]
configured properly - If you are using a reverse proxy with your GitLab instance, web terminals need to be enabled
Partial support for Helm chart
Interactive web terminals are partially supported in gitlab-runner
Helm chart.
They are enabled when:
- The number of replica is one
- You use the
loadBalancer
service
Support for fixing these limitations is tracked in the following issues:
Debugging a running job
docker
executor does not keep running
after the build script is finished. At that point, the terminal automatically
disconnects and does not wait for the user to finish. Follow
this issue for updates on
improving this behavior.Sometimes, when a job is running, things don’t go as you would expect, and it
would be helpful if one can have a shell to aid debugging. When a job is
running, on the right panel you can see a button debug
that opens the terminal
for the current job. Only the person who started a job can debug it.
When selected, a new tab opens to the terminal page where you can access the terminal and type commands like in a standard shell.
If you have the terminal open and the job has finished with its tasks, the
terminal blocks the job from finishing for the duration configured in
[session_server].session_timeout
until you
close the terminal window.
Interactive web terminals for the Web IDE
To run interactive web terminals for the Web IDE, see Web IDE.