harrisoncramer / gitlab.nvim

Create, review, and manage Gitlab reources without leaving Neovim
MIT License
254 stars 35 forks source link

Request: More newbie-friendly docs #23

Closed mnbroatch closed 1 year ago

mnbroatch commented 1 year ago

Is your feature request related to a problem? Please describe. Can't get plugin to work

Describe the solution you'd like I'm trying out neovim for the first time (longtime vim user), because I wanted to use this plugin

I spent the weekend trying to get this to work...

I think I have things set up somewhat correctly using the Lazy manager because changing either the auth token or the private gitlab url causes an error, which tells me we're at least authenticating...

I am currently in the branch that has an existing PR that is trying to be merged, and I have "base_branch" set to the target branch that we're trying to merge into (is that right? I've tried with the target branch and with "master") EDIT: THAT WAS NOT RIGHT. IT SHOULD ALWAYS BE YOUR ACTUAL MASTER OR MAIN BRANCH. It's set inside .gitlab.nvim, in the root of the project folder. Is that where it wants to be?

I have the config from the docs pasted in my init.lua require("gitlab").setup({...

I have the prerequisites listed as dependencies in the Lazy table and they are installed.

I type :lua require('gitlab').summary() and nothing happens. Is that an appropriate way to try to call that function? I know eventually I'll want bindings, but this should work, no? Does it sound like I'm missing something crucial?

I am willing to submit a PR for this change

harrisoncramer commented 1 year ago

I'm sorry you had trouble configuring the plugin, it sounds like a lot of folks with self-hosted Gitlab instances are having trouble.

For you, it does sound like the Go server is running -- what happens when you curl the endpoint directly from outside of Neovim? The Go server runs on a separate port outside of Neovim, and Neovim will reach out to it to make requests to Gitlab. Curling that server directly might be the easiest way of tracking down what's going wrong:

curl --header "PRIVATE-TOKEN: ${GITLAB_TOKEN}" localhost:21036/info 

Do you get the information or do you get an error? This is what's happening from within the plugin when you call the summary function.

The Go server is also writing a log of outbound requests that it's making to Gitlab, so you could check those to see that they look correct. They'll be kept at your cache location:

:lua print(vim.fn.stdpath("cache"))

Which for me is /Users/harrisoncramer/.cache/nvim/gitlab.nvim.log

I've added these steps to the "Troubleshooting" section of the readme to hopefully help out others in the future.

mnbroatch commented 1 year ago

Likewise, sorry if I sounded too frustrated at a piece of free software :]

But I must be close! curling the endpoint directly totally showed me MR information. Here's the output, with a heavy handed censorship pass:

{
  "message": "Merge requests retrieved",
  "status": 200,
  "info": {
    "id": redacted,
    "iid": redacted,
    "target_branch": "master",
    "source_branch": "redacted",
    "project_id": redacted,
    "title": "redacted",
    "state": "opened",
    "created_at": "2023-08-11T23:04:58.784Z",
    "updated_at": "2023-08-11T23:11:33.005Z",
    "upvotes": 0,
    "downvotes": 0,
    "author": {
      "id": redacted,
      "username": "redacted",
      "name": "redacted",
      "state": "active",
      "created_at": null,
      "avatar_url": "redacted",
      "web_url": "redacted"
    },
    "assignee": null,
    "assignees": [],
    "reviewers": [],
    "source_project_id": redacted,
    "target_project_id": redacted,
    "labels": "",
    "description": "redacted",
    "draft": true,
    "work_in_progress": true,
    "milestone": null,
    "merge_when_pipeline_succeeds": false,
    "detailed_merge_status": "not_approved",
    "merge_error": "",
    "merged_by": null,
    "merged_at": null,
    "closed_by": null,
    "closed_at": null,
    "subscribed": false,
    "sha": "redacted",
    "merge_commit_sha": "",
    "squash_commit_sha": "",
    "user_notes_count": 0,
    "changes_count": "127",
    "should_remove_source_branch": false,
    "force_remove_source_branch": false,
    "allow_collaboration": false,
    "web_url": "redacted",
    "references": {
      "short": "redacted",
      "relative": "redacted",
      "full": "redacted"
    },
    "discussion_locked": false,
    "changes": null,
    "user": {
      "can_merge": true
    },
    "time_stats": {
      "human_time_estimate": "",
      "human_total_time_spent": "",
      "time_estimate": 0,
      "total_time_spent": 0
    },
    "squash": false,
    "pipeline": {
      "id": redacted,
      "project_id": redacted,
      "status": "failed",
      "source": "merge_request_event",
      "ref": "redacted",
      "sha": "redacted",
      "web_url": "redacted",
      "updated_at": "2023-08-11T23:09:27.433Z",
      "created_at": "2023-08-11T23:05:02.441Z"
    },
    "head_pipeline": {
      "id": redacted,
      "iid": redacted,
      "project_id": redacted,
      "status": "failed",
      "source": "merge_request_event",
      "ref": "redacted",
      "sha": "redacted",
      "before_sha": "0000000000000000000000000000000000000000",
      "tag": false,
      "yaml_errors": "",
      "user": {
        "id": redacted,
        "username": "redacted",
        "name": "redacted",
        "state": "active",
        "created_at": null,
        "avatar_url": "redacted",
        "web_url": "redacted"
      },
      "updated_at": "2023-08-11T23:09:27.433Z",
      "created_at": "2023-08-11T23:05:02.441Z",
      "started_at": "2023-08-11T23:05:08.381Z",
      "finished_at": "2023-08-11T23:09:27.38Z",
      "committed_at": null,
      "duration": 256,
      "queued_duration": 5,
      "coverage": "",
      "web_url": "redacted",
      "detailed_status": {
        "icon": "status_failed",
        "text": "failed",
        "label": "failed",
        "group": "failed",
        "tooltip": "failed",
        "has_details": true,
        "details_path": "redacted",
        "illustration": {
          "image": ""
        },
        "favicon": "redacted"
      }
    },
    "diff_refs": {
      "base_sha": "redacted",
      "head_sha": "redacted",
      "start_sha": "redacted"
    },
    "diverged_commits_count": 0,
    "rebase_in_progress": false,
    "approvals_before_merge": 0,
    "reference": "redacted",
    "first_contribution": false,
    "task_completion_status": {
      "count": 0,
      "completed_count": 0
    },
    "has_conflicts": false,
    "blocking_discussions_resolved": true,
    "overflow": false,
    "merge_status": "can_be_merged"
  }
}
mnbroatch commented 1 year ago

I can provide more information about the redacted fields' format if something can't be null, etc., but hopefully the shape helps. There aren't any comments yet but I think I should be seeing the description from $.info.description when I run require("gitlab").summary()

harrisoncramer commented 1 year ago

Okay that's a good sign, seems that the MR information is being fetched. There are a couple more things to check. What happens when you log out the state of the plugin? I'm fetching the MR information (the API call you just showed) and setting it as the state of the plugin. I've exposed that state for debugging purposes:

:lua print(require("gitlab").state.INFO.title)
:lua print(require("gitlab").state.INFO.description)

These values should be set. If they aren't it means that something may have gone wrong passing that API response back to the plugin and the state isn't set correctly. This is supposed to happen in the lua/gitlab/init.lua in the ensureState function call.

If you're not seeing that state: You should be seeing a message from Neovim (and if not then this is something wrong with the job functionality that is in this plugin). You're not seeing any messages are you? There are some cases where we'd be printing out to Neovim's messages output, for instance :messages will show it. Do you see any messages there that might indicate what is going wrong?

mnbroatch commented 1 year ago

Running the print commands I see:

E5108: Error executing lua [string ":lua"]:1: attempt to index field 'INFO' (a nil value)
stack traceback:
        [string ":lua"]:1: in main chunk

Running messages I see:

panic: open /Users/mbroatch/.cache/nvim: is a directory
0xc000012258})
, 0x0?, 0x0?})
(0xc000155ee0, {0xc0000201c0, 0x18})
/Users/mbroatch/.local/share/nvim/lazy/gitlab.nvim/cmd/main.go:27 +0x126
E5108: Error executing lua [string ":lua"]:1: attempt to index field 'INFO' (a nil value)
stack traceback:
        [string ":lua"]:1: in main chunk

I'm not seeing any messages without running "messages", and running `require('gitlab').summary() does not cause any other messages to appear

mnbroatch commented 1 year ago

I disabled other plugins and basically have the same thing in messages:

panic: open /Users/mbroatch/.cache/nvim: is a directory
goroutine 1 [running]:
, {0x12c5a60, 0xc0000b2048})
, {0x0?, 0x0?, 0x0
?})
main.(*Client).init(0xc0000afee0, {0xc000092000, 0x18})
E5108: Error executing lua [string ":lua"]:1: attempt to index field 'INFO' (a nil value)
stack traceback:
        [string ":lua"]:1: in main chunk
harrisoncramer commented 1 year ago

Interesting, I think I might see what's going on. It looks like there is a mistake in the README! I'm terribly sorry. I've updated it to fix this.

In that error, the Golang server is throwing when it's trying to write to the log file, because it's trying to write to a directory. The log_path in the setup function is wrong, it's currently this:

    gitlab.setup({
     ...
      log_path = vim.fn.stdpath("cache"),   -- Log path for the Go server
    ...
    })

This should actually include the file name:

    gitlab.setup({
     ...
      log_path = vim.fn.stdpath("cache") .. "gitlab.nvim.log", -- Log path for the Go server
    ...
    })

However, configuring the log path is optional and excluding it entirely will default to this path anyway. What happens when you quit your Neovim instances and remove this line from your setup call, and then re-run :lua require("gitlab").summary(), do you still see this error?

It's strange to me that you would be able to CURL the server since this should have caused the server to crash completely from the beginning. It's possible though that you are a bit behind main (I've been changing this plugin/crushing bugs a lot recently) so you might also want to update it via Lazy to make sure you're on latest.

Does that solve the issue or do you still see errors? Thank you for sticking with this!

mnbroatch commented 1 year ago

Cool, omitting that does work!

I wasn't sure if the setup() call was needed at all; I should have tried removing it as part of the debugging process. I guess it wasn't! Though I guess this is the best outcome, improving the docs a bit!

Thanks for being so attentive!

harrisoncramer commented 1 year ago

Yeah of course, appreciate you being an early user -- I'm working to make this stable but there are still a lot of rough edges, so all the bug reports help!

harrisoncramer commented 1 year ago

By the way I'm merging in a rather large change now (https://github.com/harrisoncramer/gitlab.nvim/pull/24) now so if anything breaks on you in the discussion tree please let me know!

If you're using Lazy you would have to update to the latest to see it (I think Lazy will automatically rebuild the plugin, but if not, you can run :lua require("gitlab").build() to rebuild the binary).