Feature request: auto indexing of workspace files

[ATL-Flaneur]

It would be helpful if gitlab-ci-ls automatically processed the files in an includes block.

I'm running gitlab-ci-ls in Zed, and opening a file with an includes block shows errors for jobs defined in the included files and referenced in extends statements. Manually opening the file triggers processing and resolves the error, but this is a lengthy and tedious process in complex CI pipelines.

Another option would be to process all the YAML files in a project, which would allow opening any one and using find all references on a job.

[alesbrelih]

It should be already doing this. I'll install and check Zed integration because there are also other issues like: #387

[alesbrelih]

https://github.com/alesbrelih/gitlab-ci-ls/releases/tag/1.1.10 Should fix the issue with Zed.

remember that diagnostics get refreshed only on save (currently)

[ATL-Flaneur]

That was quick! I updated my Homebrew packages, which bumped gitlab-ci-ls to 1.1.10, and restarted Zed. It's still giving me red squiggles for jobs referenced in extends statements. I'm also getting the Unresolved tag: !reference (YAML 0) error mentioned in #387.

[alesbrelih]

Can you show me how does your includes look like? You can change names to abstract the names if you want.

[ATL-Flaneur]

Maybe it's an issue with directory handling?

The source file is pipelines/standard_node.yml and the include looks like:

include:
  - "terraform/ecs.yml"
  - "docker/build.yml"

[alesbrelih]

Yeah there was a problem with nested includes..

https://github.com/alesbrelih/gitlab-ci-ls/releases/tag/1.1.11

If I understood gitlab correctly this should fix your issues

[ATL-Flaneur]

I've updated my gitlab-ci-ls install and see the same issue. I open pipelines/standard_node.yml and have red squiggles under the extends jobs defined in the included files.

For example, in my pipelines/standard_node.yml, there's the following extends that references a definition in an included file docker/build.yml.

build docker:
  stage: build
  extends: .dockerbuild

Clicking on .dockerbuild gives an error *Rule: .dockerbuild does not exist."

When I open docker/build.yml manually, I can click through to rule .dockerbuild but the red squiggles remain. Saving pipelines/standard_node.yml clears the red squiggles.

[alesbrelih]

Weird, did you reset the language server using star at the bottom of editor? Or reset the IDE?

I tried to replicate your setup here: https://streamable.com/ma1086

Or is it different? How do you open your editor? Is main .gitlab-ci.yml inside your workspace?

[ATL-Flaneur]

Is main .gitlab-ci.yml inside your workspace?

It is not. I'm working in the development-pipelines project, which contains files like pipelines/standard_node.yml for Node.js, pipelines/standard_rust.yml for Rust, and so on. It does not have a .gitlab-ci.yml file at all. It also has files like tests/api_testing.yml for Postman stuff, docker/build.yml for Docker stuff, etc.

Node.js projects have a .gitlab-ci.yml file with:

include:
  - project: 'foo/bar/development-pipelines'
    file: 'pipelines/standard_node.yml'

Rust projects have a .gitlab-ci.yml file with:

include:
  - project: 'foo/bar/development-pipelines'
    file: 'pipelines/standard_rust.yml'

I've tried opening the project with the .gitlab-ci.yml file, but I can't tie the include directive to the pipeline code. That would be very difficult to perform automatically because the paths don't work out easily.

I've killed the language server and restarted Zed repeatedly. Let me know if there's any diagnostic info that would be handy!

[alesbrelih]

Now it makes sense 👍 Also makes sense why you were using pipelines/* approach.

Yeah you were right, this isn't supported yet. But it should be done soon.

[alesbrelih]

Hey, check this out: https://github.com/alesbrelih/gitlab-ci-ls?tab=readme-ov-file#project-level-configuration-gitlab-ci-lsyml

Will something like this be ok?

[ATL-Flaneur]

I'm regularly working on projects that contain CI code but don't have a .gitlab-ci.yml file. If the language server would scan the .yml files in the project and process include: directives, then name resolution should work. For example, a current project has a file pipelines/standard_node.yml that includes pipelines/standard_rules.yml and later has a !reference [.feature_branch_always_rules, rules] statement where .feature_branch_always_rules is defined in standard_rules.yml. Even when I have both standard_node.yml and standard_rules.yml open in Zed, I get red squiggles under !reference [.feature_branch_always_rules, rules].