Pirate Praveen edb4c77020 New upstream version 14.2.5+ds1

2021-10-27 15:23:28 +05:30

3.3 KiB

Raw Blame History

stage	group	info	type
Verify	Runner	To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments	reference

Interactive Web Terminals

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. 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.

NOTE: Shared runners on GitLab.com do not provide an interactive web terminal. Follow this issue for progress on adding support. For groups and projects hosted on GitLab.com, interactive web terminals are available when using your own group or project runner.

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

NOTE: Interactive web terminals are not yet supported by gitlab-runner Helm chart. Support is tracked in this issue.

Debugging a running job

NOTE: Not all executors are supported.

NOTE: The 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. Please 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.

When clicked, a new tab opens to the terminal page where you can access the terminal and type commands like a normal 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.