Interactive web terminals

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. Because 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 the gitlab-runner Helm chart. They are enabled when:

• The number of replicas is one
• You use the loadBalancer service

Support for fixing these limitations is tracked in the following issues:

• Support of more than one replica
• Support of more service types

Debugging a running job

Prerequisites:

• You must have the Developer, Maintainer, or Owner role for the project.
• You must have started the job. No role grants access to the terminal of a job started by another user. For more information, see CI/CD permissions.

Sometimes, when a job is running, things don’t go as you expect. It would be helpful if one can have a shell to aid debugging. When a job runs, the right panel displays a debug button ( ) that opens the terminal for the current job.

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 your terminal is open after the job completes, the job doesn’t finish until after the configured [session_server].session_timeout duration. To avoid this, you can close the terminal after the job finishes.