Zašto su generisani Make targeti kanonski?¶
TL;DR
Makefile.generated.mk se regeneriše iz services.json kroz
ci/json/services_to_makefile.py. Generiše <svc>-<verb> +
globalne helper targete. Ručno python3 ci/run.py ... u yml-u
je workaround, ne canonical. Generisani target poznaje ENV
derivation, env-parametric shape, --wait/NO_WAIT toggle, i
Make-var passthrough — sve što ručni poziv mora ponovo da otkrije.
Generisani targeti (canonical)¶
Za svaki servis u services.json:
| Target | Verb | ENV |
|---|---|---|
<svc>-bump |
ci/run.py bump <svc> --env $(ENV) |
zahtijeva ENV |
<svc>-seed |
ci/run.py seed <svc> --env $(ENV) |
zahtijeva ENV |
<svc>-build |
ci/run.py build <svc> --env $(ENV) --push |
zahtijeva ENV |
<svc>-scan |
ci/run.py scan <svc> --env $(ENV) |
zahtijeva ENV |
<svc>-deploy |
ci/run.py deploy <svc> --env $(ENV) --wait |
zahtijeva ENV |
<svc>-notify |
ci/run.py notify <svc> --env $(ENV) |
zahtijeva ENV |
<svc>-release-<env> |
chain (build → deploy → notify) | zahtijeva release.enabled |
Plus globalni:
bump,build,scan,deploy,notify(state-driven default)tag,trigger-pipeline,ci-checkout-releaseci-state-merge,ci-docker-login,ci-pint-lint,ci-phpstan,ci-ruff,ci-bandit-scan,ci-hadolint,ci-shellcheck, ...
Zašto ENV derivation¶
# ENV se automatski izvodi:
ENV ?= $(shell python3 -c '... logical_env_from_label ...' 2>/dev/null)
# U Bitbucket deployment step-u sa `deployment: api-production`:
make api-deploy # ENV=production automatski
# NE: make api-deploy ENV=production
# U flat build step-u sa SENTRY_RELEASE_ENV=staging:
make api-build # ENV=staging automatski
Generisani target to radi za tebe. Ručni ci/run.py poziv zahtijeva
--env production eksplicitno — lako se zaboravi.
YML HARD RULES (load-bearing)¶
# NE: ručni python3 u yml-u (čak ni u ci-artifacts vlastitom pipeline-u!)
- step:
script:
- python3 ci/run.py bump api --env production
# DA: generisani target
- step:
script:
- make api-bump ENV=production
# ILI: state-driven default (ENV se izvodi automatski)
- step:
script:
- make api-bump
Svaki ručni python3 ci/run.py u bitbucket-pipelines.yml je
signal da ili (a) target ne postoji, ili (b) trebaš novi generisani
target.
Repo-specific wrapper-i (gdje su OK)¶
Consumer repo može imati vlastite ci-* wrapper targete u svom
Makefile-u, ALI samo za:
- Bitbucket fan-out (parallel-step coordination)
- Output-variable export
- Artifact filename shims
- Consumer-specific test harnesses
NE za redoslijed build/deploy/notify — to je već u generisanim targetima.
Regeneracija¶
# Ručno:
make gen
# → "✓ Regenerated Makefile.generated.mk"
# Auto-regen prereq (NE treba ručno):
# Makefile.generated.mk: services.json $(GEN_SCRIPT)
# @python3 $(GEN_SCRIPT) --output $@
# Kada se services.json promijeni, `make <generated-target>` auto-rege.
Nikad ne edituj Makefile.generated.mk ručno — sledeći make
gen briše tvoje izmjene.
Vidi i¶
v7.md§2 — "Gdje da promijenim" (Make targeti)02-systems/10-consumer-make.md— consumer.mk + Makefile.generated.mk deep-diveci/make/CLAUDE.md— Make contractci/json/services_to_makefile.py— generatorci/CLAUDE.md(root) — "YML HARD RULES" + "Consumer Make contract"