I can't seem to find the most obvious CI feature that one ever needs from such a tool: run a project pipeline after another project's pipeline has finished. You can do it with trigger but only for downstream triggering, which is the opposite of what you want in case you have a project that is a core dependency of 20 other projects which all need to be rebuilt.
What you need in this case is to be able to define something like:
Project A: nothing particular, just a normal pipeline
Project B, that "depends" on project A:
.gitlab-ci.yml
from_upstream:
stage: pre
trigger:
project: ProjectA
What it does is trigger ProjectB build whenever a ProjectA pipeline has [successfully] finished.
Instead you must declare all dozens of downstreams in ProjectA in a similar fasion, which is silly and counter-productive, especially when ProjectA is a core library that gets constantly reused everywhere.
So, can someone please explain why GitlabCI is missing an obvious feature (which isn't available even in EE) that has been in Bamboo and Hudson/Jenkins for decades? And how do i do what i need with Gitlab-CI?
UPDATE: It seems the notion of upstream/downstream is really confusing for some people, so just to clarify: upstream Project A is and must always be decoupled from downstream Project B because separation of concern is a thing and upstream maintainers couldn't and shouldn't possibly have any knowledge on how their project is used downstream.
So, desired functionality (which, again, exists for decades in Bamboo and Jenkins) is that downstream pipelines declare passive triggers on upstream pipelines, not the other way around with active triggers as it's currently implemented in Gitlab-CI.