Automation

Automation

Rules that run automatically after a mutating command (new, edit, status, comment, label, version, epic, link) and can set fields, add labels, or leave a comment, based on conditions over the task.

Adding a rule

git task config rule add \
  --name auto-triage-bugs \
  --on task.created \
  --when 'kind == "bug"' \
  --do 'set_priority high' --do 'add_label triage'

• --on (required, exactly one): task.created | status.changed | comment.added | label.added | task.updated.
• --when (optional; omit for unconditional): an evalexpr expression over kind, status, priority, assignee, title, all read as strings (empty string if the field is unset on that task).
• --do (repeatable, at least one): set_priority|status|assignee|kind|due|milestone <value>, add_label|remove_label <value>, add_fixed_version|remove_fixed_version <value>, add_affected_version|remove_affected_version <value>, add_comment "text".

Omitting --name/--on/--do starts an interactive wizard instead. Don't invoke bare config rule add from a script; a JSON caller gets a validation error telling it exactly that, rather than hanging on a prompt it can't answer.

git task config rule add --global        # write to ~/.config/git-task/automation.toml instead
git task config rule list --format json  # effective global + per-repo rules
git task config rule remove auto-triage-bugs
git task config rule remove auto-triage-bugs --global

How a rule fires

Rule actions run as their own attributed operation package, under a synthetic git-task-automation actor, visible in git task log <id> like any other author's edit. A rule fires at most once per triggering command. Its own actions can cascade into other rules (a set_status action can re-trigger a status.changed rule), but never back into the rule that's already running in this pass, so there's no infinite-loop guard to build yourself. A misconfigured rule (an unparseable --when, an action that doesn't parse back into a real operation) is skipped with a warning, not a hard failure of the command that triggered it.

Built-in automations

A small fixed catalog, disabled/enabled per-project or per-machine rather than authored as a rule:

git task automation list                          # built-ins + effective custom rules
git task automation enable auto-sync
git task automation disable auto-unassign-done
git task automation disable auto-sync --global    # this machine, not just this repo

• auto-unassign-done: clears the assignee when status is set to done. Runs ahead of any global/project custom rules for the same event.
• auto-sync: after the whole rule cascade for a command settles, spawns a detached background push+pull against origin. It's a network side effect, not a rule with a condition/action pair, so it can't be authored via config rule add; toggling it on or off is the only lever. Disable it for a single invocation with the environment variable GIT_TASK_DISABLE_AUTO_SYNC=1.

Per-project toggle state syncs with the repo like any other config change; per-machine toggle state (--global) does not.

Reading the effective set

git task config show (see Configuration) reports both built-ins and custom rules, with each rule tagged scope: "global" or "repo" so you can tell where it came from at a glance.