fix(drone-dep): revert _count_deploy=False — dep deploys must count for DG4.1
Some checks failed
continuous-integration/drone/push Build is failing
Some checks failed
continuous-integration/drone/push Build is failing
The DG4.1 formula in run_recipe_ci.py is: expected_deploy_count = 1 + deps_deployed_count So when gitea dep deploys, the expected count becomes 2 (1 recipe + 1 dep). The _count_deploy=False fix made dep deploys NOT count, giving actual=1 vs expected=2 → DG4.1 violation even though the run was correct. Original error "deploy-count 2 != 1" was because deps_state was empty when the DG4.1 check ran (provisioning had failed), giving expected=1 while count was already 2 from an early dep deploy. The proper fix is for _provision_deps to succeed (which it now does), not to suppress counting. Revert _count_deploy=False in deps.py; update docstrings for clarity. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
@ -16,6 +16,8 @@ Per Phase-2 DECISIONS:
|
||||
must share the single node's MAX_TESTS budget without exceeding it).
|
||||
- Each dep is undeployed in the orchestrator's `finally`, in **reverse** order so a recipe-under-
|
||||
test can depend on multiple deps with a dependency chain (a → b → c teardown is c → b → a).
|
||||
- Dep deploys DO count toward the DG4.1 deploy-count invariant. The formula in run_recipe_ci.py is
|
||||
`expected_deploy_count = 1 + deps_deployed_count`, so each dep deploy increments the counter.
|
||||
|
||||
Run state:
|
||||
- `$CCCI_DEPS_FILE` — JSON file written by the orchestrator after each dep deploys; each entry is
|
||||
@ -80,10 +82,9 @@ def deploy_deps(
|
||||
for dep in deps:
|
||||
domain = dep_domain(parent_recipe, pr, ref, dep)
|
||||
print(f" dep: deploying {dep} -> {domain}", flush=True)
|
||||
# Dep deploys do NOT count toward the DG4.1 "one deploy per run" invariant — that
|
||||
# contract covers the recipe-under-test only; each dep is a supporting service, not the
|
||||
# subject of the test. Pass _count_deploy=False so the main recipe's single-deploy
|
||||
# assertion isn't distorted by the number of deps declared.
|
||||
# Dep deploys count toward DG4.1 — the check expects (1 + len(cold-deps)), so each
|
||||
# dep that deploys here MUST be counted. The formula is authoritative in run_recipe_ci.py:
|
||||
# expected_deploy_count = 1 + deps_deployed_count
|
||||
dm = meta_for.get(dep) or meta_mod.load(dep)
|
||||
lifecycle.deploy_app(
|
||||
dep,
|
||||
@ -91,7 +92,6 @@ def deploy_deps(
|
||||
secrets=True,
|
||||
deploy_timeout=int(dm.DEPLOY_TIMEOUT),
|
||||
meta=dm,
|
||||
_count_deploy=False,
|
||||
)
|
||||
try:
|
||||
lifecycle.wait_healthy(
|
||||
|
||||
Reference in New Issue
Block a user