fix(service-ci): run it-postgres in parallel with build instead of serially

[aniham]

Summary

Cuts ~6-7min off PR CI wall-clock time by running it-postgres in parallel with build instead of after it. Measured on spacecat-api-service: build (lint + unit tests + bundle smoke check) ~6m13s, it-postgres (Docker Postgres integration tests) ~6m36s — sequential today, so every PR pays ~13min. Removing the artificial ordering means paying max(6m13s, 6m36s) ≈ 6.5min instead, roughly halving PR CI time for every service on this reusable workflow with it-postgres: true.

• it-postgres had needs: build, but the job does its own checkout, ECR login, and npm ci — it doesn't consume anything from build's output. The dependency was pure sequencing, not a real one.
• Removed needs: build so it-postgres runs concurrently with build instead of after it.
• Downstream jobs (semantic-release, deploy-stage, branch-deploy) keep needs: [build, it-postgres] and still wait for both — unaffected.

Trade-off

needs: build wasn't purely cosmetic ordering — it also gated it-postgres behind build succeeding, so a PR whose build job failed never paid for it-postgres (ECR login + AWS creds + spinning up a Postgres container + ~6-7min of integration tests). That gate wasn't fast, though: npm run lint fails in ~30s, but a failing unit test doesn't surface until the full ~5min parallel mocha run finishes (mocha doesn't bail on first failure by default), so build itself typically takes most of its ~6min to report a failure. The gate saved wasted it-postgres compute on builds that were already going to fail — it didn't make failures fast.

After this change, it-postgres starts unconditionally in parallel with build, so every PR — including ones where build ultimately fails — now pays the full it-postgres compute cost too, across every consumer of this reusable workflow.

This is an intentional trade: faster wall-clock feedback on the (common) passing path, in exchange for higher CI compute/AWS-call cost on the failing path. No change to who can trigger it-postgres or what credentials it uses — only its timing relative to build moved.

Test plan

• YAML validated locally (yaml.safe_load), confirmed it-postgres.needs is now unset and all other jobs unchanged.
• Verify on a downstream consumer PR (e.g. spacecat-api-service pinned to @v3) that build and it-postgres start at the same time and total CI time drops as expected.
• Confirm semantic-release/deploy-stage/branch-deploy still correctly wait for both build and it-postgres to succeed before deploying (no regression on fail-fast behavior for deploys).

[aniham]

Note on rollout: this repo has no automated semantic-release — versions are cut manually, and main is already at v3.1.2 (floating tag v3). Consumers pinned to @v2 (e.g. spacecat-api-service) are on a frozen tag and won't pick up this fix from a v2 release; they'd need to bump their pin to @v3 (the diff between v2 and v3 is just the additive, default-off mac-giver-caller input, so that bump is safe on its own).

Opened adobe/spacecat-api-service#2865 as a draft companion PR bumping that pin — it's blocked on this PR merging and a new mysticat-ci release moving the v3 tag before it's actually load-bearing.

[MysticatBot]

Hey @aniham,

⚠ Degraded review - no spec document was found for this change (searched the PR links, the touched repos' docs, the architecture/guidelines docs, and linked Jira). This review covers code-level quality but could not validate the change against an agreed design, so confidence is reduced. Add a spec link (PR template section 4) and re-request review for a full-confidence pass.

Verdict: Approve - clean, well-scoped CI optimization with no blocking concerns.
Complexity: TRIVIAL - 5-line change to a single workflow file.
Changes: Removes needs: build from the it-postgres job so it runs in parallel with build, halving CI wall-clock time (1 file).

Non-blocking (2): minor issues and suggestions

• nit: The it-postgres input description (line ~29) still says "after build" but it now runs in parallel - consider updating to "in parallel with build" - .github/workflows/service-ci.yaml:29
• nit: The 4-line comment (lines 194-197) could be a one-liner since timing estimates will drift as jobs evolve - .github/workflows/service-ci.yaml:195

---

_{Skill: pr-review | Model: us.anthropic.claude-opus-4-6-v1[1m] | Duration: 1m 30s | Cost: $2.71 | Commit: 47228870f0f8074c6ad46a73dd77b8869640fc21
If this code review was useful, please react with 👍. Otherwise, react with 👎.}