Skip to content

Commit 1227939

Browse files
added AGENTS.md for agent context
1 parent 2f7c27e commit 1227939

File tree

1 file changed

+76
-0
lines changed

1 file changed

+76
-0
lines changed

AGENTS.md

Lines changed: 76 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,76 @@
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

Comments
 (0)