slim and single are projections of the Kubernetes tiers of the same name, and make check-profiles is what stops the two drifting. It has never actually gated one, and the projection is stale right now.
Two halves to it.
The check is skipped on every run
profile-projection in .github/workflows/ci.yml:134 is gated on profile-projection-precondition, which only says yes when the repo has a DFE_INFRA_TOKEN secret with read on hyperi-io/dfe-infra.- that secret does not exist, so the job reports
skipped, not failure. Checked the last three runs on main -- 34733992141, 34732169077, 34581681437 -- Profile projection: skipped on all three.
- the precondition job itself passes, so the run is green and the summary looks complete. The
::notice:: it prints is honest, and nobody reads notices on a green run.
make check-profiles with DFE_INFRA_DIR unset prints "projection NOT checked (not a pass)" and exits 0, which is the right local behaviour and the wrong CI behaviour.
The projection is stale
Run by hand, dfe-docker main (c748877) against dfe-infra main (96a44cbb):
render_profiles: service_profiles.yaml is STALE against the Kubernetes profiles -- run `make render-profiles`
--- committed
+++ rendered
@@ -32,6 +32,8 @@
config_path: loader/kafka.yaml
dfe-receiver:
config_path: receiver/kafka.yaml
+ dfe-transform-elastic:
+ config_path: transform-elastic/kafka.yaml
dfe-transform-vrl:
config_path: transform-vrl/kafka.yaml
dfe-infra's tier carries dfe-transform-elastic and the compose projection does not. That is the ONE difference the check reports today -- I could not reproduce drift in the other direction, so treat "both ways" as unproven.
What to do about the token is the real question
- a
DFE_INFRA_TOKEN is one more credential to mint and rotate for a check that reads one public-in-future repo
- the alternative is projecting from something dfe-docker already has -- a pinned copy of the profile input, refreshed by the same pin cycle that moves the app versions -- so the check runs on every PR with no secret at all
- leaving it as is means the target exists, the job exists, and neither has ever said no
Done when the projection check runs on an ordinary PR with no operator setup and fails a stale service_profiles.yaml.
slimandsingleare projections of the Kubernetes tiers of the same name, andmake check-profilesis what stops the two drifting. It has never actually gated one, and the projection is stale right now.Two halves to it.
The check is skipped on every run
profile-projectionin.github/workflows/ci.yml:134is gated onprofile-projection-precondition, which only says yes when the repo has aDFE_INFRA_TOKENsecret with read on hyperi-io/dfe-infra.skipped, notfailure. Checked the last three runs on main -- 34733992141, 34732169077, 34581681437 --Profile projection: skippedon all three.::notice::it prints is honest, and nobody reads notices on a green run.make check-profileswithDFE_INFRA_DIRunset prints "projection NOT checked (not a pass)" and exits 0, which is the right local behaviour and the wrong CI behaviour.The projection is stale
Run by hand, dfe-docker main (c748877) against dfe-infra main (96a44cbb):
dfe-infra's tier carries dfe-transform-elastic and the compose projection does not. That is the ONE difference the check reports today -- I could not reproduce drift in the other direction, so treat "both ways" as unproven.
What to do about the token is the real question
DFE_INFRA_TOKENis one more credential to mint and rotate for a check that reads one public-in-future repoDone when the projection check runs on an ordinary PR with no operator setup and fails a stale
service_profiles.yaml.