This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
StatusAuthorsCoachDRIsOwning StageCreated
proposed devops verify -

GitLab CI Events Proposal 1: Using the .gitlab-ci.yml file

Currently, we have two proof-of-concept (POC) implementations:

They both have similar ideas;

  1. Find a new CI Config syntax to define the pipeline events.

    Example 1:

     workflow:
   events:
     - events/package/published

 # or

 workflow:
   on:
     - events/package/published

    Example 2:

     spec:
   on:
     - events/package/published
     - events/package/removed
   # on:
   #   package: [published, removed]
 ---
 do_something:
   script: echo "Hello World"
  2. Upsert an event to the database when creating a pipeline.
  3. Create EventStore subscriptions to handle the events.

Problems & Questions

  1. The CI config of a project can be anything;
    • .gitlab-ci.yml by default
    • another file in the project
    • another file in another project
    • completely a remote/external file

    How do we handle these cases?

  2. Since we have these problems above, should we keep the events in its own file? (.gitlab-ci-events.yml)
  3. Do we only accept the changes in the main branch?
  4. We try to create event subscriptions every time a pipeline is created.
  5. Can we move the existing workflows into the new CI events, for example, merge_request_event?