[schema-coverage] feat: Add schema coverage demo for container field

[github-actions]

Schema Coverage Demo

This PR adds a minimal demo workflow that demonstrates usage of the container field in the gh-aw frontmatter schema.

Why: The schema feature coverage checker found that container was not used in any existing workflow.

What: Adds schema-demos/schema-demo-container.md with a valid, minimal demonstration of this field.

Field Description

Container to run the job steps in.

Validation

• Coverage grep confirms schema-demos/schema-demo-container.md now contains the top-level container key.
• make build && make fmt could not complete because this runner has Go 1.24.13 locally, while go.mod requires Go 1.25.8, and the toolchain download from proxy.golang.org is blocked by the environment firewall.
• make fmt is blocked by the same missing Go 1.25.8 toolchain.

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• proxy.golang.org

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "proxy.golang.org"

See Network Configuration for more information.

Generated by 📊 Schema Feature Coverage Checker · ◷

• expires on May 25, 2026, 7:55 AM UTC

[pelikhan]

@copilot investigate how this field is used

[Copilot]

@copilot investigate how this field is used

The container field has two distinct usages in gh-aw:

1. Top-level frontmatter field (what this demo covers)

Configures the container in which the main agent job steps run — mirroring the native GitHub Actions jobs.<job_id>.container field. It can be a simple image string or a configuration object:

# Simple form
container: node:18

# Object form
container:
  image: ubuntu:latest
  credentials:
    username: ${{ secrets.DOCKER_USER }}
    password: ${{ secrets.DOCKER_PASSWORD }}
  env:
    MY_VAR: value

The value is extracted from the frontmatter in workflow_builder.go (workflowData.Container = c.extractTopLevelYAMLSection(frontmatter, "container")), then injected into the compiled main agent job in compiler_main_job.go.

2. MCP server tool field (in mcp-servers:)

Within an individual MCP server entry, container specifies a Docker image to run that server as a containerized stdio tool instead of using command:

mcp-servers:
  my-tool:
    container: myregistry/my-mcp-server:latest

This is parsed in mcp.go and mcp_config_custom.go, which build a Docker-based stdio transport for the tool.

[Copilot]

Pull request overview

Adds a minimal schema coverage demo workflow for the top-level container frontmatter field.

Changes:

• Adds schema-demos/schema-demo-container.md.
• Demonstrates a valid container object with image: ubuntu:latest.
• Includes a minimal noop task consistent with existing schema demo files.

Show a summary per file

File	Description
schema-demos/schema-demo-container.md	Adds the schema coverage demo for the container field.

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

• Files reviewed: 1/1 changed files
• Comments generated: 0

[github-actions]

Skills-Based Review 🧠

Applied /grill-with-docs — this PR adds a new schema demo file, making it a documentation/vocabulary addition worth checking for consistency with the project model.

Assessment

• ✅ container is a valid top-level property in main_workflow_schema.json — the demo correctly targets the right field
• ✅ File naming (schema-demo-container.md) and structure match existing demos (schema-demo-labels.md, schema-demo-metadata.md) exactly
• ✅ Frontmatter structure (engine, permissions, timeout-minutes, on: workflow_dispatch) is consistent with peer demos
• ✅ Task body correctly instructs the agent to call noop — appropriate for a coverage-only workflow

Verdict

Approve — this is a clean, targeted schema coverage addition with no issues found.

🧠 Reviewed using Matt Pocock's skills by Matt Pocock Skills Reviewer · ● 5.5M