Repository navigation
Conversation
… init default Projects upgraded by nself update that still have HASURA_VERSION=v2.44.0 in .env were downgraded to hasura-v14 because the old init default matched hasura-v14.IsDefaultVersion and switched the entry away from the v2.51.0 pin. Treat v2.44.0 as non-explicit when the project pin is hasura (v2.51.0) so the newer pin wins without requiring users to clear stale .env values. Also fix the composePrefixRE doc comment placement in logs_json.go and document the migration in Image-Lock.md and Config-Hasura.md.
|
Fixed all three review findings in 00b064f:
All |
…out env mutation Remove the staleInitDefault migration branch that treated v2.44.0 as non-explicit when a v2.51.0 pin existed. Every nonblank HASURA_VERSION is now explicit and overrides a project pin, including v2.44.0 written by service upgrade hasura v2.44.0. Pass the version to projectPin explicitly via projectPinWithVersion instead of mutating the process environment with os.Unsetenv/os.Setenv. Update docs and tests to reflect the new behavior.
|
Fixed review findings in 3b172de:
All compose and commands tests pass. |
Fix three local debt rows verified against origin/main at 86627b8. Leave the image-mirror publishing row blocked by the explicit publishing/settings restrictions.
Per row
json: legacyfor the v1.4 logs registry/help view while retaining the existing v1.5-only envelope registration. Accept dotted schema names and generatelogs.record.v1.schema.json(and the shared admin logs record name). Filter v1.5 JSON logs against text without the compose service prefix, retain the prefix for service extraction, and trim only timestamp/prefix delimiters so message indentation and trailing spaces survive. Add argv assertions for both modes and follow settings, populated v1.4 follow byte identity, over-4-MiB terminal errors, indentation, schema-path, and prefix-filter regressions. Exclude flags overriding JSON to none/legacy from machine parameters; regenerate OpenAPI, facts, and MCP goldens. This also removes doctor’s legacy-only flags from machine schemas. Rationale: retain the established v1.4 contract (ADR 0021 compatibility model), and only advertise machine invocations that can return their promised envelope.HASURA_VERSIONblank, config preserves blank, and every nonblank selection is explicit. Known versions select their corresponding image-lock entry; blank follows the mode default/project pin.service upgrade hasura v2.44.0can now override a newer pin. Update docs, the config-list fixture, and init/render/lock tests. Rationale: an explicit version must take effect; blank is the unambiguous default. Existing env files containing v2.44.0 now select that version explicitly; clear it to follow the default/pin. Reused the existing unmerged c484098 fix after confirming its branch has no open PR.${MINIO_ROOT_USER}/${MINIO_ROOT_PASSWORD}at the source. Secret templating preserves explicit credential references instead of rebinding them by destination key to application S3 credentials. Add a generate-and-template regression with distinct credential pairs, plugin-path assertions, and refresh the compose fixture. Rationale: existing generator behavior and tests select root credentials; preserve that behavior and allow custom-service env overrides rather than silently changing identity..github/workflows/image-pin-bump.ymlgates apply onIMAGE_MIRROR_APPLY. Existing PR chore(images): weekly image pin bump #969 reports auth/auth-v14/valkey copies still needed, and explicitly says it pushes nothing. Completion requires enabling the repository variable and an authenticated public Docker Hub push (mirror-images.sh --apply), followed by live verification. Those actions are explicitly out of scope; no settings, registry writes, image/version bumps, or production verification performed.Verification
${S3_ACCESS_KEY}/${S3_SECRET_KEY}and passes after with MinIO root refs. New init test fails with main’s old init template; explicit Hasura downgrade/render coverage passes after in both compatibility and pinning modes.go test -mod=vendor ./cmd/commands ./internal/build ./internal/compose ./internal/config ./internal/setup ./internal/invoke ./internal/canon ./internal/mcpgen ./tools/schemagen(with workerNO_COLORunset): all packages passed across the runs. The final run passed commands (235.6s), compose, config, setup, invoke, canon, MCP, and schemagen; internal/build could not link because a shared Go cache file disappeared. internal/build passed its earlier whole-package run (10.1s), the v1.5 whole-package rerun (12.1s), and the credential regression. The same missing-cache-file failure also occurred while testing a clean origin/main archive; no cache workaround appliedNSELF_V15=1 env -u NO_COLOR go test -mod=vendor ./internal/build ./internal/compose ./internal/config: PASS. Full v1.5 setup/invoke/canon/schemagen tests also PASS. Relevant logs/Hasura tests exercise both modes.go vet -mod=vendorfor the eight production packages/tools touched: PASS.CGO_ENABLED=0 go build -mod=vendor -o <scratch>/nself ./cmd/nself: PASS.make canon schemas cmd-inventory,make schemas-check: PASS (317 schemas current).go test -mod=vendor ./internal/repoqa -run 'TestSchemasAreCurrent|TestOpenAPI|TestCommandCanonPageIsCurrent' -count=1: PASS. MCP stdio/golden targeted recheck: PASS. Touched-file gofmt andgit diff --check: PASS.NO_COLORand failed three remote-config isolation tests. Those exact failures reproduce on clean origin/main. Unsetting only that worker variable makes the full affected-package rerun pass. The initial broader run also identified the expected compose and MCP golden changes; fixtures were regenerated and checked.