GitHub Issues Intake

[fkukuck]

PR Summary: GitHub Issue Intake

Adds github_issue automation triggers. Labeling a matching GitHub issue now creates and starts an automation run, passes issue metadata as inputs, records the run's issue source, and optionally comments back on the issue.

Highlights

• New AutomationTrigger::GithubIssue with trigger_label, optional issue_label, and comment.
• GitHub issues.labeled starts matching automations; PR-shaped issue events are ignored.
• issues.unlabeled closes the trigger cycle so re-labeling can start another run.
• Delivery IDs and open-cycle markers prevent duplicate runs.
• Webhooks acknowledge quickly; materialization/start happens in the background.
• Shared automation_runner path now handles API, scheduled, and GitHub issue-triggered runs.
• Runs expose RunSourceContext::GithubIssue and issue links in API/web projections.
• Workflows receive issue inputs like github_issue_url, github_issue_title, github_issue_body, github_repository, and github_delivery_id.

Surface Area

• Server: webhook parsing/dispatch, trigger matching, dedupe, comments, source context.
• Store: persisted trigger run records and open-cycle markers.
• API/client: OpenAPI, Rust replacements/tests, generated TypeScript models.
• Web: automation form trigger controls and GitHub issue source links in run UI.
• Docs: GitHub integration section, API nav, changelog entry.

Tests

• Server coverage for label matching, PR filtering, dedupe, relabel behavior, comments, and prompt webhook ack.
• Store coverage for delivery markers, open cycles, close behavior, and encoded paths.
• API/type/web tests updated for github_issue triggers and GitHub issue run source context.

[fkukuck]

#474 now limited the use of templating vars. We should discuss on how to proceed. Should we populate env vars instead?

[swerner]

@fkukuck I browsed through this PR, but I'm not exactly sure where you'd be using vars or env. In the [run.inputs] block? Do you have any examples?

We're really interested in learning about the use cases to make sure we have everything covered that should allow interpolation. Once this track of work is finished, for most things you'll be able to select from env vars inputs and secrets and there should be consistent handling across the fields that support them.

[fkukuck]

Well the solution was a little cumbersome, but worked. It was a node in workflow.fabro:

    intake [
        label="Intake",
        shape=parallelogram,
        script="mkdir -p artifacts/intake/raw && \
cat > artifacts/intake/raw/github_issue_title.txt <<'FABRO_GITHUB_ISSUE_TITLE_EOF'
{{ inputs.github_issue_title }}
FABRO_GITHUB_ISSUE_TITLE_EOF
cat > artifacts/intake/raw/github_issue_url.txt <<'FABRO_GITHUB_ISSUE_URL_EOF'
{{ inputs.github_issue_url }}
FABRO_GITHUB_ISSUE_URL_EOF
cat > artifacts/intake/raw/github_issue_number.txt <<'FABRO_GITHUB_ISSUE_NUMBER_EOF'
{{ inputs.github_issue_number }}
FABRO_GITHUB_ISSUE_NUMBER_EOF
cat > artifacts/intake/raw/github_issue_author.txt <<'FABRO_GITHUB_ISSUE_AUTHOR_EOF'
{{ inputs.github_issue_author }}
FABRO_GITHUB_ISSUE_AUTHOR_EOF
cat > artifacts/intake/raw/github_repository.txt <<'FABRO_GITHUB_REPOSITORY_EOF'
{{ inputs.github_repository }}
FABRO_GITHUB_REPOSITORY_EOF
cat > artifacts/intake/raw/github_issue_body.txt <<'FABRO_GITHUB_ISSUE_BODY_EOF'
{{ inputs.github_issue_body }}
FABRO_GITHUB_ISSUE_BODY_EOF
FABRO_GITHUB_ISSUE_TITLE_FILE=artifacts/intake/raw/github_issue_title.txt \
FABRO_GITHUB_ISSUE_URL_FILE=artifacts/intake/raw/github_issue_url.txt \
FABRO_GITHUB_ISSUE_NUMBER_FILE=artifacts/intake/raw/github_issue_number.txt \
FABRO_GITHUB_ISSUE_AUTHOR_FILE=artifacts/intake/raw/github_issue_author.txt \
FABRO_GITHUB_REPOSITORY_FILE=artifacts/intake/raw/github_repository.txt \
FABRO_GITHUB_ISSUE_BODY_FILE=artifacts/intake/raw/github_issue_body.txt \
.fabro/workflows/software_factory/scripts/intake_markdown.sh"
    ]

and the script would make use of these env variables. But probably we need a better solution

[brynary]

Closing in favor of #519 to keep the PR list tidy.