Change on settings for the LS are not clear on the documentation.

[Msouza91]

Up to 0.7.0 I was able to use the language server with a good setup on Neovim with mason_lsp_config and attach the server to my files. After the recent updates I'm getting some error messages when I try to use it, yet I didn't see any warning about breaking changes.

Neovim Version: 0.9.5
I had the same errors running on ubuntu 23.04 natively and 22.04 on WSL

I installed the LSP from Mason and was running it with this config:

--- Setup Mason LSP Install
require("mason").setup({})
require("mason-lspconfig").setup({
	ensure_installed = {
		"azure_pipelines_ls",
         }
	handlers = {
		lsp.default_setup,
		azure_pipelines_ls = function()
			require("lspconfig").azure_pipelines_ls.setup(my_handlers.azure())
		end,
	},

Here is the handlers config returning the LS options table:

local M = {}
function M.azure()
	local opts = {
		settings = {
			yaml = {
				schemas = {
					["https://raw.githubusercontent.com/microsoft/azure-pipelines-vscode/master/service-schema.json"] = {
						"/azure-pipeline*.y*l",
						"/*.azure*",
						"Azure-Pipelines/**/*.y*l",
						"Pipelines/*.y*l",
						"cap/**/*.y*l",
						"cap/*.y*l",
						"veiling/**/*.y*l",
						"veiling/*.y*l",
					},
				},
			},
		},
	}
	return opts
end
return M

From 0.8.0 onwards I get an assertion error when the nvim lsp client tries to start the language server.

[winstliu]

What is the assertion error you're getting? We didn't knowingly introduce any breaking changes in 0.8.0.

[Msouza91]

The error message is not very descriptive I think, but it happens when the Nvim client tries to attach using these configs on 0.8.0, but works fine on 0.7.0
It only happens when I open a file in which I configured the azure_ls to attach onto and after the update.
If my minimal setup above is not enough to reproduce the error I'll need to take some time on the weekend to narrow it down a little bit.
I edited the original issue to include my neovim version and platforms in which I encountered the error for some extra info.

In the meantime, if there are any loggin or other debug info that I could extract, kindly inform me where to gather it from.

Error  08:54:24 msg_show.lua_error Error executing vim.schedule lua callback: /usr/share/nvim/runtime/lua/vim/lsp.lua:1308: RPC[Error] code_name = InternalError, message = "Request initialize failed with message: [UriError]: Scheme is missing: {scheme: \"\", authority: \"\", path: \"null\", query: \"\", fragment: \"\"}"
stack traceback:
	[C]: in function 'assert'
	/usr/share/nvim/runtime/lua/vim/lsp.lua:1308: in function ''
	vim/_editor.lua: in function <vim/_editor.lua:0>

[Keltirion]

I get the same issue, I've noticed when you use the file which is called azure-pipelines.yml it works, but any other which should be detected by schema patern does not work eg. azure-pipelines.yaml does not work.

[Msouza91]

Maybe the binary is not expecting the same object that is passed from the table on these new versions, I'm not sure I'm capable of going through the code since I'm not a JSDev, but I can try to follow the logic and hopefully find where the issue is happening.

[Ziwi01]

I have the same issue. Previously I was attaching the LSP using the autocommand based on a pattern when buffer is being opened, now I rely on the schema pattern defined here. Both ways I get the error, when couple weeks ago it was working fine.

EDIT: It is working fine on 0.7.0. I browsed through the code and I don't see any obvious suspects - so it's probably either an internal function call used in one of new PRs or the dependency updates causing this issue.

[cksidharthan]

I have the same issue too. I tried to configure the yamlls plugin with azure pipeline schema as a temp fix, but even that is giving warnings on the pipeline files :(

[brianrobt]

I was having the same issue and fixed it by changing the value of the root_dir attribute. If you don't have root_dir set you will also get the same error.

Broken version

lspconfig["azure_pipelines_ls"].setup({
  capabilities = capabilities,
  root_dir = lspconfig.util.root_pattern("azure-pipelines.yml"),
  single_file_support = true,
  settings = {},
})

Fixed version

lspconfig["azure_pipelines_ls"].setup({
  capabilities = capabilities,
  root_dir = lspconfig.util.root_pattern("azure-pipelines.y*l"),
  single_file_support = true,
  settings = {},
})

[yavorski]

It is working for the specified patterns, but it is throwing error for every other yml file.

Settings:

local lsp = require("lspconfig")
local patterns = { "azure*.yml", ".azure/*.yml", "pipelines/*.yml", "azure-pipelines/*.yml" }
local service_schema = "https://raw.githubusercontent.com/microsoft/azure-pipelines-vscode/master/service-schema.json"

lsp.azure_pipelines_ls.setup({
  capabilities = LSP.capabilities(),
  root_dir = lsp.util.root_pattern(patterns),
  single_file_support = true,
  settings = {
    yaml = {
      schemas = {
        [service_schema] = patterns
      }
    }
  }
})

Example: open ~/my-project/.github/workflows/main.yml throws error:

Error executing vim.schedule lua callback: /usr/share/nvim/runtime/lua/vim/lsp/client.lua:589: RPC[Error] code_name = InternalError, message = "Request initialize failed with message: [UriError]: Scheme is missing: {scheme: \"\", authority: \"\", path: \"null\", query: \"\", fragment: \"\"}"
stack traceback:
  [C]: in function 'assert'
  /usr/share/nvim/runtime/lua/vim/lsp/client.lua:589: in function ''
  vim/_editor.lua: in function <vim/_editor.lua:0>

[brianrobt]

Should ~/my-project/.github/workflows/main.yml be managed by another YAML language server other than azure_pipelines_ls since it's not specific to Azure DevOps? That path is also missing from patterns.

[yavorski]

Indeed it should, but this server is also firing and throwing error, because of the yaml filetype, I think.

[ja-albert]

I have the same problem as @yavorski : Opening a yaml file without configured scheme, I get the same error message as in #160 (comment). My :LspInfo also matches the one in #160 (comment).

Within a Azure pipeline yaml file, everything works as intended.

I have version 0.8.0 installed with npm and use it in Neovim.

[Msouza91]

We might be barking at the wrong tree with the root directory thing, in 0.7.0 which works I get the same root dir message on :LspInfo, but the language server works, #160 (comment) makes sense for me. When updating to 0.8.0 it doesn't work at all.

I'd like to add that the issue presents itself in the same way on macOS although I am aware that it is most likely not platform specific.

I'll keep using 0.7.0 since the features added are only relevant for vscode users, we have gf for navigating to templates.
Hopefully for the next update in a year or two they have figured it out.

[winstliu]

We did introduce a bug in 0.8.0 that will be fixed in #169. It had a similarly vague error message in VS Code, though I'm not sure how the concept of "workspaces" translates to neovim/other IDEs.

You could try with that branch, I'm hoping to get a new release out with that fix in January.

[winstliu]

Oh, if I read this thread more closely, then yeah #169 definitely sounds correlated with rootUri/directory.

[Msouza91]

We did introduce a bug in 0.8.0 that will be fixed in #169. It had a similarly vague error message in VS Code, though I'm not sure how the concept of "workspaces" translates to neovim/other IDEs.

You could try with that branch, I'm hoping to get a new release out with that fix in January.

If I read this post correctly, Neovim doesn't have the same concept, it does have a reference for the current working directory that matches the one from which you first started the process, but you can dynamically change this with a command during a session.
For all intents and purposes the server not crashing when it can't find this root directory should indeed solve our problem.

I have built the binary from #169 branch and after pointing my LSP client to it I haven't gotten any errors so far.

And the server seems to returning the expected outputs

To anyone interested in replicating, after building the binary, just change the cmd parameter on your lspconfig setup, it would look something like this:

local M = {}
function M.azure()
  local opts = {
    settings = {
      yaml = {
        cmd = { "~/Downloads/package/bin/azure-pipelines-language-server" },
        capabilities = capabilities,
        schemas = {
          ["https://raw.githubusercontent.com/microsoft/azure-pipelines-vscode/master/service-schema.json"] = {
            "/azure-pipeline*.y*l",
            "/*.azure*",
            "Azure-Pipelines/**/*.y*l",
            "Pipelines/*.y*l",
            "cap/**/*.y*l",
            "cap/*.y*l",
            "veiling/**/*.y*l",
            "veiling/*.y*l",
            "sol_agora/**/*.y*l",
            "sol_agora/*.y*l",
            "aldo_solar/**/*.y*l",
            "aldo_solar/*.y*l",
          },
        },
      },
    },
  }
  return opts
end

return M

I have handlers that require configuration like that on a separate file, hence the function returning the configuration object like this, just require the handlers file on the lspconfig main file and call the function

local my_handlers = require("marcos.core.handlers")
require("lspconfig").azure_pipelines_ls.setup(my_handlers.azure())