ci: scope the website deploy workflow to the website stack - #526
Open
izzywdev wants to merge 2 commits into
Open
ci: scope the website deploy workflow to the website stack#526izzywdev wants to merge 2 commits into
izzywdev wants to merge 2 commits into
Conversation
"Deploy FuzeFront Website (SSH)" ran on EVERY pull request to master with no
paths filter, and planned Terraform against AWS us-east-1. That plan fails:
Error: no matching EC2 VPC found
data.aws_vpc.default fuzefront-website/infrastructure/main.tf:31
Error: reading ELBv2 Load Balancers: couldn't find resource
data.aws_lb.main :83
Error: reading Auto Scaling Group (fuzefront-website-production-asg): empty result
data.aws_autoscaling_group.main :93
All three are DATA sources — Terraform reading pre-existing AWS resources. All
three resolve to nothing, so the VPC, load balancer and auto-scaling group this
stack expects are simply not there.
The result was a permanently-red required check on pull requests that change
nothing this workflow deploys. Every job it touches works in
./fuzefront-website/{backend,frontend}, and its Terraform is
./fuzefront-website/infrastructure — so the trigger now matches that scope.
This deliberately does NOT hide the failure. A PR touching fuzefront-website/**
still runs the plan and still fails, on the change that actually owns the
problem. What it stops is an unrelated PR being blocked by infrastructure it
never touched.
What this does NOT decide: whether the AWS website stack should exist at all.
CLAUDE.md says prod is Kubernetes on Contabo k3s via Helm/Argo, and the missing
VPC/ALB/ASG suggest this path was decommissioned without retiring its workflow.
Deleting it is a deployment-topology decision for the owner, not a side effect
of unblocking CI.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GaPa3JgrVNtWrGvqQEAEqv
Contributor
Automated code review (gate-code-review)Credit balance is too low Report-only — this check never blocks merge. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
"Deploy FuzeFront Website (SSH)" ran on every pull request to master with no
paths:filter, and planned Terraform against AWSus-east-1. That plan fails outright:All three are data sources — Terraform reading pre-existing AWS resources. All three resolve to nothing, so the VPC, load balancer and ASG this stack expects aren't there.
The effect was a permanently-red check on PRs that change nothing this workflow deploys — it's what's currently blocking #521, which touches only
packages/and an unrelated workflow file.The change
Every job here works in
./fuzefront-website/{backend,frontend}, and its Terraform is./fuzefront-website/infrastructure. The trigger now matches that scope, on bothpushandpull_request.What this does not do
It doesn't hide the failure. A PR touching
fuzefront-website/**still runs the plan and still fails — loudly, on the change that owns the problem. What it stops is an unrelated PR being blocked by infrastructure it never touched.It doesn't decide whether the AWS website stack should exist. CLAUDE.md says prod is Kubernetes on Contabo k3s via Helm/Argo, and the missing VPC/ALB/ASG suggest this path was decommissioned without retiring its workflow. If that's right, the workflow and
fuzefront-website/infrastructure/should probably be deleted — but that's a deployment-topology decision for you, not a side effect of unblocking CI.Note
This PR touches
.github/workflows/deploy.yml, which the new filter includes — so this PR itself will still trigger the failing plan once. Every subsequent unrelated PR won't.Generated by Claude Code