A green workflow is not a release request
A hypothetical museum keeps exhibit captions in GitHub. A workflow tests every branch push, while a separate authorized release process publishes the site when a reviewed version tag is created. If the workflow treats all green jobs as permission to deploy, an ordinary branch update could accidentally trigger publication. GitHub Actions exposes GITHUB_REF_TYPE, which identifies whether the ref that triggered the run is a branch or a tag. The value helps classify the event, but it does not authenticate the person who created the ref or prove the tag points to approved content. Treat it as one input to a release gate, not the gate itself.
Read the documented branch or tag value
The GitHub variables reference specifies branch and tag as the valid GITHUB_REF_TYPE values. It also distinguishes GITHUB_REF_NAME, the shorter ref name, from GITHUB_REF and other workflow context. A release condition should compare the ref type to the documented value instead of parsing a user-controlled name and hoping it starts with a particular prefix. For pull requests, the effective ref and checked-out commit can be different from a contributor branch. Record the triggering event alongside ref type before using any branch or tag conditions for release logic.
Build a test-only branch path
A branch push may run caption validation, accessibility checks and a preview build without uploading to the production site. The workflow can branch on GITHUB_REF_TYPE to identify this class of event, but should also confirm the event is one the project intentionally supports. A malicious or accidental branch name should never be interpolated into shell commands. Use least-privilege job permissions and avoid exposing production secrets to tests of untrusted code. The decision to run diagnostics and the decision to publish must be separate. Green test output is evidence about a particular checked-out revision, not a general license to deploy future content.
Handle a tag as a candidate, not an approval
A tag-triggered run is a candidate for a release workflow, not automatic proof of editorial acceptance. Before any deployment, verify the tag name against a published naming convention, confirm the commit SHA and the intended repository, and check the authorized reviewer record. Tag names can be changed in some workflows; an organization should use its branch protections, rulesets and release procedures to mitigate unauthorized ref changes. The condition GITHUB_REF_TYPE == tag is too weak as the sole requirement for publishing a public museum website. Design the production job so missing approval or mismatched source revision fails closed.
Check the event and commit together
GITHUB_EVENT_NAME, GITHUB_SHA and other context fields help explain what actually ran. For example, a tag push and a workflow_dispatch invocation could produce different assumptions about the ref. Do not infer source provenance from GITHUB_REF_TYPE alone. Store the exact event type, immutable commit reference and workflow revision in an evidence manifest. If a release tag references a different commit than the one that passed caption review, require new checks on the release target. An authorized deployment process should verify which content it is deploying rather than rely on a green badge from an unrelated run.
Compare a branch, a tag and an ambiguous run
A useful diagram shows three synthetic cases: a branch push with ref type branch and preview-only permissions; a reviewed tag with ref type tag and a separate release approval; and a manually triggered or mismatched context that is sent for explicit review. These illustrations are not GitHub screenshots or proof of a tested policy. For each case, the decision tree should check the actual workflow event and commit before it decides what operations are permitted. Do not let a fallback branch accidentally match the production path when a variable is absent or unexpected.
Separate code testing from site credentials
A secure pipeline can put release credentials behind a protected environment and restrict production permissions to a dedicated job. The tag-type check can route a candidate toward that approval boundary, but the environment and repository permissions must enforce the real restriction. Preview jobs should not receive publishing tokens, especially on untrusted pull requests. Build artifacts should be verified against their content hashes and reviewed source revision before reuse. If a caption linter needs to read untrusted content, treat that content as data and avoid executing embedded paths or commands. The type of the triggering ref does not neutralize malicious build inputs.
Record why a release was permitted
When the museum publishes a new caption package, keep a compact audit record containing repository, ref type, ref name, event name, commit SHA, workflow revision and approval reference. Store the reviewed caption version and output artifact checksum separately. That record helps explain why a tag-triggered release occurred and which source was actually deployed. If the ref type was branch, the audit should normally show preview-only behavior rather than publication. A release dashboard should not label every tag run approved merely because the variable says tag; its label should reflect a verified approval decision.
Test the wrong-path cases deliberately
Use isolated workflow fixtures to check branch pushes, annotated or lightweight tag triggers where relevant, manual dispatches and unexpected event configurations. Confirm that branch jobs cannot access production secrets and that a tag without editorial approval cannot publish. Also test what the workflow does when a required context value is absent, since defensive conditions should fail closed. Compare expected job permissions and actual artifacts from each synthetic case. Do not claim that a string comparison enforces all of GitHub’s permission and trust boundaries. Review the workflow YAML and organization rulesets before launching a production release.
Research scope and final safeguards
We consulted the current official GitHub Actions variables, events and workflow-syntax references for the meanings of ref type, ref name and triggering event. The discussion uses hypothetical museum deployments; no repository was modified, no workflow was run and no public content was published. Illustrations depict decision paths rather than real settings. GitHub features and organization policies may vary, so confirm the deployed runner environment, supported triggers, protected environments and the checked-out SHA. Keep the final release decision behind authenticated approval and least-privilege permissions. GITHUB_REF_TYPE is a useful descriptive signal, not a certificate of source integrity or editorial permission.
How We Research
Our November 11, 2026 editorial review consulted these named primary references: GitHub Actions variables reference; GitHub Actions events reference; GitHub Actions workflow syntax. We compared the field definitions, scope, constraints, failure cases and feature-specific caveats against a hypothetical museum operations workflow. We did not access private accounts, send production API requests, record actual user information, measure benchmark outcomes, inspect a live WordPress instance, or present the drawings as real vendor screenshots. Illustrations show synthetic educational scenarios. Product settings, documentation and account entitlements may change; verify the current reference and obtain operational or privacy approval before applying any change.
Frequently Asked Questions
The official GitHub Actions variables reference lists branch and tag.
No. It indicates ref type, not identity, commit integrity or editorial permission.
A preview or test job should not receive production credentials merely because it completed successfully.
Review event name, ref name, commit SHA, workflow revision, repository and the project’s approval record.
A well-designed workflow should fail closed if event, ref or approval context is not the expected release condition.