|
| 1 | +# Repository Guidelines |
| 2 | + |
| 3 | +## Project Structure & Module Organization |
| 4 | +This repository hosts Shuffle app implementations. Each app lives in a top-level folder named after the integration (e.g., `aws-ec2/`), and each release is versioned under a subfolder like `1.0.0/`. A typical app version contains: |
| 5 | + |
| 6 | +- `src/app.py`: the Shuffle SDK entry point. |
| 7 | +- `api.yaml`: OpenAPI definition used by Shuffle. |
| 8 | +- `requirements.txt`: Python dependencies for the app. |
| 9 | +- `Dockerfile`: container build instructions for the app. |
| 10 | +- `README.md`: app-specific usage and action documentation. |
| 11 | +- Optional assets such as screenshots (`*.png`). |
| 12 | + |
| 13 | +In `api.yaml`, prefer an `authentication` block for shared credentials (URL, tokens, keys). Actions should only include auth parameters when they truly differ per call. |
| 14 | + |
| 15 | +## Build, Test, and Development Commands |
| 16 | +Apps are built and run container-first via the Shuffle SDK image. From an app version directory: |
| 17 | + |
| 18 | +- `docker build -t shuffle-<app>:<version> .`: build the app image. |
| 19 | +- `docker run --rm shuffle-<app>:<version>`: run the app container locally. |
| 20 | + |
| 21 | +For quick iteration on code, you can also run the Python entrypoint in a virtualenv: |
| 22 | + |
| 23 | +- `pip install -r requirements.txt` |
| 24 | +- `python src/app.py --log-level DEBUG` |
| 25 | + |
| 26 | +## Coding Style & Naming Conventions |
| 27 | +Use 4-space indentation and standard Python style. Keep functions `snake_case`, classes `CamelCase`, and constants `UPPER_SNAKE_CASE`. Match existing patterns in `src/app.py` and keep action names aligned with `api.yaml`. |
| 28 | + |
| 29 | +## Creating New Shuffle Apps (Agent Workflow) |
| 30 | +Use an existing app as a template (e.g., `http/1.4.0/` or `aws-ec2/1.0.0/`) and follow the same folder layout. A minimal, working app version should include: |
| 31 | + |
| 32 | +- `api.yaml`: action definitions, parameters, and examples. |
| 33 | +- `src/app.py`: class extending the Shuffle SDK (`shuffle_sdk.AppBase`). |
| 34 | +- `requirements.txt`: third-party dependencies. |
| 35 | +- `Dockerfile`: built on `frikky/shuffle:app_sdk`. |
| 36 | + |
| 37 | +When adding actions, ensure the `api.yaml` action name matches the method name in `src/app.py` and parameter names align exactly. Keep input parsing defensive (strings vs JSON), and return JSON-serializable results. For HTTP integrations, centralize auth and base URL handling and add a TLS `verify` option. If a service requires special payloads (e.g., ADF for Jira), accept JSON strings and pass through unchanged. Keep `api.yaml` examples realistic because they show up in the Shuffle UI. |
| 38 | + |
| 39 | +## Authentication & App Configuration |
| 40 | +Most apps declare credentials in `api.yaml` under `authentication:` so Shuffle injects them automatically. In code, read those values as normal action arguments (Shuffle passes them into each action). Prefer a single auth helper in `src/app.py` (e.g., `_auth()` for tokens, `_build_api_base()` for base URLs) and reuse it across actions. If an integration supports multiple auth modes (token vs password), accept both and choose the provided one. |
| 41 | + |
| 42 | +Prefer small, focused actions (create, update, list, search) and document auth requirements and examples in the app `README.md`. |
| 43 | + |
| 44 | +## Manual Python App Notes (From Shuffle Docs) |
| 45 | +- **SDK image choices:** Shuffle provides Alpine (slim), Kali (security tooling), and Blackarch (kitchen‑sink). This repo’s Dockerfiles typically use `frikky/shuffle:app_sdk` (Alpine‑based) unless a toolset requires otherwise. |
| 46 | +- **Directory layout:** `api.yaml`, `Dockerfile`, `requirements.txt`, `README.md`, and `src/app.py` are expected in each app version. Complex apps can add additional modules under `src/` and import them from `app.py`. |
| 47 | +- **Actions & wiring:** Every action in `api.yaml` must map to a method in `src/app.py` with the same name and argument list. Authentication parameters are passed into each action automatically when declared under `authentication:`. |
| 48 | +- **Utility helpers:** In `AppBase`, you can use `self.get_file`, `self.set_files`, `self.update_file`, and cache helpers `self.get_cache`, `self.set_cache`, `self.delete_cache` for file and key/value workflows. |
| 49 | +- **Prototyping:** Build and test your Python logic locally first, then wire it into `src/app.py`. Keep return values JSON‑serializable so Shuffle can consume them. |
| 50 | +- **Upload & hotload:** After a prototype works, upload it to Shuffle (cloud) or hotload locally (on‑prem) by rebuilding the app image. Local Docker rebuilds are faster for iteration. |
| 51 | + |
| 52 | +## Testing, Hotloading, and CI/CD |
| 53 | +- **Cloud upload test:** Use the Upload App API to add the app to your org, then run a workflow to validate actions. |
| 54 | +- **Local hotload (on‑prem):** Place the app folder in `shuffle-apps/`, set `SHUFFLE_APP_HOTLOAD_FOLDER=./shuffle-apps`, then use the hot reload button in the UI. Allow ~20 seconds for the reload to complete. |
| 55 | +- **Update workflow deps:** If you update an existing app version, remove and re‑add the app in any workflows that reference it. |
| 56 | +- **Fast local iteration:** After the first upload, rebuild locally: `docker images | grep <appname>` then `docker build . -t <imagename>`. |
| 57 | +- **CI/CD pattern:** Create a test workflow, upload a test app version, run the workflow via API, and validate `workflowexecution.workflow.validation.valid` before promoting. |
| 58 | + |
| 59 | +## Publishing Apps |
| 60 | +- **OpenAPI apps:** Upload to your instance, then use the `/apps` page to publish so it appears on `shuffler.io`. |
| 61 | +- **Python apps:** Fork `https://github.com/frikky/shuffle-apps`, add your app, and open a pull request to upstream. |
| 62 | + |
| 63 | +## Testing Guidelines |
| 64 | +There is no repository-wide test suite. If you add tests for a specific app, keep them alongside the app version (e.g., `aws-ec2/1.0.0/tests/`) and document how to run them in that app’s `README.md`. |
| 65 | + |
| 66 | +## Commit & Pull Request Guidelines |
| 67 | +Commit messages are short and descriptive, sometimes using a prefix like `fix:`. Follow that style and keep commits scoped to a single app/version when possible. |
| 68 | + |
| 69 | +For pull requests, include: |
| 70 | + |
| 71 | +- A clear description of the change and impacted app/version path. |
| 72 | +- Updated `README.md` or `api.yaml` when behavior changes. |
| 73 | +- Screenshots/assets if user-facing output or UI-related docs are affected. |
| 74 | + |
| 75 | +## Security & Configuration Tips |
| 76 | +Many apps require API keys or credentials. Do not commit secrets; use environment variables or Shuffle configuration fields instead, and document required inputs in the app’s `README.md`. |
0 commit comments