Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
  • This project
    • Loading...
  • Sign in / Register
GitLab Community Edition
GitLab Community Edition
  • Overview
    • Overview
    • Details
    • Activity
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
    • Locked Files
  • Issues 10,410
    • Issues 10,410
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 551
    • Merge Requests 551
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • GitLab.org
  • GitLab Community EditionGitLab Community Edition
  • Issues
  • #24197

Closed
Open
Opened Nov 04, 2016 by Mark Pundsack@markpundsack 
  • Report abuse
  • New issue
Report abuse New issue

Smart deploy, simplify the .gitlab-ci.yml syntax by assuming Kubernetes

Description

Deploying via shell scripts is powerful in that it's incredibly flexible, but sometimes it's too cumbersome, ugly, or not functional enough. We need a higher-level construct, especially for deploys, that let's developers easily configure common deployment scenarios.

Proposal

  • Introduce specific keywords for various deployment scenarios such as kubernetes, ideally through extensible plugins (#14178).
  • The deploy plugin may run in the context of the GitLab rails server rather than the GitLab runner. There are various pros and cons to this.
    • Running in Rails allows access to deployment variables without having to expose them to the runners.
    • Running in Rails allows easier return of richer information than simple pass/fail exit code. e.g. return information needed for connecting a terminal to a container. (Runners could support this, but we'd have to extend the API)
    • Plugins running in Rails might be more approachable than writing in Go.
  • Either way, the plugin would be able to directly connect services via API without needing scripts or CLIs.
  • Plugins could be tightly tied to Services to provide the ability to store variables or otherwise configure deployment at a project level (#23859)
  • Richer interactions could allow actions beyond simple deployment such as:
    • access a terminal that connects to running environments
    • smart monitoring of deployments
    • incremental/rolling deploys, canary deploys, blue/green deploys, traffic vectoring, etc.
    • simplifying closing environments
    • restart/pause/etc of environments
  • The obvious downside is that this would be GitLab-specific, and up to us to maintain as things change.
review_app:
   kubernetes:
     pod: my/pod/file
   variables:
     MY_APP_DOMAIN: review-$DOMAIN.app.com
  environment:
    name: review/$APP

Links / references

  • From #22864 (comment 16790373) and #23286 (closed)
  • GitLab Runner plugins: #14178

/cc @ayufan

Related issues

Assignee
Assign to
Epic
Backlog
Milestone
Backlog
Assign milestone
Time tracking
None
Due date
No due date
4
Labels
CI/CD deploy direction feature proposal
Assign labels
  • View project labels
Reference: gitlab-org/gitlab-ce#24197