Skip to content

GitLab Next

    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Menu
    Projects Groups Snippets
  • Sign up now
  • Login
  • Sign in / Register
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 43,111
    • Issues 43,111
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1,369
    • Merge requests 1,369
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.org
  • GitLabGitLab
  • Issues
  • #5426
Closed
Open
Created Mar 23, 2018 by James Ramsay (ex-GitLab)@jramsay-gitlab🔴Contributor

Open Web Terminal from attached CI runner in Web IDE

When the Web IDE is opened by a maintainer a job defined in the .gitlab-ci.yml should be run from the current commit to launch a live environment and attached to the Web IDE so that it is ready to receive commands from the Web IDE to run linters, code formatters or tests.

The full value of this feature won't be available until changes from the Web IDE are mirrored to the CI runner. This is the smallest iteration that provides incremental benefits allowing the user access to a REPL, and allows them to commit their changes and then test the change immediately rather than waiting for the whole suite to execute. We intend to immediately follow this feature with https://gitlab.com/gitlab-org/gitlab-ee/issues/5276 to make this workflow much much better. Also, it highly probable that this first iteration can't be enabled in production while changes are being made to the CI runner in parallel, which means that the first publicly accessible version will have mirroring anyway.

Proposal

Following investigation from https://gitlab.com/gitlab-org/gitlab-ee/issues/5281

If a web-ide job is defined in the .gitlab-ci.yml and a runner is available, a button should be shown offering the user should be able to open the web terminal and start the job.

When using the web terminal, it should be possible to:

  • start/stop/restart the web terminal
  • resize the web terminal

Designs

Pane expanded (all good) Pane expanded (not configured) Pane expanded (no runners available)
expanded-stopped how-to-configure configure-runner
Terminal Starting... Terminal Started Restart prompt (when changing branch or modifying config)
expanded-starting expanded-started restart-prompt

Links

https://gitlab.com/gitlab-org/gitlab-ee/issues/5281

User Stories

The Web IDE loads

  • The terminal button won't appear if the license feature is not present

User clicks the terminal button

  • If no proper web-ide job is present in the .gitlab_ci.yml file then we show a message to the user with a hint about how to configure it. Note: in the description says that we won't show the button in this case, but this way we can show the user how to configure the feature.

    • When the user changes the branch, we have to check the config file again and show the proper message in the tab
    • Edge case: User modifies the config file through the web editor. We have to choices to handle this:
      • Allow the user to click the Start Terminal button with no action. (The backend will raise an error)
      • After each commit check if the config file is valid. But if we have already a terminal running, what should be the output in this case?
  • If no proper runner is available we show a message in the tab (like the one we show when there are no pipelines in the pipeline's tab).

    • We will poll the runners' endpoint to check if there are any of them available. Besides, it also helps if we are running a terminal and the runner, for whatever reason, is not available anymore. We can also avoid creating builds that are going to be stuck because of it.
  • The Start Terminal button will be present if all the conditions are met.

User clicks the Start Terminal button

  • We'll send a call to create the build and we'll get the build info.
  • We'll start polling the jobs endpoint to watch the job's state:
    • If the job is in pending state we will show a message.
      • The Stop button will be shown to allow the user to perform this action over the terminal job.
      • If the job is stuck (in pending state) for a long time, cancel it?
    • If the job is in running state we'll launch the terminal.
      • The Stop button will be shown to allow the user to perform this action over the terminal job.
    • If the job state is different than running or pending means that it has finished.
      • We destroy the terminal.
      • Show the Restart Terminal button.

User clicks the Stop Terminal button

  • We'll send a request to cancel the job.
  • The terminal component will be destroyed.
  • The Restart Terminal button we'll be shown if all the requirements are met.

User clicks the Restart Terminal button

  • We'll send a request to retry the job.
  • We'll start polling the job to watch the state.
  • The buttons Stop Terminal will be visible.
Edited Oct 03, 2018 by Jeethu Karthik
Assignee
Assign to
Time tracking