Public Access
gitea-actions[bot]
162 lines
4.9 KiB
Markdown
162 lines
4.9 KiB
Markdown
<!-- Copyright (C) 2026 Moko Consulting <hello@mokoconsulting.tech>
|
|
|
|
This file is part of a Moko Consulting project.
|
|
|
|
SPDX-LICENSE-IDENTIFIER: GPL-3.0-or-later
|
|
|
|
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version.
|
|
|
|
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the IMPLIED WARRANTY of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
|
|
|
|
You should have received a copy of the GNU General Public License (./LICENSE).
|
|
|
|
# FILE INFORMATION
|
|
DEFGROUP: dolibarr-api-mcp.Documentation
|
|
INGROUP: dolibarr-api-mcp
|
|
REPO: https://git.mokoconsulting.tech/MokoConsulting/dolibarr-api-mcp
|
|
VERSION: 09.38.05
|
|
PATH: ./CONTRIBUTING.md
|
|
BRIEF: Contribution guidelines for the project
|
|
-->
|
|
|
|
# Contributing to dolibarr-api-mcp
|
|
|
|
We appreciate your interest in contributing to this project! This document provides guidelines for contributing.
|
|
|
|
## Table of Contents
|
|
|
|
- [Code of Conduct](#code-of-conduct)
|
|
- [Getting Started](#getting-started)
|
|
- [How to Contribute](#how-to-contribute)
|
|
- [Development Workflow](#development-workflow)
|
|
- [Commit Messages](#commit-messages)
|
|
- [Pull Request Process](#pull-request-process)
|
|
|
|
## Code of Conduct
|
|
|
|
This project adheres to the Contributor Covenant Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to hello@mokoconsulting.tech.
|
|
|
|
## Getting Started
|
|
|
|
1. Fork the repository
|
|
2. Clone your fork locally
|
|
3. Install dependencies: `npm install`
|
|
4. Build: `npm run build`
|
|
5. Create a new branch for your work
|
|
|
|
## How to Contribute
|
|
|
|
### Reporting Bugs
|
|
|
|
- Use the Gitea issue tracker
|
|
- Describe the bug clearly with steps to reproduce
|
|
- Include the Dolibarr version you're connecting to
|
|
- Include relevant logs or error messages
|
|
|
|
### Adding New Tools
|
|
|
|
If you want to add support for a Dolibarr API endpoint not yet covered:
|
|
|
|
1. Check the [Dolibarr API Explorer](https://your-dolibarr.com/api/index.php/explorer) for endpoint details
|
|
2. Add the tool registration in `src/index.ts` following the existing patterns
|
|
3. Update `docs/API.md` with the new tool's parameter table
|
|
4. Update `README.md` tool listing
|
|
5. Update `CHANGELOG.md`
|
|
|
|
### Contributing Code
|
|
|
|
- Pick an issue or create one
|
|
- Fork the repository and create a branch
|
|
- Make your changes following the project conventions
|
|
- Submit a pull request
|
|
|
|
## Development Workflow
|
|
|
|
1. Ensure your fork is up to date with the main repository
|
|
2. Create a feature branch from `main`
|
|
3. Make your changes
|
|
4. Test against a Dolibarr instance (use `npm run setup` to configure a dev connection)
|
|
5. Build with `npm run build` to catch TypeScript errors
|
|
6. Commit your changes with clear messages
|
|
7. Push to your fork
|
|
8. Create a pull request
|
|
|
|
## Commit Messages
|
|
|
|
Follow the conventional commit format:
|
|
|
|
```
|
|
<type>(<scope>): <subject>
|
|
|
|
<body>
|
|
|
|
<footer>
|
|
```
|
|
|
|
Types: `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore`, `ci`, `build`, `perf`, `revert`
|
|
|
|
Example:
|
|
```
|
|
feat(tools): add shipment management tools
|
|
|
|
Add dolibarr_shipments_list, dolibarr_shipment_get, and
|
|
dolibarr_shipment_validate tools for the /shipments API endpoint.
|
|
```
|
|
|
|
## Pull Request Process
|
|
|
|
1. Update documentation for any new tools
|
|
2. Follow the project's coding style and conventions
|
|
3. Ensure `npm run build` succeeds without errors
|
|
4. Update the CHANGELOG.md with your changes
|
|
5. Request review from maintainers
|
|
6. Address any feedback promptly
|
|
7. Once approved, your PR will be merged
|
|
|
|
## Style Guidelines
|
|
|
|
- Use tabs for indentation
|
|
- All source files must include the Moko Consulting copyright header
|
|
- Use `snake_case` for local variables (matching Dolibarr API field names)
|
|
- Use Zod for all tool parameter validation
|
|
- Follow the `formatResponse()` pattern for consistent error handling
|
|
|
|
## Infrastructure Standards
|
|
|
|
All repositories in the MokoConsulting org follow these conventions:
|
|
|
|
### Release Tags
|
|
|
|
Every repo maintains 5 standard release channel tags:
|
|
|
|
- `development` - Active development builds
|
|
- `alpha` - Early internal testing
|
|
- `beta` - Broader testing / client UAT
|
|
- `release-candidate` - Final QA before production
|
|
- `stable` - Production release
|
|
|
|
### Branch Protection
|
|
|
|
- `main` is protected; only `jmiller` can push directly
|
|
- All other contributors must use pull requests
|
|
- PRs are automatically reviewed by Claude Code
|
|
|
|
### CI/CD
|
|
|
|
- Gitea Actions runs all CI workflows
|
|
- Workflows live in `.gitea/workflows/`
|
|
|
|
### Secrets
|
|
|
|
All repos have `GA_TOKEN` and `GH_TOKEN` as Actions secrets for API access.
|
|
|
|
## Questions?
|
|
|
|
If you have questions about contributing, feel free to open an issue or contact the maintainers at hello@mokoconsulting.tech.
|
|
|
|
## Revision History
|
|
|
|
| Date | Version | Author | Notes |
|
|
| --- | --- | --- | --- |
|
|
| 2026-05-07 | 0.0.1 | jmiller | Initial contributing guidelines |
|