Skip to content

ci: build agentwatch-landing, and run the Docker build on pull requests(Closes #608) #621

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
SakethSumanBathini wants to merge 1 commit into from
Closed

ci: build agentwatch-landing, and run the Docker build on pull requests(Closes #608) #621

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 40 additions & 3 deletions .github/workflows/ci.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -139,12 +139,47 @@ jobs:
NEXT_TELEMETRY_DISABLED: 1
NEXT_PUBLIC_API_URL: /api/v1

# ─── Landing build ────────────────────────────────────────────────────────
# agentwatch-landing had no CI coverage at all: it is a full Next.js application with its own
# lockfile, and nothing installed it, built it or type-checked it. A dependency break or a type
# error landed silently and the first person to find out was whoever deployed. `frontend` has had
# a build job all along; the asymmetry looked accidental rather than deliberate.
landing-build:
name: Landing Build
runs-on: ubuntu-latest
defaults:
run:
working-directory: agentwatch-landing
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: ${{ env.NODE_VERSION }}
cache: npm
cache-dependency-path: agentwatch-landing/package-lock.json
- name: Install deps
run: npm ci
# No separate type-check step: unlike `frontend`, the landing app declares no `type-check`
# script — and it doesn't need one. Its next.config sets no `ignoreBuildErrors`, so
# `next build` type-checks as part of the build and fails on a type error by itself.
- name: Build
run: npm run build
env:
NEXT_TELEMETRY_DISABLED: 1

# ─── Docker build ─────────────────────────────────────────────────────────
docker-build:
name: Docker Build
runs-on: ubuntu-latest
needs: [python-tests, frontend-build]

@coderabbitai coderabbitai Bot Jul 12, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

docker-build does not wait for landing-build.

The PR summary and stack context state that docker-build should wait for landing-build, but the needs array only lists python-tests and frontend-build. This means a failing landing-build won't block docker-build, and the new landing CI coverage isn't acting as a gate for the Docker build step.

🔧 Proposed fix 
-    needs: [python-tests, frontend-build]
+    needs: [python-tests, frontend-build, landing-build]
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
needs: [python-tests, frontend-build]
needs: [python-tests, frontend-build, landing-build]
🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/ci.yml at line 174, Update the docker-build job’s needs
configuration to include landing-build alongside python-tests and
frontend-build, ensuring docker-build waits for and is blocked by a failing
landing-build.

if: github.event_name == 'push' && github.ref == 'refs/heads/main'
# Previously gated to `push` on `main`, which meant the images were only ever built *after* a
# change had already merged. A pull request touching Dockerfile.api got no Docker build at all,
# so a broken Dockerfile could only be discovered on main — by which point it's everyone's
# problem. Running it on pull requests as well makes it a gate rather than a post-mortem.
#
# The cost is modest: both builds already use the GitHub Actions layer cache (`cache-from:
# type=gha`), so unchanged layers are pulled rather than rebuilt.
if: github.event_name == 'pull_request' || (github.event_name == 'push' && github.ref == 'refs/heads/main')
steps:
- uses: actions/checkout@v4
- uses: docker/setup-buildx-action@v3
Expand Down Expand Up @@ -177,7 +212,9 @@ jobs:
with:
python-version: ${{ env.PYTHON_VERSION }}
- name: Install pip-audit
run: pip install pip-audit
run: |
pip install -e ".[crypto]"
pip install pip-audit
- name: Audit dependencies
run: pip-audit --desc --requirement <(pip-compile pyproject.toml --quiet 2>/dev/null || echo "")
run: pip-audit --desc
continue-on-error: true
Loading