Add GitHub Actions build type

[TomHennen]

Problem

Wrangle itself is categorized as a "shell" project type, but it's really a GitHub Actions project. The shell build type (shellcheck + bats) misses key functionality:

• No validation that composite actions work end-to-end
• No testing of uses: step resolution, env propagation, step outputs
• No verification that SARIF ends up at expected paths
• actionlint runs in CI but isn't part of the build type

Many other projects that ship GitHub Actions have the same gap.

What a GitHub Actions build type could include

Source stage:

• actionlint on all workflow/action YAML
• shellcheck on all .sh files
• zizmor for Actions-specific security linting
• bats tests

Build stage:

• Run act to validate actions work end-to-end (Add local action testing via act #115)
• Validate action metadata (descriptions, input types, pinned SHAs)
• Check for common anti-patterns
• SBOM generation (see below)
• Vuln scan the SBOM via OSV-Scanner

Release stage:

• Tag validation
• Publish to GitHub Marketplace (if applicable)
• Generate attestation for the release

SBOMs: all build types must have them

All build types have dependencies and all dependencies can have vulnerabilities. "No compiled artifact" does not mean "no SBOM." The spec should require SBOMs for all build types.

Research needed: Before building custom SBOM generation, we should evaluate whether existing tools already handle GitHub Actions dependencies:

• Anchore's sbom-action / Syft — Syft has been expanding its catalogers; it may already enumerate uses: references or other GHA-specific dependencies. Needs testing.
• GitHub's Dependency Graph SBOM export — GitHub understands uses: references in its dependency graph. Their SBOM export (SPDX 2.3) may already include these. Needs testing.
• cdxgen, Trivy — worth checking if they've added GHA support.

If existing tools cover this, wrangle should use them rather than reinvent. If they don't (or coverage is incomplete), wrangle could fill the gap — e.g., a wrangle SBOM generator that:

• Parses uses: references from workflow/action YAML → SBOM components
• Parses Docker image references from container steps
• Parses pinned tool versions from install scripts
• Feeds the SBOM to OSV-Scanner for vuln scanning

The same approach applies to shell projects — enumerate binary dependencies, sourced scripts, tool versions.

Why this matters for wrangle itself: Right now OSV-Scanner reports "no package sources found" on the wrangle repo because there are no traditional manifests. But wrangle has real dependencies (actions, tools, Docker images) with real vulnerabilities. An SBOM would make those scannable.

Spec updates needed

• Add GitHub Actions build type to build/actions/ table
• Require SBOMs for all build types (not just those with compiled artifacts)
• Clarify that "build" encompasses validation-only project types
• Define what SBOM means for non-traditional project types (actions, shell)
• Consider whether "release" for an action (tagging, marketplace publish) fits the existing stage model

Broader question: what is a "build"?

The spec defines the build stage as "compile, generate SBOM, scan SBOM." But for actions and shell projects, there's no compilation. The lifecycle stages need to be flexible enough to handle:

• Build types that produce publishable artifacts (container, binary, package)
• Build types that validate correctness without a publishable artifact (shell, actions)
• All build types generating SBOMs (dependency enumeration)
• "Release" meaning different things per type (push to registry vs tag vs marketplace)

Related

• Add local action testing via act #115 — Local action testing via act
• Restore scan output model: step summary as primary UX, metadata dir as attestation source #114 — Scan output model
• build/actions/shell/ — closest existing analog