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,437
    • Issues 10,437
    • 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
  • #28566

Closed
Open
Opened Feb 22, 2017 by Mark Pundsack@markpundsack 
  • Report abuse
  • New issue
Report abuse New issue

Dependency checking

Debian has a security fix for openSSH. Organizations without GitLab walk into the office and see that 1000 applications need to be updated. Organizations with GitLab walk into the office and see that 999 applications were updated successfully and 1 had to be rolled back. We can do this because we have monitoring integrated into GitLab, we're not deploying into a black hole but can see if the application still meets the service level objectives.

Have a story version of the vision on the direction page.

  1. Start with container scheduler.
  2. Use web terminal and local editor to create something.
  3. See auto deploy with automatic parallel tests and review apps.
  4. Debian package used in your container has a security fix.
  5. GitLab auto detects you have that dependency and creates a new build.
  6. The changelog is updated automatically.
  7. In the merge request you can see the metrics and SLO (service level objective) was not met and after deploying to 1% it was reverted.
  8. All this happened automatically after Debian pushed to stable.
  9. Luckily when you check the next day your application is not vulnerable.
  10. So you use chat to close the issue that was automatically opened after the failed deploy.
  11. An early user of your service also emailed GitLab service desk to ask if the Debian security update is addressed.
  12. You create a blog post via the web terminal that is published with GitLab pages.

I'm not sure this should go on the direction page as it's severely overloaded already, but explaining our vision by using a story/flow is an effective tool.

/cc @sytses

Links

  • [meta] VersionEye integration
  • New site: shield.gitlab.com
  • GitLab License finder
  • VersionEye - Display in Merge requests list view
  • VersionEye - Display information in the Merge request details view
  • VersionEye - Display in Commits list view
  • VersionEye - Add option to activate GitLab Version Service to the administration panel of a repository
  • VersionEye - Settings panel for GitLab Version Service
  • Prior art: https://depfu.io/
Edited Sep 22, 2017 by Sid Sijbrandij

Related issues

Assignee
Assign to
Epic
Next 7-13 releases
Milestone
Next 7-13 releases
Assign milestone
Time tracking
None
Due date
No due date
5
Labels
CI/CD GitLab Premium direction meta moonshots
Assign labels
  • View project labels
Reference: gitlab-org/gitlab-ce#28566