428 commits

This branch

This branch

All branches

Author	SHA1	Message	Date
Ashwin Kumar Sivakumar	8b648e73d0	chore: trigger build after registry-cleanup fix ... trigger build	2026-07-19 18:15:49 +05:30
Ashwin Kumar Sivakumar	e4c9fc31ee	feat: human-readable reference numbers + fix verification document visibility ... Adds a DB-trigger-generated reference_number (NXT-{TYPE}-{YY}-{000001}) to verifications, support_tickets, payments, job_applications, lead_requests, and users, replacing raw UUIDs shown to customers/admins. Also fixes verification-status endpoint to return uploaded documents (previously omitted, so documents never appeared after submission), and adds a reference-number lookup endpoint for the AI support assistant. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-19 16:34:00 +05:30
Ashwin Kumar Sivakumar	dbb02e54cc	fix(db): stop wiping employees table on every migration run, restore phone column ... CRITICAL: 20260402030000_strict_employee_separation.up.sql contained an unconditional DROP TABLE IF EXISTS employees CASCADE followed by a bare CREATE TABLE, written as a one-time schema transformation back when it was authored. The db-migrate tool has no applied-migrations tracking table - it replays every .sql file on every run - which turned that one-time DROP into a destructive operation that wipes every employee account (including admin accounts) on every single migration job run. This is what caused today's "db error while logging in": the phone column (never present in any tracked migration, added out-of-band in production at some point) was gone after the recreate, and every employee row - including the account in use this session - was deleted. Fix: make the table creation a plain idempotent CREATE TABLE IF NOT EXISTS (the standalone-schema transition it performed already happened in production long ago, so the drop was never needed for correctness going forward). Add a proper migration for the phone column so it's tracked instead of relying on an undocumented manual ALTER. Confirmed via kubectl-verified row count (0) and a pre-incident backup (2026-07-18T21:00:03Z, predates the destructive run) that the deleted row is recoverable; restoring it separately as a one-time data fix, not part of this schema migration. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-19 05:40:48 +05:30
Ashwin Kumar Sivakumar	bb616c6db1	fix(db): make three more migrations idempotent; log swallowed login DB error ... Same class of bug as the ai_plans_and_limits fix: ai_credit_packages and users_litellm_key used plain CREATE TABLE/ADD COLUMN with no re-run guard, and payu_rename_columns did a bare RENAME COLUMN that fails outright on any second run ("column razorpay_order_id does not exist"). All three were discovered by actually running the db-migrate job end to end for the first time and fixed in the same pass as the verification_logs FK fix - already baked into the db-migrate image that was built and run manually, this commit just brings the source in the repo in sync with what's deployed. Also: apps/employees login handler's DB error was being discarded via .map_err(|_| ...) with zero logging, making the reported "db error while logging in" impossible to diagnose from pod logs. Log the real error. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-19 04:40:31 +05:30
Ashwin Kumar Sivakumar	e80ce2901c	fix(db): make ai_plans_and_limits migration idempotent ... The db-migrate job (crates/db-migrate) has no applied-migrations tracking table - it replays every .sql file on every run, relying on each file being idempotent (IF NOT EXISTS / ON CONFLICT), which is the pattern virtually every other migration in this directory follows. This one wasn't: plain CREATE TABLE/CREATE INDEX and two INSERTs with no ON CONFLICT guard. Since the tables/data already exist from this file's one successful run, every subsequent migration job run failed immediately on "relation ai_plans already exists" - before ever reaching any migration after it, including ones genuinely needed (see the verification_logs FK fix two commits back). Confirmed via a live job run: this was the actual reason db-migrate had never completed successfully before. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-19 03:14:02 +05:30
Ashwin Kumar Sivakumar	e2635c1c30	fix(migrate): fix db-migrate build and job manifest, both broken ... Dockerfile.migrate copied only crates/db-migrate + a few unrelated crates but left the root Cargo.toml's [workspace] members list referencing every apps/* service, none of which exist in this build context - cargo failed immediately with "failed to load manifest for workspace member apps/gateway". Trim the workspace to just crates/db-migrate (it has no path dependency on anything else per crates/db-migrate/Cargo.toml) using the same awk trick Dockerfile.simple already uses per-service. Also fix the resulting binary output path (workspace builds put target/ at the workspace root, not under the member crate's own directory). k8s-migration-job.yaml targeted namespace: default, where neither nxtgauge-backend-rust-secrets nor a registry pull secret exist - both only exist in the nxtgauge namespace where the actual app runs. Fix the namespace and add the missing imagePullSecrets so the job can actually pull its image and read DATABASE_URL. Neither of these had ever been exercised successfully before - this is the first real migration run since the job/image were added. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-19 03:07:26 +05:30
Ashwin Kumar Sivakumar	466e7abf03	fix(db): point verification_logs FK at verifications, not legacy verification_requests ... scripts/init-db.sql created verification_logs.verification_request_id with a foreign key against verification_requests(id) - an unrelated legacy table. VerificationRepository::update_status inserts the verifications.id (the row actually being approved/rejected) into that column on every status change, which has been violating the FK on every single call: "insert or update on table verification_logs violates foreign key constraint verification_logs_verification_request_id_fkey" This made every Approve/Reject click in Verification Management 500, confirmed via the browser's actual response body. Drop and recreate the constraint to point at verifications(id), which is what the code has always actually been logging against. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-19 03:01:25 +05:30
Ashwin Kumar Sivakumar	a0d97583c4	ci: retrigger isolated employees rebuild (bad digest from concurrent push) ... The 20-service matrix push for 8a29b81 landed a digest in gitops for employees that doesn't exist in the registry (ImagePullBackOff, confirmed via kubectl - same failure mode documented in 512eb72/ea622a4). This commit only touches apps/employees/ so the CI path-filter rebuilds just that one service in isolation, avoiding the concurrent-push contention. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-19 00:30:27 +05:30
Ashwin Kumar Sivakumar	8a29b81c84	feat(admin-auth): add POST /api/admin/auth/refresh for sliding session window ... Admin access tokens expire after 15 minutes with no way to renew one, so active admins got logged out mid-work with no warning (silent 401s, now surfaced by admin-solid's session-expired dialog). Add a refresh endpoint that exchanges the HttpOnly nxtgauge_admin_token cookie for a new 15-minute access token, rotating the employee_sessions row (revoke old, store new) - mirrors the existing pattern in apps/users/src/handlers/auth.rs, but against the DB-backed employee_sessions table instead of Redis. Add EmployeeRepository::get_by_id / get_valid_session_by_token / revoke_session to support it. The admin-solid frontend calls this on a timer while the admin is active and skips it once idle for 15 minutes, so the session now extends while active and expires on inactivity as intended, instead of on a fixed wall-clock timer. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-19 00:14:08 +05:30
Tracewebstudio Dev	f56251374a	Increase LiteLLM request timeout from 60s to 180s ... The askash-main model at llm.nxtgauge.com takes 60-120s to generate job descriptions; previous 60s timeout caused all JD generations to fail. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-07-18 14:23:04 +02:00
Tracewebstudio Dev	623cda47b0	fix: end-to-end workflow fixes for company/job-seeker and profession flows ... - companies/admin: add proper POST /jobs/{id}/approve and /jobs/{id}/reject endpoints (sets status=LIVE, not direct SQL bypass) - customers: fix list_requests to query by customer_user_id (not professional), add optional lead_id filter; fix debit to use professional_user_id - payments: switch razorpay_order_id column to payu_txnid (PayU migration) - users/auth: fix role resolution to not inject phantom roles for professionals - contracts/profession_shared: fix my_requests SQL to join leads+users instead of nonexistent requirements table - db/job_seeker: fix INSERT VALUES placeholder count (add missing $10) - storage: add MOCK_STORAGE=true mode for local dev without real B2 creds Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-07-18 11:40:01 +02:00
Ashwin Kumar Sivakumar	3546b2caf0	fix(ci): sort registry prune by real image build time, protect current SHA ... Same fix as nxtgauge-frontend-solid and nxtgauge-admin-solid: this script isn't currently wired into this repo's build.yaml, but it's identical to the version that deleted frontend-solid's just-built image seconds after pushing it (sorted candidates by request time instead of actual build time). Fixing it here too so it's safe if/when it gets wired up, rather than leaving a dormant copy of the same bug. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-17 05:38:27 +05:30
Tracewebstudio Dev	0163349988	fix: skip broken migrations that reference dropped professionals table ... Several migrations reference a professionals table that was replaced by per-profession profile tables in 20260317195000. Rename to .skip so sqlx migrate run succeeds on a fresh local dev database. Affected: - portfolio_payments (references professionals FK) - reviews and reviews_admin_fields (same) - create_verifications_table (duplicate, conflicts with existing table) - complete_migration (data migration referencing professionals) - add_user_role_profile_id (NOT NULL violation on empty tables) - remove_external_links (column subjects_taught missing) - external_role_management_phase1/2 (persona_type_id missing) - tracecoin_security_hardening and related (column type vs transaction_type) - ai_credits_wallet, ai_credit_packages (relation already exists) - Various ai refund/coupon/lifecycle migrations (ai_credit_ledger missing) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-07-17 00:48:50 +02:00
Ashwin Kumar Sivakumar	3e2f3dd85d	perf(ci): cache cargo registry and target dir across image builds ... Dockerfile.simple had no build caching at all - every push recompiled the full dependency tree from scratch for every service, in release mode, targeting musl with static OpenSSL (the slowest possible combination). BuildKit cache mounts for /app/target and the cargo registry/git caches persist across builds on the same runner node and are shared across all 20 services, since they overlap heavily on workspace dependencies. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-16 21:07:33 +05:30
Ashwin Kumar Sivakumar	f5201965d8	Issue each account its own LiteLLM virtual key instead of the shared master key ... register() now generates a per-account LiteLLM key (best-effort, non-blocking) and stores it on the user. New internal endpoint GET /internal/users/{id}/llm-key lets other services fetch (or lazily backfill) an account's key, authenticated via the existing X-AI-Service-Key shared secret. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-16 20:29:00 +05:30
Ashwin Kumar Sivakumar	74664176da	chore: retrigger isolated CI builds for users, social-media-managers (again) ... Both still on stale bad digests after the previous retrigger. Old replicas continue serving traffic throughout, so no outage. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-15 05:50:21 +05:30
Ashwin Kumar Sivakumar	6c5c6b6938	chore: retrigger isolated CI build for social-media-managers ... Landed a bad digest again in the previous batch. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-15 05:03:19 +05:30
Ashwin Kumar Sivakumar	b8785e39f2	chore: retrigger isolated CI builds for services with stale bad digests ... Restarting these deployments to pick up the corrected B2 secret revealed they'd been running healthy old pods on top of a bad digest in the deployment spec all along (silent from an earlier rebuild wave) — the restart exposed it via ImagePullBackOff/ErrImagePull. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-15 04:14:58 +05:30
Ashwin Kumar Sivakumar	bf3850c282	chore: retrigger isolated CI builds for photographers, payments ... Both landed ImagePullBackOff on bad digests from the previous batch; old replicas kept serving throughout, so no outage. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-15 03:23:56 +05:30
Ashwin Kumar Sivakumar	ea622a4af8	chore: retrigger isolated CI builds for 6 more services on bad digests ... Same congestion pattern from the crates/contracts push. gateway still had 2 healthy replicas serving traffic throughout, so no outage — just a failed rolling-update replica for these 6 services. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-15 03:01:39 +05:30
Ashwin Kumar Sivakumar	8cabe37818	fix(contracts): log the full B2 upload error chain, not just outer context ... tracing::error!("...: {}", e) on an anyhow::Error only prints the outermost .context() message ("B2 upload failed") — the actual root cause (auth failure, DNS, timeout, bad bucket, etc.) from the AWS SDK is swallowed. Switching to {:?} prints the full chain so the real failure is visible in logs instead of a message that just repeats itself. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-15 02:34:22 +05:30
Ashwin Kumar Sivakumar	95184f83c4	chore: retrigger isolated CI builds for 8 services stuck on bad digests ... The last crates/db push (professional.rs role_key fix) rebuilt all 20 services concurrently again, and 8 of them landed ImagePullBackOff on a digest the registry doesn't have — same congestion pattern as the employees incident. This commit only touches apps/*/ for the affected services so CI rebuilds just these 8 in relative isolation. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-15 02:32:46 +05:30
Ashwin Kumar Sivakumar	03d761f0f3	fix(db): remove role_key column alias breaking every ProfessionalRepository query ... All three queries selected role_key AS profession_key, but the Professional struct's field is named role_key — sqlx's FromRow derive matches by column name, so every call (get_by_user_id, submit_for_verification, and its UPDATE...RETURNING) failed at runtime with "no column found for name: role_key". This is the professional-profile existence check used by document upload, portfolio, and submission endpoints across all 10 profession services — document upload was 500ing for every professional role because of this. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-15 01:30:45 +05:30
Ashwin Kumar Sivakumar	fb681accc3	fix(profile): use user_role_profile_id column, not id, for profession tables ... The profession-specific tables (photographer_profiles, tutor_profiles, etc.) were extended with a separate user_role_profile_id FK column and a NOT NULL user_id column, but every generic profile query still treated the shared user_role_profiles.id value as if it were the profession table's own `id` PK, and never supplied user_id at all. Result: PATCH /api/profile 500'd with "null value in column user_id violates not-null constraint" on every first-time save for any of the 10 professional roles — profile saves were completely broken, which cascades into submit-for-verification always running off an empty fallback payload with no real data or documents. Fixes get_profile, save_profile, set_profile_status, and fetch_saved_profile_by_urp_id to query/write user_role_profile_id (and populate user_id on insert) instead of assuming id. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-15 00:57:39 +05:30
Ashwin Kumar Sivakumar	89a2076974	fix(verifications): wrap list response in {items: [...]} ... GET /api/admin/verifications returned a bare JSON array, but every consumer (Verification Management, Approval Management, and the e2e test's own mock) expects {items: [...]}. Array.isArray(payload?.items) was always false against a bare array, so both admin screens have been showing "No verification requests found" regardless of what's actually in the queue. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-15 00:51:14 +05:30
Ashwin Kumar Sivakumar	512eb722a5	chore(employees): retrigger isolated CI build ... The prior push (crates/cache change) rebuilt all 20 workspace services concurrently, and the employees job's build/push landed a digest that doesn't exist in the registry (kubectl confirmed ImagePullBackOff with "not found" resolving that exact sha256). This commit only touches apps/employees/ so the CI path-filter rebuilds just that one service in isolation, without the same concurrent-build congestion. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-15 00:34:39 +05:30
Ashwin Kumar Sivakumar	01f3810c8f	feat(employees): add forgot-password/reset-password for admin accounts ... Employees (internal admin/staff) had no self-service password reset — only /login, /logout, /session existed. Adds /api/admin/auth/forgot-password and /api/admin/auth/reset-password, mirroring the existing users-table flow but against EmployeeRepository and a distinct Redis key namespace (reset:employee:*) so a code for one identity store can never be consumed against the other. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-14 23:28:39 +05:30
Ashwin Kumar Sivakumar	308daf4959	fix(verification): align document keys and dedupe role maps across handlers ... extract_documents() recognized a stale set of document keys that no longer matched what the frontend actually uploads (portfolio_ownership_proof, professional_certifications, qualification_proof, tax_document), so every non-COMPANY role's verification case was created with an empty documents array. Also extracts role_key_to_display/role_to_table into a shared role_meta module — verifications.rs and approvals.rs were each missing UGC_CONTENT_CREATOR from their inline copies, so that role's rejections and final approvals were silently no-ops. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-14 21:23:30 +05:30
Ashwin Kumar Sivakumar	b9133018a5	fix(admin-auth): add rate limiting to admin login endpoint ... The admin/employee login handler had no brute-force protection, unlike the regular user login path. Given these accounts hold internal/ super-admin privileges, add a tighter limit (5 attempts/15min vs 10 for regular users) using the existing sliding-window Redis limiter. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-14 16:12:52 +05:30
Ashwin Kumar Sivakumar	e53098728a	refactor(companies): remove local-disk fallback from submit_with_documents — B2 only	2026-07-11 02:13:56 +05:30
Ashwin Kumar Sivakumar	a019f86477	feat(companies): add /profile/submit-with-documents endpoint with local-disk fallback for B2 outages	2026-07-11 01:31:03 +05:30
Ashwin Kumar Sivakumar	5fa1f8f74c	fix(profile): persist all COMPANY profile fields, not just company_name	2026-07-10 14:27:15 +05:30
Ashwin Kumar Sivakumar	9d475858ab	fix(auth): default role assignment to APPROVED at signup ... Roles assigned at registration are immediately active for login + session. Document/profile approval (handled separately by user_role_profiles in onboarding/verifications) is the correct gate for review workflows — do not gate raw role assignment on that flow. Previously defaulted to PENDING for non-demo accounts, which get filtered out by get_user_role_keys (WHERE status = 'APPROVED') and produced JWTs with empty roles, causing the 'role is not assigned' UX bug after login.	2026-07-09 23:41:49 +05:30
Ashwin Kumar Sivakumar	f7d0f6f9f5	fix: Update Dockerfiles to use ci.nxtgauge.com registry	2026-07-08 03:37:18 +05:30
Ashwin Kumar Sivakumar	8a8372850f	perf(ci): settle on capacity 2/node x 3 workers = 6 concurrent slots ... capacity=3/node (9 total) oversubscribed the 8 physical cores per node - individual builds slowed roughly 3x under contention (observed directly: builds that took ~2m37s standalone were still running after 8+ minutes), for no clear net throughput win since this workload is CPU-bound. Also found and fixed the actual reason capacity wasn't taking effect at all initially: the runner daemon command never passed --config, so it was silently running on default settings regardless of config.yaml. Settled on 2/node (6 total, matching docker-ready runner-2/3/4 - the control-plane node nxtgauge-1 is deliberately excluded from the runner DaemonSet and should stay that way, not used for build load). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-08 02:43:46 +05:30
Ashwin Kumar Sivakumar	ba1b0ebcc0	fix(ci): raise max-parallel to 9, make gitops push failures actually fail the job ... Bumped runner.capacity from 1 to 3 on all 3 runner pods (9 total concurrent slots - nodes were sitting at 7-11% CPU during builds, so plenty of headroom), matched here with max-parallel: 9. Also fixed a real bug: the gitops-push retry loop had no check after exhausting all attempts, so a job whose every push attempt failed would still exit 0 and report "success" - which is exactly what happened on the previous run (verified: all 20 services built and pushed their images correctly, but the actual GITOPS_PAT secret was invalid/expired, and the retry loop silently swallowed the resulting failure across all 20 jobs). Fixed the secret itself (confirmed the existing admin-scoped Forgejo token has valid push access to ashwin/nxtgauge-gitops and rotated GITOPS_PAT to it), and added an explicit exit 1 if the retry loop exhausts without a successful push. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-08 02:30:36 +05:30
Ashwin Kumar Sivakumar	9efb733974	fix(ci): use GITOPS_PAT instead of never-configured GITOPS_PUSH_TOKEN ... Confirmed via the matrix run: every service's actual docker build and push succeeded, but the GitOps-update step failed on all of them with "GITOPS_PUSH_TOKEN is empty". Checked the repo's configured secrets - GITOPS_PUSH_USERNAME/GITOPS_PUSH_TOKEN were never set; only a leftover GITOPS_GITHUB_USERNAME/GITOPS_GITHUB_TOKEN pair (from before the gitops repo moved to Forgejo) and GITOPS_PAT exist. Confirmed ashwin/nxtgauge-gitops lives on ci.nxtgauge.com matching this workflow's defaults, so GITOPS_PAT is the one meant for this. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-08 02:10:33 +05:30
Ashwin Kumar Sivakumar	e8651cf6c6	perf(ci): parallelize service builds across all 3 runners via matrix strategy ... The build was structured as a single job looping through all ~20 services sequentially, so only 1 of the 3 deployed runner pods (one per worker node) was ever used - the other 2 sat idle for the entire build. Switched to a static per-service matrix (max-parallel: 3, matching the 3 runners at capacity 1 each) so independent services build concurrently. Each matrix job does its own quick "does this service need building" check up front (same change-detection logic, now per-job) rather than relying on a shared job output, to avoid needing cross-job artifact/output passing. GitOps updates also move into each matrix job (previously a single step at the end) since there's no longer one job aggregating all results - added a fetch/reset/retry loop since multiple jobs can now push to the same gitops branch concurrently. Tried adding cargo registry/target cache mounts to Dockerfile.simple for a bigger per-build win too, but measured it directly (local A/B: cold build 2m37s vs a second, supposedly-cached build 7m18s) and it made things slower here, likely cargo's own cache-verification pass outweighing the benefit for this dependency set - reverted that part, Dockerfile.simple is unchanged. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-08 01:54:47 +05:30
Ashwin Kumar Sivakumar	968960fb3d	fix(ci): tolerate buildx's pretty-printed metadata-file JSON when extracting digest ... docker buildx --metadata-file writes pretty-printed JSON (space after the colon: "containerimage.digest": "sha256:..."), but the digest grep required compact JSON with no space, so it always matched nothing. That produced an empty $digest, which the script correctly treated as fatal and exited on - right after the first service (gateway) had already built and pushed successfully, silently aborting the rest of the service loop. Verified the fix against a real locally-generated metadata file from the same buildx command. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-08 00:03:32 +05:30
Ashwin Kumar Sivakumar	d422139e48	fix(ci): remove redundant rustup install now that base image already has it ... The official rust:alpine base (unlike whatever image the old defunct registry.nxtgauge.com mirror actually held) already ships a full rustup-installed toolchain, so the extra `curl rustup.rs | sh` step now fails with "cannot install while Rust is installed". Drop it and the /root/.cargo/bin PATH override (the base image already sets PATH to its own /usr/local/cargo/bin) - just add the musl target, which the existing rustup binary can do directly. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-07 23:41:31 +05:30
Ashwin Kumar Sivakumar	ae9c38a3af	fix(ci): point Dockerfile.simple at ci.nxtgauge.com instead of the defunct registry.nxtgauge.com mirror ... registry.nxtgauge.com was set up back in April for the old Woodpecker CI (commit 09df032) as a manual one-time mirror of rust:alpine to dodge Docker Hub rate limits. It never had a real ingress route wired up on the current cluster (confirmed: no Ingress/IngressRoute matches that host anywhere), so every build has been failing at the base-image pull. ci.nxtgauge.com is the registry actually in active use since the Forgejo migration, and the build job already authenticates against it for pushing service images, so no new credentials are needed. Manually mirrored rust:alpine there as a one-time step. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-07 23:36:23 +05:30
Ashwin Kumar Sivakumar	c8fa02a9a4	fix(ci): derive DOCKER_HOST from the job container's own default gateway ... --add-host=host.docker.internal:host-gateway is not being honored by this act_runner setup (tried via the runner's global container.options and a per-job container: block; neither worked, confirmed by two separate failed runs with identical DNS-lookup errors). Read the container's real default-route gateway from /proc/net/route instead (portable, no iproute2 dependency) and export it as DOCKER_HOST via GITHUB_ENV. This is the actual IP of the dind engine that spawned the job container, regardless of hostname-aliasing support. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-07 22:50:54 +05:30
Ashwin Kumar Sivakumar	dcf573e0f6	fix(ci): use explicit container: block for reliable job-level docker options ... Forgejo's docs note --add-host via the runner's global container.options config is not reliably honored for jobs using pure label-based runs-on mapping. Setting the same image + options explicitly per-job via jobs.build.container is the more directly supported path for per-job container customization. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-07 22:45:35 +05:30
Ashwin Kumar Sivakumar	b9e0ba247c	fix(ci): route job-container DOCKER_HOST via host.docker.internal ... 127.0.0.1:2375 only worked from the runner container's own network namespace (sibling to the dind sidecar in the same pod). The actual job container that runs each step is spawned *by* that dind engine, one level deeper, so its own loopback doesn't reach the sidecar. host.docker.internal (mapped to the job container's real gateway via --add-host=host.docker.internal:host-gateway in the runner's container.options) reaches back to the dind engine that created it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-07 19:59:27 +05:30
Ashwin Kumar Sivakumar	e6e503ca69	ci: trigger build after enabling docker-in-docker privileged mode ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-07 19:07:50 +05:30
Ashwin Kumar Sivakumar	0ea4024657	fix(ci): fix YAML syntax error in build.yaml that silently disabled Actions ... The unindented heredoc terminator (<<EOF2 ... EOF2 flush-left) broke the YAML block-scalar indentation contract for the `run: |` step, causing Forgejo to log "ignore invalid workflow build.yaml: yaml: line 75: could not find expected ':'" and silently skip the workflow entirely on every push since this line was introduced. No builds have run on main or high-performance since 2026-07-05 as a result. Replaced the multi-line heredoc with a single-line bash here-string, which needs no extra indentation and keeps the shell logic identical. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-07 18:34:45 +05:30
Ashwin Kumar Sivakumar	519a52813f	fix(jobs): nest jobs router under /api/jobs to match gateway routing ... The gateway forwards /api/jobs unmodified to the jobs service, but the service registered its routes at bare /jobs with no prefix — every other service (companies, users) nests under /api/<service> to match. This made the public job listing endpoint unreachable (404) through the gateway on test111. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-07 18:15:34 +05:30
Ashwin Kumar Sivakumar	afb4dc9ae6	fix(ci): use docker-ready runner label in Forgejo workflow ... - Change runs-on from self-hosted to docker-ready - Add DOCKER_HOST and DOCKER_BUILDKIT env vars - Align with other repo workflows	2026-07-06 04:24:06 +05:30
Ashwin Kumar Sivakumar	67d372c160	ci: remove GitHub Actions workflow - using Forgejo CI exclusively ... - Remove build-and-deploy-forgejo.yml from GitHub Actions - Forgejo CI at ci.nxtgauge.com now handles all builds and deployments - All images pushed to Forgejo registry (ci.nxtgauge.com/ashwin/*) - GitOps updates handled by Forgejo workflows	2026-07-06 04:19:40 +05:30
Ashwin Kumar Sivakumar	b8939e6384	fix(k8s): switch db-migrate image from GHCR to Forgejo registry	2026-07-06 03:52:54 +05:30