blob: 5f10ba1fbb2fbcbbbaab6b0f0157b2e40f76cc1d (
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
65
66
67
68
69
70
71
72
73
|
---
owning-stage: "~devops::verify"
description: 'GitLab CI Events Proposal 4: Creating events via CI files'
---
# GitLab CI Events Proposal 4: Creating events via CI files
Each project can have its own event configuration file. Let's call it `.gitlab-ci-event.yml` for now.
In this file, we can define events in the following format:
```yaml
events:
- package/published
- issue/created
```
When this file is changed in the project repository, it is parsed and the events are created, updated, or deleted.
This is highly similar to [Proposal 1](proposal-1-using-the-gitlab-ci-file.md) except that we don't need to
track pipeline creations every time.
1. Upsert events to the database when `.gitlab-ci-event.yml` is updated.
1. Create [EventStore subscriptions](../../../development/event_store.md) to handle the events.
## Filtering jobs
We can filter jobs by using the `rules` keyword. For example:
```yaml
test_package_published:
script: echo testing published package
rules:
- events: ["package/published"]
test_package_removed:
script: echo testing removed package
rules:
- events: ["package/removed"]
```
Otherwise, we can make it work either a CI variable;
```yaml
test_package_published:
script: echo testing published package
rules:
- if: $CI_EVENT == "package/published"
test_package_removed:
script: echo testing removed package
rules:
- if: $CI_EVENT == "package/removed"
```
or an input like in the [Proposal 3](proposal-3-using-the-gitlab-ci-events-folder.md);
```yaml
spec:
inputs:
event:
default: push
---
test_package_published:
script: echo testing published package
rules:
- if: $[[ inputs.event ]] == "package/published"
test_package_removed:
script: echo testing removed package
rules:
- if: $[[ inputs.event ]] == "package/removed"
```
|
