zellij-org/zellij

Fork 0

mirror of https://github.com/zellij-org/zellij.git synced 2024-11-22 13:02:12 +03:00

哇呜哇呜呀咦耶 8626e7ab40

update log path (#1927 )

2022-11-13 23:25:37 +09:00

9.0 KiB

Raw Blame History

Contributing to Zellij

Thanks for considering contributing to Zellij!

First: if you're unsure of anything, feel free to ask on our Discord server, or on Matrix. We're a friendly and welcoming bunch!

Code of Conduct

Before contributing please read our Code of Conduct which all contributors are expected to adhere to.

Building

To build Zellij, we're using cargo-make – you can install it by running cargo install --locked --force cargo-make.

To edit our manpage, the mandown crate (cargo install --locked mandown) is used and the work is done on a markdown file in docs/MANPAGE.md.

Here are some of the commands currently supported by the build system:

# Format code, build, then run tests and clippy
cargo make
# You can also perform these actions individually
cargo make format
cargo make build
cargo make test
# Run Zellij (optionally with additional arguments)
cargo make run
cargo make run -l strider
# Run Clippy (potentially with additional options)
cargo make clippy
cargo make clippy -W clippy::pedantic
# Install Zellij to some directory
cargo make install /path/of/zellij/binary
# Publish the zellij and zellij-tile crates
cargo make publish
# Update manpage
cargo make manpage

To run install or publish, you'll need the package binaryen in the version wasm-opt --version > 97, for it's command wasm-opt.

To run test, you will need the package pkg-config and a version of openssl.

Should you be a `nix` (linux/macOs) user, you can use the following commands in order to get set up: (expand)

nix develop Download and set up dependencies.
nix build Build the binary in the result directory. (--release)
nix run Run the binary.
cachix use zellij Will use our binary cache as a substituter.

Running the end-to-end tests

Zellij includes some end-to-end tests which test the whole application as a black-box from the outside. These tests work by running a docker container which contains the Zellij binary, connecting to it via ssh, sending some commands and comparing the output received against predefined snapshots.

Should you be a macOS (including m1) user, please follow these commands before. (expand here):

rustup target add x86_64-unknown-linux-musl
brew install messense/macos-cross-toolchains/x86_64-unknown-linux-musl
export CC_x86_64_unknown_linux_musl=$(brew --prefix)/bin/x86_64-unknown-linux-musl-gcc
export AR_x86_64_unknown_linux_musl=$(brew --prefix)/bin/x86_64-unknown-linux-musl-ar
export CARGO_TARGET_X86_64_UNKNOWN_LINUX_MUSL_LINKER=$CC_x86_64_unknown_linux_musl

To run these tests locally, you'll need to have either docker or podman and also docker-compose installed. Once you do, in the repository root:

docker-compose up -d will start up the docker container
cargo make build-e2e will build the generic linux executable of Zellij in the target folder, which is shared with the container
cargo make e2e-test will run the tests

To re-run the tests after you've changed something in the code base, be sure to repeat steps 2 and 3.

Debugging / Troubleshooting while developing

Zellij uses the excellent log crate to handle its internal logging. The output of these logs will go to /$temp_dir/zellij-<UID>/zellij-log/zellij.log which $temp_dir refers to std::env::temp_dir(). On most of operating systems it points to /tmp, but there are exceptions, such as /var/folders/dr/xxxxxxxxxxxxxx/T/ for Mac.

Example:

let my_variable = some_function();
log::info!("my variable is: {:?}", my_variable);

Note that the output is truncated at 100KB. This can be adjusted for the purposes of debugging through the LOG_MAX_BYTES constant, at the time of writing here: https://github.com/zellij-org/zellij/blob/main/zellij-utils/src/logging.rs#L24

When running Zellij with the --debug flag, Zellij will dump a copy of all bytes received over the pty for each pane in: /$temp_dir/zellij-<UID>/zellij-log/zellij-<pane_id>.log. These might be useful when troubleshooting terminal issues.

How we treat clippy lints

We currently use clippy in GitHub Actions with the default settings that report only clippy::correctness as errors and other lints as warnings because Zellij is still unstable. This means that all warnings can be ignored depending on the situation at that time, even though they are also helpful to keep the code quality. Since we just cannot afford to manage them, we are always welcome to fix them!

Here is the detailed discussion if you want to see it.

Looking for something to work on?

If you are new contributor to Zellij going through beginners should be a good start or you can join our public Discord server, we would be happy to help finding something interesting to work on and guide through.

Tips for Code Contributions

Prefer returning `Result`s instead of `unwrap`ing

Add use zellij_utils::errors::prelude::*; to the file
Make the function return Result<T>, with an appropriate T (Use () if there's nothing to return)
Append .context() to any Result you get with a sensible error description (see the docs)
Generate ad-hoc errors with anyhow!(<SOME MESSAGE>)
Further reading: See here

Logging errors

When there's a Result type around, use .non_fatal() on that instead of log::error!
When there's a Err type around, use Err::<(), _>(err).non_fatal()
Also attach context before logging!
Further reading: See here

Adding Concrete Errors, Handling Specific Errors

Add a new variant to zellij_utils::errors::ZellijError, if needed
Use anyhow::Error::downcast_ref::<ZellijError>() to recover underlying errors
Further reading: See here

Filing Issues

Bugs and enhancement suggestions are tracked as GitHub issues.

Lacking API for plugin in Zellij?

If you have a plugin idea, but Zellij still doesn't have API required to make the plugin consider opening an issue and describing your requirements.

How Do I Submit A (Good) Bug Report?

After you've determined which repository your bug is related to and that the issue is still present in the latest version of the master branch, create an issue on that repository and provide the following information:

Use a clear and descriptive title for the issue to identify the problem.
Explain which behavior you expected to see instead and why.
Describe the exact steps to reproduce the problem in as many details as necessary.
When providing code samples, please use code blocks.

How Do I Submit A (Good) Enhancement Suggestion?

Instructions are similar to those for bug reports. Please provide the following information:

Use a clear and descriptive title for the issue to identify the suggestion.
Provide a description of the suggested enhancement in as many details as necessary.
When providing code samples, please use code blocks.

Submitting Pull Requests