Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
86 lines (64 loc) · 3.88 KB

CONTRIBUTING.md

File metadata and controls

86 lines (64 loc) · 3.88 KB

Contributing to Arconia CLI

Thank you for your interest in contributing! Whether it's reporting bugs, suggesting features, improving documentation, or submitting code, your input is welcome and valued.

Ground Rules

  • Be Respectful. Adhere to the Code of Conduct.
  • Discuss First. For non-trivial changes, open an issue before starting work. PRs without a prior discussion may be rejected.
  • Use Discussions for Questions. The issue tracker is not for support questions. Use GitHub Discussions instead.
  • Focused PRs. Each pull request should address a single issue or feature, linked to the corresponding issue (e.g., Fixes #123).
  • Security Vulnerabilities. Report them responsibly via the Security Policy. Do not open a public issue.

Prerequisites

  • Java 25+ with GraalVM native compilation support.
  • A container runtime compatible with Testcontainers (e.g., Podman Desktop, Docker Desktop).

For a detailed guide on building, installing, and running the CLI from source, see the Development documentation.

Contribution Workflow

  1. Find or create an issue. Ensure a GitHub Issue exists for the change you want to make.
  2. Fork and clone the repository: 
    git clone https://github.com/<your-username>/arconia-cli.git
cd arconia-cli
  3. Create a branch off main: 
    git checkout -b my-feature-branch main
  4. Implement your changes. Follow the code style guidelines, add tests, and update documentation in docs/ if needed.
  5. Build and test locally (both JVM and native): 
    ./gradlew build
./gradlew nativeBuild
  6. Commit using Conventional Commits format with a DCO sign-off: 
    git commit -s -m "feat(skills): Add new skill support"
  7. Keep your branch updated via rebase (never merge): 
    git fetch upstream
git rebase upstream/main
  8. Push and open a PR targeting main. Ensure the PR title follows Conventional Commits format and fill out the PR template.
  9. Address review feedback. Maintainers will review your PR. Push additional signed-off commits as needed.

Reporting Bugs and Suggesting Features

Use GitHub Issues with the appropriate template. Before submitting, search existing issues to avoid duplicates and ensure bugs are reproducible with the latest version.

Development Guidelines

Code Style

  • The project uses .editorconfig for formatting. Ensure your editor respects it.
  • Use explicit imports (no wildcards).
  • Follow existing alphabetical sorting conventions.

Commit Messages

We follow Conventional Commits for both commit messages and PR titles.

<type>[optional scope]: <description>
  • Types: feat, fix, docs, style, refactor, test, build, ci, chore, revert, deps.
  • Style: Present tense, imperative mood (e.g., "Add feature", not "Added feature").
  • Breaking changes: Append ! after the type/scope (e.g., feat(core)!:) or add BREAKING CHANGE: in the footer.

Example: fix: Correct handling of projection creation

DCO Sign-off

All commits must include a Developer Certificate of Origin sign-off. Commits without it will block merging.

# Sign-off a new commit
git commit -s -m "Your commit message"

# Add sign-off to the last commit
git commit --amend -s --no-edit