Contributing

Contributing

Medusa welcomes contributions, new tools, fixes, docs. The canonical guide lives in the repository: CONTRIBUTING.md. This page summarizes the workflow.

Before you start

• Most contributions add a tool. Read Adding-a-Tool first.
• Be respectful, see the Code of Conduct.
• Security issues go through the security policy, never a public issue.

Local setup

git clone https://github.com/WhiteMuush/Medusa.git
cd Medusa
chmod +x medusa.sh
./medusa.sh check

Code conventions

• Pure Bash, sourced under set -uo pipefail. Do not add set -e (it breaks the interactive loop).
• Never cd in a deployer, use compose_in_dir / run_in_dir.
• User-facing output goes through log_message <level>, not raw echo -e with colors.
• Generated secrets use gen_password + save_credentials; files are chmod 600.
• Pin Docker image tags to real versions, not :latest (Greenbone's feed images are the documented exception).
• Match the style of the surrounding code.

Quality gates

Run locally before pushing, the same checks CI runs:

bash -n medusa.sh lib/*.sh                              # syntax
shellcheck -e SC1091 -e SC2086 -e SC2155 medusa.sh lib/*.sh
./medusa.sh list                                        # registry sanity

CI (.github/workflows/ci.yml) runs three jobs on every push and PR:

1. ShellCheck on all *.sh.
2. bash -n syntax check on all *.sh.
3. Source-chain smoke test, sources every lib/ file and asserts that key functions exist and that every registered tool has a matching deploy_<tool> function. A tool registered without its deployer fails CI.

Pull requests

• One logical change per PR; describe the change in the body (release notes are bundled per tag, no per-PR changelog entry).
• Update the relevant wiki tool page and Ports-Reference when you add or change a tool.
• Make sure the smoke test would pass: registering a tool requires defining its deploy_<tool>.

---

Next: Adding-a-Tool · Architecture