Should Salsa CI be a pure conduit for other tests or its own test env?

One of the things I've been thinking about since salsa launched is the relationship between salsa's gitlab-ci and the rest of the Debian. I see two good directions we can go:

1. make salsa-ci purely a conduit for all the existing tools in Debian (gbp, lintian, piuparts, etc) with no customization related to GitLab-CI allowed, only what is exposed as variables by something like salsa-ci-team/pipeline.
2. make Debian workflows fit more into the GitLab workflow, and let Debian Developers freely use GitLab CI for custom scripts, etc.

salsa-ci-team/pipeline is looking like a good candidate for the first case, with centralized management via the config include and way that each job's script can't be changed in the .gitlab-ci.yml. I've been using salsa-ci-team/ci-image-git-buildpackage to explore the second case. If we want to offer Debian Developer's the full flexibility of GitLab CI on its own, then salsa-ci-team/pipeline looks quite hard to workaround because it is not based around bash scripts like GitLab CI jobs usually are.

Here's one small example of a test that falls outside of the normal Debian tools, (but perhaps could be handled better elsewhere): https://salsa.debian.org/android-tools-team/android-platform-system-core/blob/master/debian/.gitlab-ci.yml