fix(analytics): pass the Clarity project id into the image build

[Elias-3817]

Pass the Clarity project id into the image build

Microsoft Clarity was added to the frontend in #11, but the image build
never received the project id. Next.js replaces every NEXT_PUBLIC_*
expression with a literal string during next build, so the compiled
bundle carries whatever the value was at build time. With nothing passed,
the component's guard renders nothing and no sessions are recorded.

This is invisible from the outside. The build succeeds, the image ships,
the pod runs, and the dashboard stays empty with no error anywhere.

The workflow now passes the id as a build arg and the Dockerfile declares
it before the build step. The id is hardcoded rather than read from a
repository variable because it is already public in the page source of
every instrumented site, and this workflow only ever runs in this
repository.

[qodo-code-review]

PR Summary by Qodo

fix(analytics): pass Clarity project id during Docker image build

🐞 Bug fix ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Pass NEXT_PUBLIC_CLARITY_PROJECT_ID as a Docker build argument from GitHub Actions
• Declare the Clarity build arg/env in Dockerfile.dev so Next.js can inline it at build time
• Fix missing analytics configuration caused by building without NEXT_PUBLIC_* values

Diagram

graph TD
  A["GitHub Actions: build-and-push"] --> B["Docker buildx build"] --> C["Dockerfile.dev"] --> D["Next.js build"] --> E{{"Microsoft Clarity"}}

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Store project id in GitHub Actions secret/variable (not hardcoded)

• ➕ Avoids embedding a specific project id directly in the workflow YAML
• ➕ Easier to change per environment (staging/prod) without code changes
• ➖ Requires secret/variable management and documentation for deploys

2. Use runtime env injection instead of build-time arg

• ➕ Allows changing project id without rebuilding the image
• ➖ Does not work for typical Next.js usage when the value must be inlined via NEXT_PUBLIC_* at build time unless you adopt a runtime config strategy (e.g., server-injected config endpoint)

Recommendation: Keep the build-arg approach (it matches Next.js NEXT_PUBLIC_* inlining requirements), but prefer sourcing NEXT_PUBLIC_CLARITY_PROJECT_ID from a GitHub Actions variable/secret or environment-specific configuration rather than hardcoding it in the workflow file.

Files changed (2) +3 / -0

Other (2) +3 / -0

build-and-push-dockerhub.ymlPass Clarity project id as Docker build-arg +1/-0

Pass Clarity project id as Docker build-arg

• Adds NEXT_PUBLIC_CLARITY_PROJECT_ID to the Docker build arguments in the Docker Hub build-and-push workflow so the value is available during image compilation.

.github/workflows/build-and-push-dockerhub.yml

Dockerfile.devExpose NEXT_PUBLIC_CLARITY_PROJECT_ID during build +2/-0

Expose NEXT_PUBLIC_CLARITY_PROJECT_ID during build

• Declares NEXT_PUBLIC_CLARITY_PROJECT_ID as a build ARG and exports it as an ENV var so Next.js can inline the value during the build.

Dockerfile.dev

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📜 Skill insights (0)

1. Hardcoded Clarity project id 🐞 Bug ⚙ Maintainability

Description

The Docker Hub build workflow hardcodes NEXT_PUBLIC_CLARITY_PROJECT_ID, so images built from
main/staging/dev all embed the same Clarity project id and it can’t be environment-specific (or
disabled) via normal build configuration. This can mix analytics between environments and forces
updates to go through workflow edits instead of environment variables.

Code

.github/workflows/build-and-push-dockerhub.yml[77]

+            NEXT_PUBLIC_CLARITY_PROJECT_ID=jvv0pvzi3x

Evidence

The workflow is triggered on multiple branches but passes a fixed Clarity id, while the repo
documents that Clarity is optional and must be set at build time (implying it should be configurable
per environment).

.github/workflows/build-and-push-dockerhub.yml[5-10]
.github/workflows/build-and-push-dockerhub.yml[66-78]
.env.example[100-103]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The workflow bakes a fixed `NEXT_PUBLIC_CLARITY_PROJECT_ID` into every built image regardless of branch/environment.

### Issue Context
The workflow runs on `main`, `staging`, and `dev`, but always sets the same Clarity project id. The repo’s `.env.example` indicates this value is optional and intended to be set at build time.

### Fix Focus Areas
- .github/workflows/build-and-push-dockerhub.yml[3-10]
- .github/workflows/build-and-push-dockerhub.yml[66-78]
- .env.example[100-103]

### Suggested fix
- Replace the hardcoded value with a GitHub Actions variable/secret (e.g., `${{ vars.NEXT_PUBLIC_CLARITY_PROJECT_ID }}`), and optionally use environment/branch-specific vars (prod vs dev/staging) or omit the arg on non-prod branches to keep Clarity disabled where desired.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Divergent Clarity build config 🐞 Bug ≡ Correctness

Description

Only the Docker Hub workflow passes NEXT_PUBLIC_CLARITY_PROJECT_ID; the GHCR tag build workflow
builds the same Dockerfile.dev without it, which disables Clarity at build time for those images.
This makes analytics behavior depend on which workflow/registry produced the image, complicating
debugging and deployments.

Code

.github/workflows/build-and-push-dockerhub.yml[77]

+            NEXT_PUBLIC_CLARITY_PROJECT_ID=jvv0pvzi3x

Evidence

Docker Hub builds now set the Clarity id at build time, while GHCR tag builds do not; since the
frontend code returns null when the env is missing, this directly causes enabled vs disabled Clarity
depending on build pipeline.

.github/workflows/build-and-push-dockerhub.yml[66-78]
.github/workflows/build-containers.yml[49-61]
Dockerfile.dev[1-6]
apps/frontend/src/components/layout/clarity.component.tsx[5-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Container images built via different workflows (Docker Hub vs GHCR tag builds) will have different `NEXT_PUBLIC_CLARITY_PROJECT_ID` values, because only one workflow supplies the new build arg.

### Issue Context
- `Dockerfile.dev` now supports `NEXT_PUBLIC_CLARITY_PROJECT_ID` and exports it into the build environment.
- The frontend Clarity component disables itself when the env var is missing.
- The GHCR tag build workflow does not pass this build arg, so Clarity will be disabled there while enabled in Docker Hub builds.

### Fix Focus Areas
- .github/workflows/build-and-push-dockerhub.yml[66-78]
- .github/workflows/build-containers.yml[49-61]
- Dockerfile.dev[1-6]
- apps/frontend/src/components/layout/clarity.component.tsx[5-17]

### Suggested fix
- Add `NEXT_PUBLIC_CLARITY_PROJECT_ID` to the GHCR build command in `.github/workflows/build-containers.yml` (preferably sourced from `${{ vars.* }}` or `${{ secrets.* }}`), or intentionally omit it in both workflows if Clarity should remain disabled for those images.
- If different environments should use different Clarity projects, apply the same branch/environment mapping logic across both workflows.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}