Plugin fails to build

[kostya9]

Prerequsities

• I'm on the latest version of the plugin
• I've installed the required dependencies
• I've run :h gitlab.nvim.troubleshooting and followed the steps there

Setup Configuration and Environment

return {
	"harrisoncramer/gitlab.nvim",
	dependencies = {
		"MunifTanjim/nui.nvim",
		"nvim-lua/plenary.nvim",
		"sindrets/diffview.nvim",
		"stevearc/dressing.nvim", -- Recommended but not required. Better UI for pickers.
		"nvim-tree/nvim-web-devicons" -- Recommended but not required. Icons in discussion tree.
	},
	enabled = true,
	build = function() require("gitlab.server").build(true) end, -- Builds the Go binary
	config = function()
		require("gitlab").setup({
			debug = {
				request=true,
				response=true,
				gitlab_request=true,
				gitlab_response=true,
			},
			log_path = "D:/gitlab.nvim.log"

		})
	end,
}

OS: Windows

Bug Description

When installing the plugin, it does not build the server binary. At the same time, building manually via go build -o bin.exe works (running in gitlab.nvim/cmd directory).

My hypothesis: it tries to build the binary in the wrong directory.

Reproduction Steps

1. Check out the feature branch
2. Open Neovim
3. Observe error:

Could not install gitlab.nvim!

4. Observe that there is no binary bin.exe in gitlab.nvim folder.

Screenshots

[harrisoncramer]

Interesting. I'm not a Windows user so this would be hard for me to debug, as you've already determined there's something going wrong here:

  local file_path = u.current_file_path()
  local parent_dir = vim.fn.fnamemodify(file_path, ":h:h:h:h")
  state.settings.bin_path = parent_dir
  state.settings.bin = parent_dir .. (u.is_windows() and "\\bin.exe" or "/bin")

  if not override then
    local binary_exists = vim.loop.fs_stat(state.settings.bin)
    if binary_exists ~= nil then
      return
    end
  end

  local cmd = u.is_windows() and "cd %s\\cmd && go build -o bin.exe && move bin.exe ..\\"
    or "cd %s/cmd && go build -o bin && mv bin ../bin"

  local command = string.format(cmd, state.settings.bin_path)
  local null = u.is_windows() and " >NUL" or " > /dev/null"
 
  -- If you add this line we can see the command that's actually being run
  print(command .. null)

  local installCode = os.execute(command .. null)
  if installCode ~= 0 then
    u.notify("Could not install gitlab.nvim!", vim.log.levels.ERROR)
    return false
  end
  u.notify("Gitlab.nvim installed successfully!", vim.log.levels.INFO)
  return true

To debug this, I'd probably want to know the exact command the plugin is trying to run. You can see that if you change into the plugin directory and edit that function in lua/gitlab/server.lua to add a print before the command is actually executed.

To find the source code for this plugin, run the following ex command to see where the plugins are on your system. Then change into your Lazy directory, and into the Gitlab directory:

:lua=vim.fn.stdpath("data") # And then switch into lazy, gitlab.nvim...

[harrisoncramer]

This is something to do with your setup, if you're able to post more information about the command that's actually running and further debug that Lua file, that'd be great.

With an EC2 instance running Windows and with the basic requirements needed for this plugin (Lazy, Neovim, Go, and the bare bones configuration from the Readme), the plugin created and moved the bin.exe in the correct location and everything worked as expected for me.

[harrisoncramer]

Hey @kostya9 are you able to provide the above information? Specifically I'm looking for the actual command the plugin is trying to run on your machine, since I'm not able to replicate. It's probably a path or command issue of some kind.

[kostya9]

Sorry for the long delay.

The command looks fine, but it fails for some reason. When I copy this command and run manually - it works.

Now that I think about it - this may be connected to the fact that I use PowershellCore as terminal instead of the default things, and maybe my vim terminal settings are causing this issue. Although looking at the docs, the os.execute() should use the system shell, not my vim configuration...

[kostya9]

The build command starts to work if I change it to this (executing commands via vim.system):

[harrisoncramer]

That's hugely helpful, thank you.

I've opened up an MR that should fix this: #419

Do you mind checking out this branch and tell me if the server builds correctly? You should be able to check out a specific branch with Lazy, then run this to force a rebuild:

:lua require("gitlab.server").build(true)

[Daydreamer-riri]

Hi @harrisoncramer, How do I know if I built it correctly?

I now get an error:

   Error  21:04:17 notify.error gitlab.nvim: panic: could not find emojis at ./config/emojis.json
goroutine 1 [running]:

   Error  21:04:17 notify.error gitlab.nvim: github.com/harrisoncramer/gitlab.nvim/cmd/app.CreateRouter(0xc000252000, 0x1?, 0xc00011fd88, {0xc00011fdf0, 0x3, 0x5c35a7?})
	D:/Users/ding.zhao/AppData/Local/nvim-data/lazy/gitlab.nvim/cmd/app/server.go:94 +0x3b4b
github.com/harrisoncramer/gitlab.nvim/cmd/app.StartServer(0xc000252000, 0xc00023a678, {{0xc000174ff0, 0x42}, {0xc000175010, 0xb}, {0xc00017501c, 0x12}, {0xc00023e000, 0x24}})
	D:/Users/ding.zhao/AppData/Local/nvim-data/lazy/gitlab.nvim/cmd/app/server.go:26 +0x156
main.main()
	D:/Users/ding.zhao/AppData/Local/nvim-data/lazy/gitlab.nvim/cmd/main.go:45 +0x397

   Error  21:04:17 notify.error gitlab.nvim: Golang gitlab server exited: job_id: 9, exit_code: 2

[harrisoncramer]

Ah, okay I think that was due to me using forward slashes in the emoji location, I've made this fix:

Could you pull down the latest for this branch, rebuild the server, and try again: #419

[Daydreamer-riri]

Thanks. I will try it tomorrow, thank you for your reply!

[Daydreamer-riri]

Hi @harrisoncramer, I tried it out and it's running well. However, I encountered this issue: I can't close any of the gitlab.nvim pop-up windows using esc or q. Is this normal?

I also noticed that the time displayed was incorrect:

The comments here are ones I just posted.

[harrisoncramer]

I'm not sure why your diagnostics wouldn't close. But both of these are separate issues from this original issue, if you are unable to resolve them please open up a separate ticket. I'll close this one out now.