blob: 7dfc3873ada42d7ffb21b611431c76b7112f276b (
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
|
---
owning-stage: "~devops::verify"
description: 'GitLab CI Events Proposal 1: Using the .gitlab-ci.yml file'
---
# GitLab CI Events Proposal 1: Using the `.gitlab-ci.yml` file
Currently, we have two proof-of-concept (POC) implementations:
- [GitLab CI Workflows PoC](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91244)
- [PoC NPM CI events](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111693)
They both have similar ideas;
1. Find a new CI Config syntax to define the pipeline events.
Example 1:
```yaml
workflow:
events:
- events/package/published
# or
workflow:
on:
- events/package/published
```
Example 2:
```yaml
spec:
on:
- events/package/published
- events/package/removed
# on:
# package: [published, removed]
---
do_something:
script: echo "Hello World"
```
1. Upsert an event to the database when creating a pipeline.
1. Create [EventStore subscriptions](../../../development/event_store.md) to handle the events.
## Problems & Questions
1. The CI config of a project can be anything;
- `.gitlab-ci.yml` by default
- another file in the project
- another file in another project
- completely a remote/external file
How do we handle these cases?
1. Since we have these problems above, should we keep the events in its own file? (`.gitlab-ci-events.yml`)
1. Do we only accept the changes in the main branch?
1. We try to create event subscriptions every time a pipeline is created.
1. Can we move the existing workflows into the new CI events, for example, `merge_request_event`?
|
