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 2: Using the rules
keyword
Can we do it with our current rules
system?
workflow:
rules:
- events: ["package/*"]
test_package_published:
script: echo testing published package
rules:
- events: ["package/published"]
test_package_removed:
script: echo testing removed package
rules:
- events: ["package/removed"]
- We don’t upsert anything to the database.
- We’ll have a single worker which subcribes to events
like
store.subscribe ::Ci::CreatePipelineFromEventWorker, to: ::Issues::CreatedEvent
. - The worker just runs
Ci::CreatePipelineService
with the correct parameters, the rest will be handled by therules
system. Of course, we’ll need modifications to therules
system to supportevents
.
Problems & Questions
- For every defined event run, we need to enqueue a new
Ci::CreatePipelineFromEventWorker
job. - The worker will need to run
Ci::CreatePipelineService
for every event run. This may be costly because we go through every cycle ofCi::CreatePipelineService
. - This would be highly inefficient.
- Can we move the existing workflows into the new CI events, for example,
merge_request_event
?