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. The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
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 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 a workflow definition to the database when new configuration gets pushed.
  3. Match subscriptions and publishers whenever something happens at GitLab.

Discussion

  1. How to efficiently detect changes to the subscriptions?
  2. How do we handle differences between workflows / events / subscriptions on different branches?
  3. Do we need to upsert subscriptions on every push?