Summary
Job identifiers in .circleci/config.yml and .github/workflows/ use four different naming styles for the same kind of thing. Unlike step display names, job identifiers surface as status-check contexts, and branch protection rulesets reference those contexts from repository settings that live outside the repository - so renaming a job can silently stop a required check from ever being satisfied.
This was found during a codebase convergence audit of main. The step display names were converged in that pass; the job identifiers were deliberately left alone and raised here, because fixing them safely requires coordinating with the branch ruleset rather than just editing the config.
Details
The four coexisting styles:
kebab-case - assign-author, release-drafter, vr-compare, update-dependencies, vortex-test-common, vortex-test-docs, vortex-test-installer.
snake_case - remove_lagoon_environment.
Generic placeholder - main, which says nothing about what the job does.
Bare nouns - lint, database, build, deploy, audit.
Related identifier drift in the same files, worth settling in the same pass:
- Step ids mix snake_case (
resolve_pr, gate, compare, result, summary) with kebab-case (check-requirements) and bare words (calver, version, netlify).
- Job and step outputs mix snake_case (
diff_id, pr_number, changes_percent, should_run, skipped) with kebab-case (release-version) and a bare value.
- Workflow display names mix a title-case list (
Database, Build, Test and Deploy), sentence case (Security audit, Draft release notes), quoted title case (Auto Author Assign, Close Pull Request) and a dash-prefixed family (Test - Visual regression, Vortex - Test).
- Three filename versus display name mismatches:
vortex-release.yml is named Vortex - Release docs but also contains the installer job; vortex-test-common.yml is named just Vortex - Test; build-test-deploy.yml is named Database, Build, Test and Deploy while its filename omits the database stage.
Suggested approach
Before renaming any job, enumerate which contexts the branch ruleset currently requires. Rename the job and update the required-context list together, otherwise the protection silently waits forever on a context nothing will ever report.
Step ids, outputs and workflow display names carry none of that risk and can be converged freely in the same change.
Summary
Job identifiers in
.circleci/config.ymland.github/workflows/use four different naming styles for the same kind of thing. Unlike step display names, job identifiers surface as status-check contexts, and branch protection rulesets reference those contexts from repository settings that live outside the repository - so renaming a job can silently stop a required check from ever being satisfied.This was found during a codebase convergence audit of
main. The step display names were converged in that pass; the job identifiers were deliberately left alone and raised here, because fixing them safely requires coordinating with the branch ruleset rather than just editing the config.Details
The four coexisting styles:
kebab-case -
assign-author,release-drafter,vr-compare,update-dependencies,vortex-test-common,vortex-test-docs,vortex-test-installer.snake_case -
remove_lagoon_environment.Generic placeholder -
main, which says nothing about what the job does.Bare nouns -
lint,database,build,deploy,audit.Related identifier drift in the same files, worth settling in the same pass:
resolve_pr,gate,compare,result,summary) with kebab-case (check-requirements) and bare words (calver,version,netlify).diff_id,pr_number,changes_percent,should_run,skipped) with kebab-case (release-version) and a barevalue.Database, Build, Test and Deploy), sentence case (Security audit,Draft release notes), quoted title case (Auto Author Assign,Close Pull Request) and a dash-prefixed family (Test - Visual regression,Vortex - Test).vortex-release.ymlis namedVortex - Release docsbut also contains the installer job;vortex-test-common.ymlis named justVortex - Test;build-test-deploy.ymlis namedDatabase, Build, Test and Deploywhile its filename omits the database stage.Suggested approach
Before renaming any job, enumerate which contexts the branch ruleset currently requires. Rename the job and update the required-context list together, otherwise the protection silently waits forever on a context nothing will ever report.
Step ids, outputs and workflow display names carry none of that risk and can be converged freely in the same change.