blob: ad76b7f8dd4f829a036d76fed8ff6cf79946036a (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
|
---
owning-stage: "~devops::verify"
description: 'GitLab CI Events Proposal 3: Using the .gitlab/ci/events folder'
---
# GitLab CI Events Proposal 3: Using the `.gitlab/ci/events` folder
We can also approach this problem by creating separate files for events.
Let's say we'll have the `.gitlab/ci/events` folder (or `.gitlab/workflows/ci`).
We can define events in the following format:
```yaml
# .gitlab/ci/events/package-published.yml
spec:
events:
- name: package/published
---
include:
- local: .gitlab-ci.yml
with:
event: $[[ gitlab.event.name ]]
```
And in the `.gitlab-ci.yml` file, we can use the input;
```yaml
# .gitlab-ci.yml
spec:
inputs:
event:
default: push
---
job1:
script: echo "Hello World"
job2:
script: echo "Hello World"
job-for-package-published:
script: echo "Hello World"
rules:
- if: $[[ inputs.event ]] == "package/published"
```
When an event happens;
1. We'll enqueue a new job for the event.
1. The job will search for the event file in the `.gitlab/ci/events` folder.
1. The job will run `Ci::CreatePipelineService` for the event file.
## Problems & Questions
1. For every defined event run, we need to enqueue a new job.
1. Every event-job will need to search for files.
1. This would be only for the project-scope events.
1. This can be inefficient because of searching for files for the project for every event.
|
