Relationships
#3060 Decide a stricter naming rule for workflow step and job names
Opened by skunk-ape · 10/6/2026
Context
swamp-club#3027 narrows step and job names to exclude control characters (C0 including tab and newline, DEL, C1), with space as the only whitespace. That keeps the leniency of the original z.string().min(1) rule while removing edge cases nothing needs.
Every other user-facing identifier in the domain has a real pattern: workflow names are lowercase alphanumerics and hyphens (WORKFLOW_NAME_PATTERN in src/domain/workflows/workflow.ts), as are definition names, data namespaces and extension names. Step and job names are the only user-authored identifiers that still accept almost any string.
What leans toward a stricter rule
- Every documented expression example uses dot access (steps.build.outputs.sha), which only parses for CEL identifiers.
- Step names are typed as bare CLI arguments to workflow approve, reject and resume --from, and embedded in quoted CEL literals in the suggested data queries.
- Every bundled and verification workflow uses kebab-case names.
What leans against
- The expression layer explicitly supports bracket access (steps["build-app"].status) and the swamp skill documents it for hyphenated and forEach-expanded names.
- forEach-expanded names are built from item values at run time, so a strict pattern would need a rule for expansions too.
- Any user workflow with spaces or uppercase in a step name breaks, and we cannot see how many exist.
Ask
Decide whether step and job names should get a kebab-case style pattern like workflow names, and if so what the deprecation path looks like (warning first, then refusal). This is a product decision, not a technical necessity, and should not block the #3027 fix.
Open
No activity in this phase yet.
skunk-ape commented 10/6/2026, 12:55:12 PM
Data from the 2026-10-06 registry scan (latest stable, rc and beta of every extension: 1,775 extensions, 1,882 versions, 444 workflow files, 2,854 step and job names), plus the swamp-extensions corpus on origin/main and this repo's test suites.
Names that fail the workflow-name rule as written: 139 in 17 extensions. Of those, 84 are forEach templates whose only offending characters sit inside the expression delimiters, for example diagnose-{{ [HOST-1] }} written with the usual dollar-brace syntax. With expressions masked, 55 names in 3 extensions fail, all because of underscores (advance_01 in @hivemq/asdlc, by_type and critical_findings in @webframp/aws/securityhub-findings, triage_reviews in @webframp/operator-briefing). With the definition-name rule, which also allows underscore, zero authored names fail. No authored name contains a literal space.
The blocker is expansion, not authoring. Expanded forEach names pass through the Step schema during evaluation and when a run is rehydrated for resume, and the values come from Kubernetes service names, Tailscale device ids, Forgejo repository names and similar, which carry dots, uppercase and slashes. Applying the definition-name rule to both schemas in this repo failed 4 of 3,716 tests: two property tests generating arbitrary names, one fixture using jobA and stepA, and the forEach platform test, whose template build-{{ self.arch }} expands over linux/amd64 to build-linux/amd64 and is refused. So a stricter rule needs either an exemption for expanded names (a separate validation path) or slugified expansions, which would change the bracket-access references authors already wrote.
Decision in the #3027 triage: the control-character rule is the stop point for now, and this issue stays open for the discussion above.
webframp commented 10/6/2026, 8:58:44 PM
Seems logical to me. Proactively fixed up mine here in case you chose to go further https://github.com/webframp/swamp-extensions/pull/472
Sign in to post a ripple.