feat: support concurrency.queue in workflow schema

[xenjke]

Summary

Workflows using the documented concurrency.queue property are currently rejected by act's schema with Unknown Property queue. GitHub added queue to the concurrency mapping (docs, added in github/docs@336b7f5); it accepts single (default) or max. This PR mirrors SchemaStore's existing encoding in act's hand-maintained schema so those workflows validate.

Fixes #6095.

Changes

• pkg/schema/workflow_schema.json — add a top-level concurrency-queue definition (allowed-values: ["single", "max"], following the precedent of branch-protection-rule-activity-type at line 188) and reference it from concurrency-mapping.properties.queue.
• pkg/schema/schema_test.go — add TestConcurrencyQueue covering single, max, job-level placement, and an invalid value.

Out of scope

The docs state that queue: max combined with cancel-in-progress: true is a workflow validation error. act's schema engine (checkMapping in pkg/schema/schema.go) validates each property in isolation, so cross-property constraints cannot be expressed in the current schema vocabulary. SchemaStore makes the same trade-off — queue is encoded as an enum but the mutual exclusion is left to prose. Can be revisited as a follow-up.

Test plan

• go test ./pkg/schema/... — new test passes (TestConcurrencyQueue + existing tests)
• golangci-lint run ./... — no issues
• go fmt ./... / go mod tidy — no diff
• Positive e2e: act -l against a workflow with concurrency.queue: max now lists jobs instead of erroring
• Negative e2e: concurrency.queue: bogus errors with Expected one of single,max got bogus

References

• GitHub docs: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#concurrency
• Docs change that introduced queue: github/docs@336b7f5
• SchemaStore precedent: https://raw.githubusercontent.com/SchemaStore/schemastore/master/src/schemas/json/github-workflow.json (#/definitions/concurrency)
• Related cross-reference in actionlint: Actionlint does not know about queue: key for concurrency rhysd/actionlint#657, concurrency: Add support for queue key rhysd/actionlint#654

[McNultyyy]

Apologies — I opened #6152 covering the same concurrency.queue schema gap without spotting this PR first. You filed #6095 and had a fix up a minute later; mine came months afterwards and I should have checked the open PRs, not just the issues. This one has precedence.

Having read the diff, I think yours is the better-scoped fix for #6095: schema-only, with table-driven cases in pkg/schema/schema_test.go covering workflow level, job level, and the invalid-value rejection. That is exactly what the issue asks for and nothing more.

I have retitled #6152 so it no longer claims to close #6095 and it now points here. The only thing it carries beyond your change is the pkg/model side — a Concurrency struct with Group/CancelInProgress/Queue and the parsing for it — which is only actually needed by the runtime work I am doing separately, so it belongs with that rather than with this fix.

Happy to do whichever you prefer: close #6152 entirely and move the model bits into my runtime PR, or leave it as a follow-up that rebases on top of yours once this lands. If it is useful I can also open a PR against your branch with the extra pkg/model tests.

[xenjke]

Thanks for taking a look @McNultyyy. This is the smaller schema-only fix, would it make sense to merge it first and then rebase #6152 on top for the pkg/model follow-up? Up to @cplee 🙏

[McNultyyy]

Sounds like a plan.

My larger-scale idea is to get the work in #6147 reviewed and merged. However I appreciate that it is a mammoth change and will need to be broken down and reviewed in smaller manageable pieces.

Keen to hear both of your ideas on this and where best to have this conversation / discussion , as to not pollute this thread.

[sampathintouch]

@cplee — independent verification of this change, in case it helps it move.

I hit #6095 while evaluating act for a GitHub Enterprise Server monorepo (75 workflows, 112 jobs, an 18-workflow reusable-workflow fan-out). Before finding this PR I wrote the same fix from scratch and landed on an identical implementation — same queue property, same concurrency-queue definition, same allowed-values: ["single", "max"]. Two independent attempts converging suggests this is the idiomatic shape for the schema dialect rather than one option among several.

I built this branch (9896075) and tested it against the real repository:

• Both affected workflows parse; stock 0.2.89 rejects both.
• queue: single and queue: max accepted at workflow level and job level.
• queue: bogus still rejected — the enum is enforced, so this doesn't loosen validation.
• The full dispatcher resolves a job through the reusable-workflow chain that previously failed outright.
• go test ./pkg/schema/... ./pkg/model/... pass; go vet and gofmt clean.

One detail that may not be obvious from the issue: the blast radius is larger than a single ignored key. Because an unknown property makes the whole job block fail to match, one queue: max cascades into misleading Unknown Property runs-on / outputs / steps errors and takes the entire file down. Worse, any workflow that uses: the affected file fails too — so a single key on one reusable workflow can make an entire pipeline unrunnable locally, which is how it presented for us.

Since queue is documented GitHub syntax (May 2026 changelog) and already encoded in SchemaStore, this is a straightforward correctness gap rather than a new feature. It's currently a hard adoption blocker for us; happy to help with whatever this needs to land.