### Summary When `spec:include:local` is used in a `gitlab-ci.yml` configuration file, it should reference the repository where the 'local' file is located but it currently references the calling repository. When `repoA` uses `spec:include:local`, the pipeline should look for a file inside `repoA` that matches the specified path. This is supported by the current documentation [`include:local`](https://docs.gitlab.com/ci/yaml/#includelocal): > Use `include:local` to include a file that is in the same repository and branch as the configuration file containing the `include` keyword. Use `include:local` instead of symbolic links. The recently added `spec:include:local` functionality should function the same as `include:local`. This is also supported by the current documentation [`spec:include`](https://docs.gitlab.com/ci/yaml/#specinclude) because this documentation links to the `include:local` documentation for how the `local` include type works: > Supports [`local`](https://docs.gitlab.com/ci/yaml/#includelocal), [`remote`](https://docs.gitlab.com/ci/yaml/#includeremote), and [`project`](https://docs.gitlab.com/ci/yaml/#includeproject) include types. Does not support `template`, `component`, or `artifact` includes. ### Steps to reproduce 1. Create a 'downstream' repo. 2. Create an 'upstream' repo. 3. In the 'upstream' repo: 1. Create a 'shared inputs' file (`shared-inputs.yml`) that has several inputs (with default values for testing purposes). 2. Create a gitlab-ci templated file (`entrypoint.gitlab-ci.yml`) that other repos can point to that references the 'shared inputs' file with `spec:include:local`. 3. Create a '.gitlab-ci.yml' file that includes the `entrypoint.gitlab-ci.yml` file with `include:local` to show the pipeline configuration of the `entrypoint.gitlab-ci.yml` file is valid. 4. In the 'downstream' repo: 1. Create a '.gitlab-ci.yml' file that includes a gitlab-ci templated file (`entrypoint.gitlab-ci.yml`) from the 'upstream' repo. 2. When the pipeline tries to run, **it will throw an error:** `'entrypoint.gitlab-ci.yml': Local file 'shared-inputs.yml' does not exist!` ### Example Project This bug was identified on a managed gitlab. An example project was created to show the issue. #### Downstream repo (`bug-test-repo`) [bug-test-repo](https://gitlab.com/calebcook-public/bug-test-repo) is the 'downstream' repo. The only thing in this project is the `.gitlab-ci.yml` file: ```yaml # bug-test-repo/.gitlab-ci.yml include: - project: calebcook-public/bug-test-pipeline ref: main file: entrypoint.gitlab-ci.yml ``` #### Upstream repo (`bug-test-pipeline`) [bug-test-pipeline](https://gitlab.com/calebcook-public/bug-test-pipeline) is the 'upstream' repo. This project has three files; `.gitlab-ci.yml`, `shared-inputs.yml`, and `entrypoint.gitlab-ci.yml`. ```yaml # bug-test-pipeline/.gitlab-ci.yml include: - local: entrypoint.gitlab-ci.yml ``` ```yaml # bug-test-pipeline/shared-inputs.yml inputs: test_str: type: string default: "this is a string" # several more inputs are included for testing purposes # this includes 'test_choice', 'test_arr', 'test_num', 'test_bool', and 'test_rules' # all of the inputs in this file have default values set ``` ```yaml # bug-test-pipeline/entrypoint.gitlab-ci.yml spec: include: - local: shared-inputs.yml --- test-job: stage: test script: - echo "test job" - echo "INPUTS" - echo " test_str='$[[ inputs.test_str ]]'" - echo " test_choice='$[[ inputs.test_choice ]]'" - echo " test_arr='$[[ inputs.test_arr ]]'" - echo " test_num='$[[ inputs.test_num ]]'" - echo " test_bool='$[[ inputs.test_bool ]]'" - echo " test_rules='$[[ inputs.test_rules ]]'" ``` ### What is the current *bug* behavior? When a project (`repoA`) references a configuration file from another repo (`repoZ`) that uses `spec:include:local`, it looks for the file in `repoA`. If the `repoZ` configuration file included the `shared-inputs.yml` with `spec:include:local`, then `repoA` would look for that file locally. ### What is the expected *correct* behavior? When a project (`repoA`) references a configuration file from another repo (`repoZ`) that uses `spec:include:local`, it looks for the file in `repoZ`. If the `repoZ` configuration file included the `shared-inputs.yml` with `spec:include:local`, then `repoA` would look for that file in `repoZ`. ### Relevant logs and/or screenshots Refer to the 'Example Project' section for the setup of test repos. #### Upstream repo (`bug-test-pipeline`) When the pipeline attempts to run for the upstream project [`bug-test-pipeline`](https://gitlab.com/calebcook-public/bug-test-pipeline), there are no problems and the pipeline runs successfully. All of the inputs are correctly ingested and print out the expected default values. This can be seen with [Job #15500933420](https://gitlab.com/calebcook-public/bug-test-pipeline/-/jobs/15500933420) {width=398 height=117} #### Downstream repo (`bug-test-repo`) When the pipeline attempts to run for the downstream project [`bug-test-repo`](https://gitlab.com/calebcook-public/bug-test-repo), there are configuration problems. The pipeline **DOES NOT** run because it is looking for the `shared-inputs.yml` file locally in the downstream project (`bug-test-repo`). It throws a configuration error: **Unable to run pipeline: `entrypoint.gitlab-ci.yml`: Local file `shared-inputs.yml` does not exist** {width=582 height=287} ### Output of checks This bug happens on GitLab.com <!-- or follow up with an issue comment of `@gitlab-bot label ~"reproduced on GitLab.com"` if you do not --> #### Results of GitLab environment info <!-- Input any relevant GitLab environment information if needed. --> N/A - run on gitlab.com with no custom configuration [Job #15500933420](https://gitlab.com/calebcook-public/bug-test-pipeline/-/jobs/15500933420) #### Results of GitLab application Check N/A - run on gitlab.com with no custom configuration [Job #15500933420](https://gitlab.com/calebcook-public/bug-test-pipeline/-/jobs/15500933420) ### Possible fixes <!-- If you can, link to the line of code that might be responsible for the problem. --> *I'm not sure where in the codebase the `spec:include:local` is implemented.* ### Patch release information for backports *I'm not sure if the bug fix needs to be backported in a patch release.* If the bug fix needs to be backported in a [patch release](https://handbook.gitlab.com/handbook/engineering/releases/patch-releases) to a version under [the maintenance policy](https://docs.gitlab.com/policy/maintenance/), please follow the steps on the [patch release runbook for GitLab engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/engineers.md). Refer to the [internal "Release Information" dashboard](https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1) for information about the next patch release, including the targeted versions, expected release date, and current status. #### High-severity bug remediation *This is likely not a high-severity bug.* To remediate high-severity issues requiring an [internal release](https://handbook.gitlab.com/handbook/engineering/releases/internal-releases/) for single-tenant SaaS instances, refer to the [internal release process for engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/internal-releases/engineers.md?ref_type=heads). <!-- If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"` -->