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