Summary
The repository variable DEPLOY_BRANCH is set to copilot/add-github-actions-workflow, a branch that no longer exists. .github/workflows/deploy.yml gates its job on:
if: github.ref_name == (vars.DEPLOY_BRANCH || 'main') || workflow_dispatch
so every push to main evaluates that condition as false and the deploy job is skipped. The last five recorded runs of deploy.yml — including two on main — all show skipped.
Impact
No merge to main has ever deployed to the omcsi instance through this workflow. The workflow reports as present and green, which is why the gap is invisible from the Actions tab: a skipped job is not a failed one.
Why this is being filed rather than fixed
Correcting the variable to main would mean the next merge auto-deploys to the live server, carrying every undeployed change since the variable was set. That is a deployment decision, not a repository-hygiene one, and it belongs to whoever operates that server. The same defect was found and corrected in Dans-Plugins/Activity-Tracker (its issue #95), where flipping the variable did exactly that — so the consequence here is known rather than speculative.
Suggested resolution
Either:
- Set
DEPLOY_BRANCH to main after a controlled workflow_dispatch run has confirmed the deploy path still works against the current server, or
- Remove the variable entirely so the workflow falls back to its documented
'main' default, again after a manual dispatch.
Whichever is chosen, a follow-up worth considering is failing loudly when DEPLOY_BRANCH names a branch that does not exist, so a stale pin cannot masquerade as a healthy skip.
Found while verifying that merging #2016 into main could not trigger an unintended production deploy.
drafted by Claude on behalf of Daniel Stephenson
Summary
The repository variable
DEPLOY_BRANCHis set tocopilot/add-github-actions-workflow, a branch that no longer exists..github/workflows/deploy.ymlgates its job on:so every push to
mainevaluates that condition as false and the deploy job is skipped. The last five recorded runs ofdeploy.yml— including two onmain— all showskipped.Impact
No merge to
mainhas ever deployed to the omcsi instance through this workflow. The workflow reports as present and green, which is why the gap is invisible from the Actions tab: a skipped job is not a failed one.Why this is being filed rather than fixed
Correcting the variable to
mainwould mean the next merge auto-deploys to the live server, carrying every undeployed change since the variable was set. That is a deployment decision, not a repository-hygiene one, and it belongs to whoever operates that server. The same defect was found and corrected inDans-Plugins/Activity-Tracker(its issue #95), where flipping the variable did exactly that — so the consequence here is known rather than speculative.Suggested resolution
Either:
DEPLOY_BRANCHtomainafter a controlledworkflow_dispatchrun has confirmed the deploy path still works against the current server, or'main'default, again after a manual dispatch.Whichever is chosen, a follow-up worth considering is failing loudly when
DEPLOY_BRANCHnames a branch that does not exist, so a stale pin cannot masquerade as a healthy skip.Found while verifying that merging #2016 into
maincould not trigger an unintended production deploy.drafted by Claude on behalf of Daniel Stephenson