160 lines
6.0 KiB
Markdown
160 lines
6.0 KiB
Markdown
# GPT 5.4 handoff: Fission CRON plan
|
||
|
||
## Goal
|
||
|
||
Составить только план действий по теме Fission cron / time triggers. Не писать реализацию сейчас. Не раздувать ответ. Нужен прагматичный, короткий, пошаговый план.
|
||
|
||
## What is the topic
|
||
|
||
В Fission cron-триггеры в документации и CRD называются `TimeTrigger`, а в CLI — `fission timetrigger`.
|
||
|
||
## Official docs used as source of truth
|
||
|
||
- https://fission.io/docs/usage/triggers/
|
||
- https://fission.io/docs/usage/triggers/timer/
|
||
- https://fission.io/docs/reference/crd-reference/
|
||
- https://fission.io/docs/reference/fission-cli/fission_timetrigger/
|
||
- https://fission.io/docs/reference/fission-cli/fission_timetrigger_create/
|
||
- https://fission.io/docs/reference/fission-cli/fission_timetrigger_showschedule/
|
||
|
||
## Facts to keep in mind
|
||
|
||
- There is no dedicated `/docs/cron/` page on the official site; relevant official page is `Timer Triggers`.
|
||
- Timer triggers run functions on a schedule.
|
||
- Cron spec supports 6 fields: seconds, minutes, hours, day of month, month, day of week.
|
||
- Readable forms are supported too: `@every 5m`, `@hourly`.
|
||
- Schedule output should use server time, not client time.
|
||
|
||
## CRD facts
|
||
|
||
- `apiVersion`: `fission.io/v1`
|
||
- `kind`: `TimeTrigger`
|
||
- `spec.cron` — cron expression
|
||
- `spec.functionref` — function reference
|
||
- `spec.method` — HTTP method, default `POST`
|
||
- `spec.subpath` — subpath, default `/`
|
||
- `functionref.type` is `name`
|
||
- `functionref.name` is the function name
|
||
|
||
## CLI facts
|
||
|
||
### `fission timetrigger`
|
||
Subcommands from official docs:
|
||
- `create`
|
||
- `delete`
|
||
- `list`
|
||
- `showschedule`
|
||
- `update`
|
||
|
||
### `fission timetrigger create`
|
||
Key flags:
|
||
- `--name`
|
||
- `--function`
|
||
- `--cron`
|
||
- `--method`
|
||
- `--subpath`
|
||
- `--spec`
|
||
- `--dry`
|
||
|
||
### `fission timetrigger showschedule`
|
||
Key flags:
|
||
- `--cron`
|
||
- `--round`
|
||
|
||
## Repo facts
|
||
|
||
Current repo has a local CRON folder with:
|
||
- `CRON/README.md`
|
||
- `CRON/CLI.md`
|
||
- `CRON/CRD.md`
|
||
- `CRON/EXAMPLES.md`
|
||
- `CRON/GLOSSARY.md`
|
||
|
||
Relevant console routes currently visible in code:
|
||
- `GET /api/timetriggers`
|
||
- `GET /console/api/timetriggers`
|
||
|
||
This means current console code clearly exposes listing for timetriggers; do not assume create/delete UI is already implemented unless verified separately.
|
||
|
||
## What the plan should optimize for
|
||
|
||
- shortest path to useful outcome
|
||
- no token waste
|
||
- no speculative implementation details
|
||
- only actions that are justified by the facts above
|
||
|
||
## Recommended output format for GPT 5.4
|
||
|
||
1. One-line conclusion
|
||
2. Short numbered plan
|
||
3. Risks or unknowns, only if they block the plan
|
||
4. No extra explanation
|
||
|
||
## Plan for mini
|
||
|
||
1. Зафиксировать целевой результат: что именно нужно сделать с cron в этом проекте.
|
||
Нужно выбрать одно из трёх:
|
||
`документация`, `console API CRUD`, `UI CRUD/просмотр`, либо полный путь поэтапно.
|
||
|
||
2. Принять официальный термин как базовый.
|
||
В коде и плане опираться на `TimeTrigger`/`timetrigger`, а не на абстрактное “cron”, чтобы не путать CLI, CRD и UI.
|
||
|
||
3. Разделить текущее состояние на “уже есть” и “надо сделать”.
|
||
Уже есть:
|
||
`официальная сводка`, `CRON docs`, `GET /api/timetriggers`, `GET /console/api/timetriggers`.
|
||
Проверить отдельно:
|
||
есть ли `POST/DELETE/UPDATE` для timetriggers в console API, модель запроса, UI-форма, UI-delete.
|
||
|
||
4. Если цель именно реализация, сначала закрыть backend API.
|
||
Минимальный набор:
|
||
`CreateTimeTriggerRequest`,
|
||
`POST /console/api/timetriggers`,
|
||
`DELETE /console/api/timetriggers/:name`,
|
||
при необходимости `PUT`.
|
||
Логика должна строить CRD `fission.io/v1`, `kind: TimeTrigger` с полями:
|
||
`cron`, `functionref`, `method`, `subpath`.
|
||
|
||
5. После backend закрыть валидацию.
|
||
Нужно валидировать:
|
||
имя,
|
||
существование функции,
|
||
непустой `cron`,
|
||
при необходимости `method`,
|
||
дефолты для `method=POST`, `subpath=/`.
|
||
Отдельно не гадать формат cron вручную, если можно отдать это на Fission/его контракт.
|
||
|
||
6. Затем делать UI только после подтверждённого backend.
|
||
Минимум:
|
||
список timetriggers,
|
||
создание,
|
||
удаление,
|
||
опционально редактирование.
|
||
Если UI не нужен сейчас, не тратить на него время.
|
||
|
||
7. Тестировать в том же порядке.
|
||
Сначала unit/integration на API builder TimeTrigger.
|
||
Потом живой сценарий:
|
||
создать функцию,
|
||
создать timetrigger,
|
||
проверить list,
|
||
проверить delete.
|
||
`showschedule` использовать как вспомогательную проверку cron-строк, а не как часть console API.
|
||
|
||
8. Документацию держать синхронно с реализацией.
|
||
Обновлять только новую папку CRON и соседние материалы, не размазывая контекст по старым документам без необходимости.
|
||
|
||
9. Не делать лишнего на первом проходе.
|
||
Не трогать:
|
||
Terraform provider,
|
||
сложный scheduler,
|
||
расширенные cron-валидаторы,
|
||
полный UI-редизайн,
|
||
пока не готов минимальный CRUD по TimeTrigger.
|
||
|
||
10. Рабочий порядок для mini:
|
||
сначала поиск фактов в коде,
|
||
потом backend routes/models/handlers,
|
||
потом тесты,
|
||
потом UI,
|
||
потом короткая проверка живым сценарием.
|