@gapi/gcli 1.8.246 → 1.8.247

package/README-CLI.md

@@ -79,6 +79,9 @@ Commands:
   workflow:runs [options]                              List a workflow runs, newest first
   workflow:status [options]                            Show a run: its step events, error and output (--follow until it ends)
   workflow:cancel [options]                            Cancel a running run
+  workflow:trigger:add [options]                       Start runs from an HTTP URL (--http; the JSON body is the input) or a schedule (--cron). Needs Fission 1.26+ on the cluster
+  workflow:trigger:list [options]                      List a workflow HTTP and schedule triggers
+  workflow:trigger:remove [options]                    Remove a workflow trigger
   help [command]                                       display help for command
 
 --- Subcommand: login ---
@@ -1134,3 +1137,43 @@ Options:
   -n, --name <name>        Workflow name
   -r, --run <run>          Run name (see workflow:runs)
   -h, --help               display help for command
+
+--- Subcommand: workflow:trigger:add ---
+Usage: gcli workflow:trigger:add [options]
+
+Start runs from an HTTP URL (--http; the JSON body is the input) or a schedule (--cron). Needs Fission 1.26+ on the cluster
+
+Options:
+  -p, --project <project>
+  -n, --name <name>        Workflow name
+  --http                   An HTTP trigger: <router>/<project>/workflows/<path>
+  --path <path>            HTTP path under /workflows/ (default: the workflow
+                           name)
+  --method <methods>       HTTP methods, comma separated (default POST)
+  --cron <schedule>        A schedule: "@every 1h", "0 9 * * 1-5", "@daily"
+                           (UTC)
+  -i, --input <json>       Schedule: the input of every run (default {})
+  --input-file <file>      Schedule: read the run input from a JSON file
+  -h, --help               display help for command
+
+--- Subcommand: workflow:trigger:list ---
+Usage: gcli workflow:trigger:list [options]
+
+List a workflow HTTP and schedule triggers
+
+Options:
+  -p, --project <project>
+  -n, --name <name>        Workflow name
+  -h, --help               display help for command
+
+--- Subcommand: workflow:trigger:remove ---
+Usage: gcli workflow:trigger:remove [options]
+
+Remove a workflow trigger
+
+Options:
+  -p, --project <project>
+  -n, --name <name>        Workflow name
+  -t, --trigger <trigger>  Trigger id, path or schedule (see
+                           workflow:trigger:list)
+  -h, --help               display help for command

package/README.md

@@ -788,6 +788,24 @@ gcli workflow:validate -f order-flow.yaml
 gcli workflow:delete --name order-flow                        # also deletes its runs
 ```
 
+**Triggers** start runs without anyone calling `workflow:run` (Fission 1.26+
+on the workflow's cluster creates the run itself):
+
+```bash
+# An HTTP URL: every request starts a run, the JSON body is the run input,
+# the answer is 202 {"run": "..."}; default path = the workflow name, POST
+gcli workflow:trigger:add --name order-flow --http --path orders --method POST
+curl -X POST 'https://functions.lambforge.com/<projectId>/workflows/orders' -d '{"orderId": 42}'
+
+# A schedule (UTC) with a fixed run input
+gcli workflow:trigger:add --name nightly-report --cron "0 6 * * *" --input '{"scope": "all"}'
+
+gcli workflow:trigger:list --name order-flow
+gcli workflow:trigger:remove --name order-flow --trigger orders   # id, path or schedule
+```
+
+`workflow:runs` shows how each run started (`manual`, `http`, `schedule`).
+
 The file `workflow:get` / `workflow:generate` write (and `workflow:apply`
 reads) - a Fission `kind: Workflow` manifest or a bare `startAt` + `states`
 works too:

package/docs/changelog.d/2026-10-26-workflows-workflow-trigger-commands-for-http-and-schedule-triggers.md

@@ -0,0 +1,23 @@
+## 2026-10-26 - workflows: workflow:trigger commands for HTTP and schedule triggers
+
+**Feature:** workflows · **Type:** feat
+
+- `workflow:trigger:add` (`--http [--path] [--method]` or `--cron
+  "<schedule>" [-i | --input-file]`), `workflow:trigger:list`,
+  `workflow:trigger:remove -t <id | path | schedule | Fission name>`
+  (`src/commands/workflow/trigger-*.ts`), on the graphql-server-lambdas
+  `addWorkflowTrigger` / `removeWorkflowTrigger` (Fission 1.26+ fork
+  `workflow-triggers` creates the runs).
+- Option handling and output are pure (`triggers.ts`: `buildTriggerInput`,
+  `findTrigger`, `triggerRow`, `runSource`); `workflow:runs` gained a `by`
+  column (manual / http / schedule). `WorkflowFragment.triggers`,
+  `WorkflowRunFragment.triggerKind / triggerName`; client calls in
+  `gql-client.ts`.
+- README Workflows section + regenerated `README-CLI.md`.
+- **Test:** `npx jest --coverage=false test/workflow.spec.ts` (11 pass, 5 new).
+- **Debug:** `Workflow triggers need Fission 1.26 or newer on this cluster`
+  is the backend saying the cluster is too old; `Pass either --http or
+  --cron` is the option check.
+- **Verification:** gcli jest 114/114; tsc + eslint clean; the new
+  mutations and fragments validated against the local gateway schema;
+  not run against production (gcli login points at production).

package/docs/features/workflows.md

@@ -17,9 +17,19 @@ the id with `listWorkflows`):
 | `workflow:validate -f file` | `validateWorkflow` (graph + lambdas on the cluster) |
 | `workflow:delete -n` | `deleteWorkflow` (runs too) |
 | `workflow:run -n [-i json \| --input-file] [--wait]` | `startWorkflowRun`; `--wait` polls `getWorkflowRun` every 2 s and prints each new event until the run is terminal |
-| `workflow:runs -n [-l]` | `listWorkflowRuns` |
+| `workflow:runs -n [-l]` | `listWorkflowRuns` (column `by`: manual / http / schedule, from `triggerKind`) |
 | `workflow:status -n -r run [--follow]` | `getWorkflowRun` (events, error, output) |
 | `workflow:cancel -n -r run` | `cancelWorkflowRun` |
+| `workflow:trigger:add -n (--http [--path] [--method a,b] \| --cron "<schedule>" [-i json \| --input-file])` | `addWorkflowTrigger`; prints the trigger and, for HTTP, a `curl` line |
+| `workflow:trigger:list -n` | the workflow's `triggers` (id, kind, URL or schedule, input) |
+| `workflow:trigger:remove -n -t <id \| path \| schedule \| Fission name>` | `removeWorkflowTrigger` |
+
+Triggers (2026-10-26) are HTTP URLs (`<router>/<projectId>/workflows/<path>`,
+the JSON body is the run input, 202 `{run}`) and schedules (cron, UTC, with a
+fixed input) that start runs. Fission 1.26+ (fork `workflow-triggers`) on the
+workflow's cluster creates the run. The option handling is pure and tested:
+`src/commands/workflow/triggers.ts` (`buildTriggerInput`, `findTrigger`,
+`triggerRow`, `runSource`).
 
 The workflow file (`definition.ts` `parseWorkflowFile`) accepts
 `workflow: {name, description, clusterId, definition}`, the same without the
@@ -37,7 +47,9 @@ USER-only in graphql-server-lambdas, so these commands need `gcli login`.
 `npx jest --coverage=false test/workflow.spec.ts`. Real: log in to a
 gateway whose project has `allowWorkflows`, then
 `gcli workflow:generate -d "..." -n demo --apply` and
-`gcli workflow:run -n demo --wait`.
+`gcli workflow:run -n demo --wait`; triggers:
+`gcli workflow:trigger:add -n demo --http`, then `curl -X POST <url> -d '{}'`
+and `gcli workflow:runs -n demo` shows the run `by` http.
 
 ## How to debug
 
@@ -47,3 +59,6 @@ gateway whose project has `allowWorkflows`, then
   `allowWorkflows`.
 - `Workflows are not enabled on this cluster`: the cluster runs Fission
   without `workflows.enabled` (canonical doc, Requires).
+- `Workflow triggers need Fission 1.26 or newer on this cluster`: the
+  cluster's Fission CRDs predate workflow triggers.
+- `Pass either --http or --cron`: exactly one of them.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gapi/gcli",
-  "version": "1.8.246",
+  "version": "1.8.247",
   "repository": {
     "type": "git",
     "url": "https://github.com/Stradivario/gapi.git"