realaravinth/debian-mirror-gitlab
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
debian-mirror-gitlab/doc/architecture/blueprints/gitlab_ci_events/index.md
Pirate Praveen 271ccb9124 New upstream version 16.0.7+ds1
2023-07-09 08:55:56 +05:30

2.8 KiB
Raw Blame History

status creation-date authors coach approvers owning-stage participating-stages
proposed 2023-03-15
@furkanayhan
@grzesiek
@jreporter
@cheryl.li
~devops::verify
~devops::package
~devops::deploy

GitLab CI Events

Summary

In order to unlock innovation and build more value, GitLab is expected to be the center of automation related to DevSecOps processes. We want to transform GitLab into a programming environment, that will make it possible for engineers to model various workflows on top of CI/CD pipelines. Today, users must create custom automation around webhooks or scheduled pipelines to build required workflows.

In order to make this automation easier for our users, we want to build a powerful CI/CD eventing system, that will make it possible to run pipelines whenever something happens inside or outside of GitLab.

A typical use-case is to run a CI/CD job whenever someone creates an issue, posts a comment, changes a merge request status from "draft" to "ready for review" or adds a new member to a group.

To build that new technology, we should:

  1. Emit many hierarchical events from within GitLab in a more advanced way than we do it today.
  2. Make it affordable to run this automation, that will react to GitLab events, at scale.
  3. Provide a set of conventions and libraries to make writing the automation easier.

Goals

While "GitLab Events Platform" aims to build new abstractions around emitting events in GitLab, "GitLab CI Events" blueprint is about making it possible to:

  1. Define a way in which users will configure when an event emitted will result in a CI pipeline being run.
  2. Describe technology required to match subscriptions with events at GitLab.com scale and beyond.
  3. Describe technology we could use to reduce the cost of running automation jobs significantly.

Proposals

For now, we have technical 4 proposals;

  1. Proposal 1: Using the .gitlab-ci.yml file Based on;
  2. Proposal 2: Using the rules keyword Highly inefficient way.
  3. Proposal 3: Using the .gitlab/ci/events folder Involves file reading for every event.
  4. Proposal 4: Creating events via CI files Combination of some proposals.

Each of them has its pros and cons. There could be many more proposals and we would like to discuss them all. We can combine the best part of those proposals and create a new one.