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.
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;
-
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"
- Upsert a workflow definition to the database when new configuration gets pushed.
- Match subscriptions and publishers whenever something happens at GitLab.
Discussion
- How to efficiently detect changes to the subscriptions?
- How do we handle differences between workflows / events / subscriptions on different branches?
- Do we need to upsert subscriptions on every push?