Skip to content

GitLab Next

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
GitLab
GitLab
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 34,951
    • Issues 34,951
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 1,268
    • Merge Requests 1,268
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Metrics
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • GitLab.org
  • GitLabGitLab
  • Issues
  • #207128

Closed
Open
Opened Feb 18, 2020 by Olivier Gonzalez@gonzoyumoDeveloper0 of 2 tasks completed0/2 tasks

Replace x-y-stable docker images with major tag for Security Products

Problem to solve

For some of our tools (SAST, Dependency Scanning, License Management) the current process implies to release a new x-y-stable docker image tag every month when there is a new version of GitLab. All these x-y-stable images are actually using a Major tag under the hood.

This process has a maintenance cost with no particular benefit now that we have the vendored templates shipping within the GitLab rails application. So we want to get rid of it.

Intended users

  • Delaney (Development Team Lead)
  • Sasha (Software Developer)
  • Devon (DevOps Engineer)

Further details

Currently, when we release a new version of a tool:

  1. we publish a new semantic version with a git tag: 1.2.4
  2. we publish a corresponding docker image: sast:1.2.4
  3. we override the corresponding major docker image: sast:1
  4. we override the existing x-y-stable images that are (supposed to be) compatible with that major version: 11-6-stable, 11-7-stable, etc.

And when there is a new monthly release of GitLab we update the CI config to add a new job to publish a corresponding x-y-stable.

For the Analyzers, we have quite a similar process but stop at step #3 and use the major tag that is matching the major version of the tool (SAST, DS). Though, this is also being replaced with the non-DinD approach by now having a dedicated job per analyzer that can directly use their own versions.

Proposal

For DS and SAST, the DinD mode requires to sync the major version of the tool with the major version of the analyzers. With the removal of Dind, this is no longer necessary and each analyzer could then follow their own semantic versioning and have independent Major versions too.

Ask customers to override the job definition to change the version they want to use.

Dependency Scanning

Template: https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/Dependency-Scanning.gitlab-ci.yml

  • deprecate DS_MAJOR_VERSION and directly use the major number here.

SAST

Template: https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml

  • deprecate SAST_ANALYZER_IMAGE_TAG and directly use the major number here.

Container Scanning

Template: https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml

  • deprecate CS_MAJOR_VERSION and directly use the major number here.

License Compliance

Template: https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/License-Scanning.gitlab-ci.yml (and the deprecated https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/License-Management.gitlab-ci.yml)

  • replace $CI_SERVER_VERSION_MAJOR-$CI_SERVER_VERSION_MINOR-stable and directly use the major number here.

Permissions and Security

Documentation

  • ensure documentation states the deprecation of x-y-stable docker images and related env variables and that support will be dropped in %13.0.
  • update the release process doc in https://gitlab.com/gitlab-org/security-products/release

Availability & Testing

This will need thorough testing and make sure that the automated QA is kept compatible.

What does success look like, and how can we measure that?

We publish docker images matching semantic versions of our tools (and just keep pushing x-y-stable images too until we officially drop support for them in %13.0).

What is the type of buyer?

GitLab Ultimate

Links / references

Release post deprecation

Edited Apr 15, 2020 by Lucas Charles
Assignee
Assign to
12.10
Milestone
12.10 (Past due)
Assign milestone
Time tracking
None
Due date
None
Reference: gitlab-org/gitlab#207128