Skip to main content

Automations

Automations run tasks, deployment profiles, or IBM i source imports from a schedule, a manual run, an inbound webhook, or SCM polling. Each automation belongs to a single environment and usually creates normal CoderFlow tasks when it runs (an IBM i import with the auto-commit outcome instead commits and pushes imported sources directly).

Where to Manage​

  1. Open Administration -> Environments.
  2. Select an environment.
  3. Open the Automations tab.

From this tab you can create, edit, enable/disable, run now, view history, and delete automations.

Creating an Automation​

Click Add Automation and configure:

  • Name and optional Description
  • Schedule using the picker:
    • None (webhook only)
    • Daily
    • Weekly
    • Monthly (one or more days, 1-28)
    • Recurring (interval + optional time window + optional days)
    • Custom cron expression
  • Run Target:
    • Custom instructions for manual-style tasks
    • Task template (from environment templates) with parameter values
    • Deployment profile (from environment deployment profiles) with parameter values
    • IBM i Import to pull changed IBM i sources on each run (see IBM i Import Automations)
  • Agent for task-based automations:
    • Claude, Codex, Gemini, Bob, or Grok
    • Optional Claude effort level override
    • Optional Codex reasoning level override
    • Optional Grok effort level override
  • Task Name Template (supports {{date}} and {{datetime}}) for task-based automations
  • Enabled toggle

Save to activate the automation.

IBM i Import Automations​

The IBM i Import run target keeps a Git repository in step with source on an IBM i system. IBM i is pull-only, so each run is a scheduled poll: it enumerates the source members in the import profile, compares their change timestamps against the snapshot saved from the last successful sync, and acts only on what changed. An unchanged source library produces no diff, no task, and no commit.

Configure these fields:

  • Connection — the stored IBM i connection (SSH key or password) used to reach the system. See IBM i Connections.
  • Import Profile — a saved selection from the Import IBM i Sources wizard that defines which libraries, files, and members to pull. Save one with Save as profile in that wizard.
  • Build Rules Profile (optional) — also regenerates build rules from the changed IBM i objects after each import, reusing the Generate Build Rules pipeline. It must share the import profile's objx library. Leave it empty to sync source only.
  • On Deleted — what to do when a member that was present last time is now gone on IBM i:
    • Ignore leaves local files alone.
    • Mirror deletes treats the missing member as delete work in the outcome.
  • On Conflict — what to do when a local file and the IBM i member have both changed:
    • Prefer IBM i changes lets IBM i win.
    • Skip conflicted files leaves them untouched.
    • Flag in a task raises the conflict for review.
  • Outcome — how the detected delta becomes a result:
    • Auto commit and push writes, commits, and pushes the imported sources straight to the repository's branch. Deterministic, with no agent involved.
    • Agent task hands the delta to an agent, which handles conversions and conflicts. The agent and task-name settings above apply. To require human approval, enable Launch tasks pinned (and optionally completion notifications) in the automation settings; the created task then starts pinned for review.
  • Branch (optional) — a Git branch override for the outcome. Defaults to the import profile's branch.
Use a dedicated Automation-scoped connection

This automation runs headlessly and reads the connection's credentials directly — it works with any IBM i connection regardless of its Available For scope. But a connection scoped Tasks has its credentials injected into every task container in the environment, and Deploy into every deployment container. If this connection needs broader IBM i authority than an interactive user's own connection would, create it with Available For set to Automation only (and no IBM i Features checked — none apply outside Task/Deploy container use) so its credentials aren't exposed anywhere else. See Available For.

How the Snapshot Advances​

Each automation stores the member snapshot from its last successful sync. The snapshot advances only after the outcome succeeds, so if a run fails (a download error, a rejected commit, an agent failure) the same delta is retried on the next tick rather than silently skipped. When a build rules profile is attached, the object snapshot it tracks advances under the same rule.

Prerequisites​

  • An IBM i connection with a stored SSH key or password, created under the environment's IBM i connections.
  • An import profile saved from the Import IBM i Sources wizard.
  • For reactive build rules, a build-rules profile from the Generate Build Rules wizard that targets the same objx library as the import profile.

Git Authentication for Scheduled Runs​

Scheduled automations run as a background system action, not as the interactive user who created them.

  • Repository operations for scheduled automation tasks use the configured app/provider identity
  • Provider audit logs will show the app/bot identity rather than an individual user
  • If a repository or branch policy requires a real user identity, scheduled pushes may still be blocked by the provider

Webhook Triggers​

Automations can also be triggered by inbound webhooks. Create a webhook from the Webhooks subtab, copy its inbound URL, and configure the external system to send a POST request to that URL.

The inbound URL has this shape:

https://<server>/api/webhooks/inbound/<token>

Webhook tokens are secret. Rotate the token if it is exposed, and use signature verification when the sender supports it.

For signature schemes, payload variables, delivery history, GitHub and Stripe examples, webhook-only ingress, and SCM polling, see Webhooks & SCM Triggers.

Optional Webhook-Only Ingress Listener​

By default, inbound webhook routes are served by the main CoderFlow server. Production deployments can instead start a second webhook-only HTTP listener and expose only that port publicly while keeping the main CoderFlow application port private.

This is route and port isolation, not process isolation. The listener runs inside the same Node process as the main CoderFlow server, so it reduces the public HTTP route surface but is not a separate process, user, container, or privilege boundary.

Set one of the following before starting the server:

WEBHOOK_INGRESS_MODE=listener
WEBHOOK_INGRESS_PORT=3003
WEBHOOK_INGRESS_HOST=0.0.0.0

WEBHOOK_INGRESS_PORT by itself also enables listener mode. WEBHOOK_INBOUND_PORT and WEBHOOK_INBOUND_HOST are accepted aliases.

The webhook-only listener serves:

  • GET /health
  • POST /api/webhooks/inbound/:token

It does not serve the CoderFlow web UI, authenticated APIs, webhook management APIs, or static assets. When using a separate public hostname or port, configure the external provider with that listener's base URL plus the inbound token path.

Schedule Notes​

The schedule picker stores a cron expression internally.

Examples:

  • Daily at 2:00 AM -> 0 2 * * *
  • Weekly Monday 9:00 AM -> 0 9 * * 1
  • Monthly 1st at midnight -> 0 0 1 * *
  • Monthly 1st and 16th at midnight -> 0 0 1,16 * *
  • Every 30 minutes -> */30 * * * *
  • Every 30 minutes, 9 AM-5 PM, weekdays -> */30 9-17 * * 1,2,3,4,5

Managing Existing Automations​

Each row in the Automations table provides:

  • On/Off toggle to enable or disable scheduling
  • Run Now to trigger immediately
  • History to view recent runs and linked tasks
  • Edit to update configuration
  • Delete to remove the automation

Run History​

History shows:

  • Trigger time
  • Trigger source (manual, schedule, webhook, or scm-poll)
  • Run status
  • Link to the generated task or deployment result

For SCM polling runs, history also shows the old and new commit SHA, commit message, and commit link when the provider supplies them.

Task-based automations can open the main task list filtered by automation. Deployment automations link to the environment's deployment history for the selected profile.

Task List Integration​

Automation-created tasks can be filtered from the main task board with:

  • index.html?automation=<automationId>

When this filter is active, the task board shows a filter banner. Automation tasks also show an automation badge on task tiles linking back to the automation history view.