make the project-specific CI-configuration a first-class CItizen.
<!--IssueSummary start-->
<details>
<summary>
Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards.
</summary>
- [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=232787)
</details>
<!--IssueSummary end-->
### Summary
The default CI-configuration `.gitlab-ci.yml` can be overridden on a per-project basis (and this override can be seeded via an instance-wide setting).
While the actual CI-job takes the override into account, it is ignored by other tasks, e.g. the enhanced WebIDE for the CI-configuration.
I first noted this on my self-hosted Gitlab-Omnibus-13.2.1 instance, but the problem persists on the gitlab.com instance.
Sidenote: On my self-hosted instance, there's a system-wide "Default CI configuration path" override, so most users don't use the default ~~`.gitlab-ci.yml`~~
### Steps to reproduce
- (create a new project)
- configure your project to use a custom CI-configuration path (say: `.git-ci/gitlab-ci.yml`)
- add a valid CI-configuration file as `.git-ci/gitlab-ci.yml` to your project.
- the CI should start a pipeline (and hopefully succeed)
- via the webinterface browse to the `.git-ci/gitlab-ci.yml` file
- notice that the WebIDE does not recognize the file as a CI-configuration
### Example Project
i also set up an example project here on gitlab.com: https://gitlab.com/umlaeute/testing
- the project is configured to use [/.git-ci/gitlab-ci.yml](https://gitlab.com/umlaeute/testing/-/blob/ac015222f4fe7c394aaa7a1e3c9fddedcf6d3a64/.git-ci/gitlab-ci.yml) as the CI-configuration, which it does (as can be seen by it's [corresponding pipeline](https://gitlab.com/umlaeute/testing/-/pipelines/171957960)).
- there is also a file [/.gitlab-ci.yml](https://gitlab.com/umlaeute/testing/-/blob/ac015222f4fe7c394aaa7a1e3c9fddedcf6d3a64/.gitlab-ci.yml) which just happens to be there and have that name. but it's nowhere used (the job would just fail)
### What is the current *bug* behavior?
Opening the project's [**configured and active** CI-configuration](https://gitlab.com/umlaeute/testing/-/blob/ac015222f4fe7c394aaa7a1e3c9fddedcf6d3a64/.git-ci/gitlab-ci.yml) in a browser, the WebIDE just does YAML syntax highlighting.
Browsing to the [/.gitlab-ci.yml](https://gitlab.com/umlaeute/testing/-/blob/ac015222f4fe7c394aaa7a1e3c9fddedcf6d3a64/.gitlab-ci.yml) file (which is nowhere used as a CI-configuration; it just happens to be there), i see `This GitLab CI configuration is valid.` and when starting the WebIDE i get autocompletion suggestions.
However, this file is **not** a GitLab CI configuration (in my context) - the *other file* is.
### What is the expected *correct* behavior?
the currently configured CI-configuration file [.git-ci/gitlab.yml](https://gitlab.com/umlaeute/testing/-/blob/ac015222f4fe7c394aaa7a1e3c9fddedcf6d3a64/.git-ci/gitlab-ci.yml) should be linted as a GitLab CI configuration file.
whether `.gitlab-ci.yml` should *also* be linted is up to your discretion.
### related
see also https://gitlab.com/gitlab-org/gitlab/-/issues/232779, which - at least judging from the wording - will only target the literal `/.gitlab-ci.yml` file instead of the project's CI-configuration.
issue