chore: Automated releases & bake SB version into code #680
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughThe change migrates version management from runtime environment variables (NEXT_PUBLIC_SOURCEBOT_VERSION) to a build-time-generated TypeScript constant (SOURCEBOT_VERSION). The release workflow now generates a version.ts file during release, exported across backend and frontend. Docker build args shift from the web version to Sentry release identifiers. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This comment has been minimized.
This comment has been minimized.
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
.github/workflows/ghcr-publish.yml (1)
77-86: Consider adding SENTRY_RELEASE build argument.The Dockerfile now expects a
SENTRY_RELEASEbuild argument (as seen in the _gcp-deploy.yml workflow), but this workflow doesn't pass it. This means GHCR-published images won't have Sentry release tracking, while GCP deployments will.🔎 Apply this diff to add SENTRY_RELEASE build argument:
- name: Build Docker image id: build uses: docker/build-push-action@v6 with: context: . labels: ${{ steps.meta.outputs.labels }} + build-args: | + SENTRY_RELEASE=${{ inputs.version || github.ref_name }} cache-from: type=gha,scope=${{ env.PLATFORM_PAIR }} cache-to: type=gha,mode=max,scope=${{ env.PLATFORM_PAIR }} platforms: ${{ matrix.platform }} outputs: type=image,name=${{ env.REGISTRY_IMAGE }},push-by-digest=true,name-canonical=true,push=true,annotation.org.opencontainers.image.description=Blazingly fast code searchentrypoint.sh (1)
74-74: POSIX sh compatibility: echo -e is non-standard.The
echo -eflag is not POSIX-compliant and may not work in all sh implementations. Since the shebang specifies#!/bin/sh, consider usingprintfinstead for better portability.🔎 Apply this diff for POSIX compliance:
-echo -e "\e[34m[Info] Sourcebot version: $SOURCEBOT_VERSION\e[0m" +printf "\e[34m[Info] Sourcebot version: %s\e[0m\n" "$SOURCEBOT_VERSION" # (and for line 179) - echo -e "\e[34m[Info] Upgraded from version $PREVIOUS_VERSION to $SOURCEBOT_VERSION\e[0m" + printf "\e[34m[Info] Upgraded from version %s to %s\e[0m\n" "$PREVIOUS_VERSION" "$SOURCEBOT_VERSION"Based on learnings, Note: Many other
echo -estatements exist throughout this file (lines 15, 17, etc.), so this is a broader pattern. You may want to address all instances in a separate refactor.Also applies to: 179-179
packages/web/src/app/api/(server)/version/route.ts (1)
4-9: Update comment and reconsider caching strategy.The comment (lines 4-8) is now outdated. It refers to
SOURCEBOT_VERSIONas an environment variable, but it's now a TypeScript constant imported at build time.Since
SOURCEBOT_VERSIONis a build-time constant (not runtime), the route could theoretically be cached. However:
- If you regenerate version.ts and rebuild, the constant will update correctly
- Keeping
force-dynamicmight be safer to prevent any edge cases🔎 Update the comment to reflect the new approach:
-// Note: In Next.JS 14, GET methods with no params are cached by default at build time. -// This creates issues since environment variables (like SOURCEBOT_VERSION) are -// not available until runtime. To work around this, we fore the route to be -// dynamic and evaluate on each request. -// @see: https://nextjs.org/docs/14/app/building-your-application/routing/route-handlers#caching +// Note: SOURCEBOT_VERSION is now a build-time constant imported from @sourcebot/shared. +// We keep force-dynamic to ensure this endpoint always returns the current build's version, +// though caching would technically work since the constant is baked in at build time. export const dynamic = "force-dynamic";Also note the typo in line 6: "fore" should be "force".
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (17)
.env.development(0 hunks).github/workflows/_gcp-deploy.yml(1 hunks).github/workflows/ghcr-publish.yml(2 hunks).github/workflows/release-sourcebot.yml(3 hunks)Dockerfile(3 hunks)entrypoint.sh(5 hunks)packages/backend/src/instrument.ts(1 hunks)packages/backend/src/posthog.ts(2 hunks)packages/shared/src/env.client.ts(0 hunks)packages/shared/src/index.client.ts(1 hunks)packages/shared/src/index.server.ts(1 hunks)packages/shared/src/version.ts(1 hunks)packages/web/src/app/[domain]/components/settingsDropdown.tsx(2 hunks)packages/web/src/app/api/(server)/version/route.ts(2 hunks)packages/web/src/app/layout.tsx(2 hunks)packages/web/src/ee/features/audit/auditService.ts(1 hunks)packages/web/src/lib/posthog.ts(2 hunks)
💤 Files with no reviewable changes (2)
- packages/shared/src/env.client.ts
- .env.development
🧰 Additional context used
🧬 Code graph analysis (5)
packages/shared/src/version.ts (2)
packages/shared/src/index.client.ts (1)
SOURCEBOT_VERSION(6-6)packages/shared/src/index.server.ts (1)
SOURCEBOT_VERSION(51-51)
packages/web/src/app/api/(server)/version/route.ts (3)
packages/shared/src/index.client.ts (1)
SOURCEBOT_VERSION(6-6)packages/shared/src/index.server.ts (1)
SOURCEBOT_VERSION(51-51)packages/shared/src/version.ts (1)
SOURCEBOT_VERSION(2-2)
packages/backend/src/posthog.ts (3)
packages/shared/src/index.client.ts (1)
SOURCEBOT_VERSION(6-6)packages/shared/src/index.server.ts (1)
SOURCEBOT_VERSION(51-51)packages/shared/src/version.ts (1)
SOURCEBOT_VERSION(2-2)
packages/web/src/lib/posthog.ts (3)
packages/shared/src/index.client.ts (1)
SOURCEBOT_VERSION(6-6)packages/shared/src/index.server.ts (1)
SOURCEBOT_VERSION(51-51)packages/shared/src/version.ts (1)
SOURCEBOT_VERSION(2-2)
packages/web/src/app/[domain]/components/settingsDropdown.tsx (3)
packages/shared/src/index.client.ts (1)
SOURCEBOT_VERSION(6-6)packages/shared/src/index.server.ts (1)
SOURCEBOT_VERSION(51-51)packages/shared/src/version.ts (1)
SOURCEBOT_VERSION(2-2)
🪛 Shellcheck (0.11.0)
entrypoint.sh
[warning] 74-74: In POSIX sh, echo flags are undefined.
(SC3037)
[warning] 179-179: In POSIX sh, echo flags are undefined.
(SC3037)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (17)
.github/workflows/ghcr-publish.yml (2)
10-15: LGTM! Workflow reusability added.The
workflow_calltrigger with a configurableversioninput enables the release workflow to invoke this publish job with a specific version tag.
49-49: Checkout behavior correctly uses version input with fallback to branch/tag name.The version input format is already correctly matched between workflows. The release workflow passes
v${{ inputs.version }}to ghcr-publish, ensuring the tag format (e.g., "v4.10.5") aligns with the checkout action's expectations and the workflow's tag filter patternv*.*.*..github/workflows/_gcp-deploy.yml (1)
67-67: LGTM! Sentry release tracking updated.The build argument correctly switches from
NEXT_PUBLIC_SOURCEBOT_VERSIONtoSENTRY_RELEASE, usinggithub.ref_nameto track the deployed version in Sentry.entrypoint.sh (1)
167-167: LGTM! Telemetry and version tracking updated correctly.The entrypoint script correctly:
- Sends the new
SOURCEBOT_VERSIONin install events (line 167)- Sends upgrade events with from/to version tracking (line 188)
- Persists the version in the install tracking file (line 197)
Also applies to: 188-188, 197-197
Dockerfile (2)
72-73: LGTM! Sentry release tracking properly configured.The
SENTRY_RELEASEbuild argument is correctly added to both the web-builder and backend-builder stages, replacing the previousNEXT_PUBLIC_SOURCEBOT_VERSIONfor Sentry release tracking.Also applies to: 114-115
133-139: LGTM! Sourcemap upload updated for SENTRY_RELEASE.The conditional sourcemap upload correctly:
- Checks for
SENTRY_RELEASEinstead of the old version variable- Uses
$SENTRY_RELEASEin both inject and upload commands- Maintains proper conditional logic for OSS builds (only uploads if SENTRY_SMUAT is present)
packages/web/src/ee/features/audit/auditService.ts (1)
4-4: LGTM! Version tracking migrated to shared constant.The audit service correctly imports and uses
SOURCEBOT_VERSIONfrom@sourcebot/shared, replacing the previous environment variable approach. This ensures consistent version tracking across audit logs.Also applies to: 10-10
packages/web/src/app/api/(server)/version/route.ts (1)
1-1: LGTM! Version endpoint updated to use shared constant.The route correctly imports and returns
SOURCEBOT_VERSIONfrom@sourcebot/shared.Also applies to: 13-13
packages/shared/src/index.client.ts (1)
5-7: LGTM! Version constant exported for client-side usage.The export correctly exposes
SOURCEBOT_VERSIONfrom the version module, enabling client-side components to access the build version. The.jsextension follows TypeScript module resolution conventions.packages/shared/src/version.ts (1)
1-2: No action needed. The file is correctly managed by the release workflow.The release workflow (
release-sourcebot.yml) intentionally generates and commitsversion.tsas part of the release process. The current hardcoded version reflects the output of the last release execution. This is the correct approach—the file is updated automatically during releases and committed to track the released version in version control.Likely an incorrect or invalid review comment.
packages/backend/src/instrument.ts (1)
2-2: LGTM!Clean migration from environment variable to the centralized
SOURCEBOT_VERSIONconstant for Sentry release tracking. The import correctly pulls from@sourcebot/sharedwhich re-exports the version constant.Also applies to: 10-10
packages/shared/src/index.server.ts (1)
47-52: LGTM!The new export for
SOURCEBOT_VERSIONfollows the existing export pattern and correctly uses the.jsextension for ESM compatibility.packages/backend/src/posthog.ts (1)
1-1: LGTM!Clean consolidation of imports and consistent migration to
SOURCEBOT_VERSIONfor telemetry event properties.Also applies to: 26-26
packages/web/src/app/[domain]/components/settingsDropdown.tsx (1)
35-35: LGTM!The client component correctly imports
SOURCEBOT_VERSIONfrom@sourcebot/shared, which re-exports it via the client entry point. The version display in the settings dropdown is clean and consistent with the PR's migration goal.Also applies to: 170-170
packages/web/src/lib/posthog.ts (1)
2-2: LGTM!Consistent migration to
SOURCEBOT_VERSIONfor server-side PostHog event tracking, matching the pattern used in the backend posthog module.Also applies to: 100-100
packages/web/src/app/layout.tsx (1)
9-9: LGTM!Clean consolidation of imports and correct usage of
SOURCEBOT_VERSIONfor the PostHogProvider prop. The server component correctly resolves the import from@sourcebot/shared.Also applies to: 45-45
.github/workflows/release-sourcebot.yml (1)
96-104: LGTM!The publish job correctly:
- Depends on the release job completing first
- Passes the version with the
vprefix to match the tag format- Requests appropriate permissions for container registry publishing
This PR automates releases via the
release-sourcebot.ymlaction and bakes the Sourcebot version into code (as opposed to using a build argument).Many users of Sourcebot build their own images from the Dockerfile, resulting in the version build arg not being set. In PostHog, we just see version "unknown", which isn't very helpful.
Summary by CodeRabbit
Refactor
Chores
✏️ Tip: You can customize this high-level summary in your review settings.