|
1 | 1 | # Contributing to Runcom |
2 | 2 |
|
3 | | -Thanks for your interest in contributing! Runcom is a monorepo of Elixir |
4 | | -packages for building and executing change plans with checkpointing. |
| 3 | +Thanks for your interest in contributing! This document explains how to get set up, |
| 4 | +what to expect, and how to submit changes. |
5 | 5 |
|
6 | | -## Ground Rules |
| 6 | +## Code of Conduct |
7 | 7 |
|
8 | | -- Be respectful — see the [Code of Conduct](CODE_OF_CONDUCT.md). |
9 | | -- File an issue before opening a non-trivial PR so we can align on direction. |
10 | | -- Keep PRs focused. One concern per PR makes review faster. |
11 | | -- All contributions are licensed under Apache 2.0 (see [LICENSE](LICENSE)). |
| 8 | +This project adheres to the [Contributor Covenant](CODE_OF_CONDUCT.md). By |
| 9 | +participating, you are expected to uphold it. Please report unacceptable behavior |
| 10 | +to the maintainers. |
12 | 11 |
|
13 | | -## Monorepo Layout |
| 12 | +## Repository Layout |
14 | 13 |
|
15 | | -| Package | Purpose | |
16 | | -|---------|---------| |
17 | | -| `runcom/` | Core DSL, step behaviours, execution engine, checkpointing | |
18 | | -| `runcom_ecto/` | Ecto/Postgres persistence | |
19 | | -| `runcom_web/` | Phoenix LiveView dashboard | |
20 | | -| `runcom_rmq/` | RabbitMQ transport via Broadway | |
21 | | -| `runcom_demo/` | Demo app wiring everything together | |
22 | | -| `runcom_demo_agent/` | Agent-side companion for distributed dispatch | |
| 14 | +Runcom is a monorepo of independently-published Hex packages: |
23 | 15 |
|
24 | | -Each package has its own `mix.exs`, `deps/`, and `_build/`. During local |
| 16 | +| Package | Path | Purpose | |
| 17 | +|---------|------|---------| |
| 18 | +| `runcom` | `runcom/` | Core DSL, step behaviours, execution engine, checkpointing | |
| 19 | +| `runcom_ecto` | `runcom_ecto/` | Ecto/Postgres persistence | |
| 20 | +| `runcom_web` | `runcom_web/` | Phoenix LiveView dashboard | |
| 21 | +| `runcom_rmq` | `runcom_rmq/` | RabbitMQ transport | |
| 22 | +| `runcom_demo` | `runcom_demo/` | Demo app wiring everything together | |
| 23 | +| `runcom_demo_agent` | `runcom_demo_agent/` | Agent-side companion for the demo | |
| 24 | + |
| 25 | +Each package has its own `mix.exs`, `_build/`, and `deps/`. During local |
25 | 26 | development, packages reference each other via path deps. |
26 | 27 |
|
27 | 28 | ## Development Setup |
28 | 29 |
|
29 | | -Runtime versions are managed by [`mise`](https://mise.jdx.dev): |
30 | | - |
31 | | -```bash |
32 | | -mise install # installs Elixir 1.20-rc.2, OTP 28, Node 22 |
33 | | -``` |
| 30 | +Runtime versions are managed by [mise](https://mise.jdx.dev) (see `mise.toml`): |
34 | 31 |
|
35 | | -Per-package workflow: |
| 32 | +- Elixir 1.20-rc.2 |
| 33 | +- OTP 28 |
| 34 | +- Node 22 |
36 | 35 |
|
37 | 36 | ```bash |
38 | | -cd runcom # (or any package) |
39 | | -mix deps.get |
40 | | -mix compile |
| 37 | +# Per-package (run from package directory) |
| 38 | +mix deps.get && mix compile |
41 | 39 | mix test |
42 | 40 | mix format |
| 41 | + |
| 42 | +# Full demo stack |
| 43 | +cd runcom_demo && docker compose up |
43 | 44 | ``` |
44 | 45 |
|
45 | | -Full demo stack (Postgres + RabbitMQ + MinIO + agents): |
| 46 | +## Making Changes |
46 | 47 |
|
47 | | -```bash |
48 | | -cd runcom_demo |
49 | | -docker compose up |
50 | | -``` |
| 48 | +1. **Fork and branch** — create a feature branch from `main`. |
| 49 | +2. **Write tests** — all new behavior should be covered by tests. For Elixir |
| 50 | + code, async tests are preferred; avoid global state. |
| 51 | +3. **Format** — run `mix format` before committing. |
| 52 | +4. **Keep changes focused** — one logical change per PR. Unrelated cleanups |
| 53 | + should go in separate PRs. |
| 54 | +5. **Update docs** — if you change public APIs, update the module `@doc` and |
| 55 | + relevant README sections. |
| 56 | + |
| 57 | +## Commit Messages |
| 58 | + |
| 59 | +Use present-tense imperative subjects ("Add checkpoint resume", not "Added" or |
| 60 | +"Adds"). Reference issues in the body when applicable. |
| 61 | + |
| 62 | +## Pull Requests |
| 63 | + |
| 64 | +When opening a PR: |
| 65 | + |
| 66 | +- Describe *what* changed and *why* — link to any relevant issue or discussion. |
| 67 | +- Include test output or screenshots where relevant. |
| 68 | +- Expect review feedback; we aim to respond within a few business days. |
51 | 69 |
|
52 | | -## Submitting Changes |
| 70 | +## Reporting Bugs |
53 | 71 |
|
54 | | -1. Fork and create a feature branch from `main`. |
55 | | -2. Make your changes with tests. |
56 | | -3. Run `mix format` and `mix test` in every package you touched. |
57 | | -4. Open a PR with a clear description of the change and its motivation. |
| 72 | +Open an issue with: |
58 | 73 |
|
59 | | -## Reporting Issues |
| 74 | +- A minimal reproduction (ideally a failing test or runbook snippet). |
| 75 | +- Elixir/OTP versions (`elixir --version`). |
| 76 | +- Relevant logs or stack traces. |
60 | 77 |
|
61 | | -Please include: |
| 78 | +## Security Issues |
62 | 79 |
|
63 | | -- Which package(s) are affected |
64 | | -- Elixir/OTP versions (`elixir --version`) |
65 | | -- A minimal reproduction if possible |
66 | | -- Relevant log output |
| 80 | +Do **not** open a public issue for security vulnerabilities. See the security |
| 81 | +policy (if present) or email the maintainers directly. |
67 | 82 |
|
68 | | -## Security |
| 83 | +## License |
69 | 84 |
|
70 | | -Please do **not** file public issues for security vulnerabilities. Instead, |
71 | | -email the maintainers at the address listed in the package `mix.exs` or |
72 | | -contact us privately via GitHub. |
| 85 | +By contributing, you agree that your contributions will be licensed under the |
| 86 | +[Apache License 2.0](LICENSE). |
0 commit comments