cc68476b15
This makes the popups in the plugin (those for editing and creating comments, replies, the pipeline, etc) configurable. Users can change the default width, height, transparency, and border properties, and set overrides per popup.
2.4 KiB
Contributing to gitlab.nvim
Thank you for taking time to contribute to this plugin! Please follow these steps when creating a feature.
- If the functionality you want is not a bug fix, please create a "feature request" issue first
It's possible that the feature you want is already implemented, or does not belong in gitlab.nvim at all. By creating an issue first you can have a conversation with the maintainers about the functionality first. While this is not strictly necessary, it greatly increases the likelihood that your merge request will be accepted.
- Fork the repository, and create a new feature branch for your desired functionality. Make your changes.
If you are using Lazy as a plugin manager, the easiest way to work on changes is by setting a specific path for the plugin that points to your repository locally. This is what I do:
{
"harrisoncramer/gitlab.nvim",
dependencies = {
"MunifTanjim/nui.nvim",
"nvim-lua/plenary.nvim",
},
build = function()
require("gitlab.server").build()
end,
dir = "~/.path/to/your-cloned-version", -- Pass in the path to your cloned repository
config = function()
require("gitlab").setup({})
end,
}
If you are making changes to the Go codebase, don't forget to run make compile in the root of the project to rebuild the binary!
- Apply formatters and linters to your changes
For changes to the Go codebase: We use gofmt to check formatting and golangci-lint to check linting. Run these commands in the root of the repository:
$ go fmt ./...
$ golangci-lint run
For changes to the Lua codebase: We use stylua for formatting and luacheck for linting. Run these commands in the root of the repository:
$ stylua .
$ luacheck --globals vim busted --no-max-line-length -- .
- Make the merge request to the
mainbranch of.gitlab.nvim
Please provide a description of the feature, and links to any relevant issues.
That's it! I'll try to respond to any incoming merge request in a few days. Once we've reviewed it and it's been merged into main, the pipeline will detect whether we're merging in a patch, minor, or major change, and create a new tag (e.g. 1.0.12) and release.