Projects: ProjectV2Workflow exposes no configuration

[MarkBennett]

What's happening

ProjectV2Workflow tells you that a workflow exists and whether it's on. It tells you nothing about what it does.

{ __type(name: "ProjectV2Workflow") { fields { name } } }

createdAt, databaseId, enabled, fullDatabaseId, id, name, number, project, updatedAt

For a built-in auto-add workflow, neither its target repository nor its filter is readable. The same is true of every other built-in workflow's configuration. A project's automation is visible only in the UI, which is also the only place it can be changed.

Why it matters

Board membership is the most serious failure mode in a project-driven process. An issue that never became a project item has no Status, no Cycle, no state at all — it's invisible to every query that reads the board. It doesn't show up as wrong, it shows up as absent, which is much harder to notice.

The auto-add workflows are the first line of defence against that, and they're configurable only by hand. A reconciler that reads the API can detect the symptom — issues in a repo that aren't project items — but never the cause: a workflow disabled, repointed at a different repository, or its filter narrowed. A repo could quietly stop flowing onto the board and the only signal would be a slowly growing backfill count in a nightly job.

enabled is the one useful bit that is exposed, and it isn't enough on its own: a workflow that is enabled but pointed at the wrong repository is indistinguishable through the API from a correct one.

The ask

Expose workflow configuration on ProjectV2Workflow. Read-only is enough to close the audit gap. At minimum, for auto-add: the target repository and the filter. Ideally the same for the other built-ins (item added to project, auto-archive, auto-close), so that a project's automation can be asserted from a script instead of eyeballed in the UI.

Write access would be better still — it would let a project's automation be provisioned as code, and restored after an accidental change — but read is the part that turns "we think this is set up correctly" into something checkable.

Related

Same pattern as a view's contents cannot be read from any API: the definition is readable, the behaviour is not. Together they mean a project's automation is essentially unauditable by script.

[github-actions[bot]]

Thank you for your interest in contributing to our community! We currently only accept discussions created through the GitHub UI using our provided discussion templates. Please re-submit your discussion by navigating to the appropriate category and using the template provided.

This discussion has been closed because it was not submitted through the expected format. If you believe this was a mistake, please reach out to the maintainers.