Add GitHub Actions deployment workflow for Google Cloud Run

[oginom]

Summary

• Add automated deployment workflow for Google Cloud Run
• Uses Workload Identity Federation for secure authentication
• Executes existing deploy.sh script with proper environment setup

Setup Instructions

1. Google Cloud Service Account Setup

1. Create a service account for GitHub Actions:

gcloud iam service-accounts create github-actions-deploy \
    --display-name="GitHub Actions Deploy" \
    --description="Service account for GitHub Actions deployment"

2. Grant necessary permissions to the service account:

# Replace YOUR_PROJECT_ID with your actual project ID
export PROJECT_ID="YOUR_PROJECT_ID"
export SA_EMAIL="github-actions-deploy@${PROJECT_ID}.iam.gserviceaccount.com"

# Cloud Run permissions
gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:${SA_EMAIL}" \
    --role="roles/run.admin"

# Container Registry permissions
gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:${SA_EMAIL}" \
    --role="roles/storage.admin"

# IAM permissions for service account management
gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:${SA_EMAIL}" \
    --role="roles/iam.serviceAccountUser"

2. Workload Identity Federation Setup

1. Create a Workload Identity Pool:

gcloud iam workload-identity-pools create "github-pool" \
    --location="global" \
    --display-name="GitHub Actions Pool"

2. Create a Workload Identity Provider:

gcloud iam workload-identity-pools providers create-oidc "github-provider" \
    --location="global" \
    --workload-identity-pool="github-pool" \
    --display-name="GitHub Actions Provider" \
    --attribute-mapping="google.subject=assertion.sub,attribute.actor=assertion.actor,attribute.repository=assertion.repository" \
    --issuer-uri="https://token.actions.githubusercontent.com"

3. Bind the service account to the Workload Identity Provider:

# Replace REPO_OWNER/REPO_NAME with your GitHub repository
export REPO="oginom/maps_llm"

gcloud iam service-accounts add-iam-policy-binding \
    --role roles/iam.workloadIdentityUser \
    --member "principalSet://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/github-pool/attribute.repository/${REPO}" \
    $SA_EMAIL

3. GitHub Secrets Configuration

Add the following secrets to your GitHub repository (Settings > Secrets and variables > Actions):

Required Secrets:

• PROJECT_ID: Your Google Cloud project ID
• WIF_PROVIDER: projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/github-pool/providers/github-provider
• WIF_SERVICE_ACCOUNT: github-actions-deploy@YOUR_PROJECT_ID.iam.gserviceaccount.com
• NEXT_PUBLIC_GOOGLE_MAPS_API_KEY: Your Google Maps JavaScript API key
• NEXT_PUBLIC_GOOGLE_MAPS_ID: Your Google Maps ID for styling
• OPENAI_API_KEY: Your OpenAI API key

How to get PROJECT_NUMBER:

gcloud projects describe YOUR_PROJECT_ID --format="value(projectNumber)"

4. Verification

After setting up all secrets and permissions, the workflow will automatically deploy to Google Cloud Run when code is pushed to the main branch. You can also trigger manual deployments using the "workflow_dispatch" event in GitHub Actions.

🤖 Generated with Claude Code

[claude]

Claude finished @oginom's task —— View job

---

Pull Request Review: GitHub Actions Deployment Workflow

I've reviewed the new GitHub Actions workflow for Google Cloud Run deployment. Here's my comprehensive feedback:

🔒 Security Concerns

Critical Issues:

• Secret Exposure in Logs (.github/workflows/deploy.yml:49 → deploy.sh:2): The set -x flag in deploy.sh:2 will echo all commands to GitHub Actions logs, exposing secrets like OPENAI_API_KEY in plain text
• Unsafe Environment Loading (deploy.sh:11): The export $(cat .env | grep -v '^#' | xargs) pattern can expose secrets in process lists and is vulnerable to injection
• Plain Text Secrets (.github/workflows/deploy.yml:38-43): Writing secrets to .env file during workflow execution creates temporary exposure

Recommendations:

# In deploy.sh, change line 2 from:
set -eux
# To:
set -eu  # Remove -x flag to prevent command echoing

Positive Security Practices:

• ✅ Uses Workload Identity Federation (much more secure than service account keys)
• ✅ Minimal GitHub token permissions (contents: read, id-token: write)
• ✅ Latest versions of Google Cloud actions

🐛 Potential Bugs & Issues

1. Region Configuration Mismatch (.github/workflows/deploy.yml:11 vs deploy.sh:6):

   • Both files hardcode asia-northeast1 but should use a single source of truth
   • Consider using the workflow's REGION environment variable in deploy.sh

2. Missing Error Handling:

   • No validation that required secrets exist before deployment
   • No rollback mechanism if deployment fails
   • No health checks after deployment

3. Environment Variable Dependency (deploy.sh:5):

   • Script expects PROJECT_ID env var but workflow creates .env file first
   • This works but creates unclear dependency ordering

💡 Code Quality & Best Practices

Good Practices:

• ✅ Clear workflow triggers (push to main + manual dispatch)
• ✅ Latest action versions
• ✅ Descriptive step names
• ✅ Proper Docker platform specification

Improvements Needed:

1. Add Build/Test Phase: No validation before deployment is risky
2. Add Caching: No Docker layer or dependency caching impacts performance
3. Environment Consistency: Region should be defined once
4. Add Validation Steps: Check required secrets and environment before deploy

🚀 Performance Considerations

• Missing Docker Caching: Consider adding Docker layer caching to speed up builds
• No Dependency Caching: Could add Node.js dependency caching if build steps are added
• Sequential Processing: Current workflow is efficient for single deployment

🧪 Test Coverage

Major Gap: No testing phase before deployment

• No linting (pnpm lint per CLAUDE.md)
• No build validation (pnpm build)
• No unit/integration tests
• No deployment validation

Recommended Improvements

# Add before deployment step:
- name: Setup Node.js
  uses: actions/setup-node@v4
  with:
    node-version: '18'
    cache: 'pnpm'

- name: Install dependencies
  run: pnpm install

- name: Run linter
  run: pnpm lint

- name: Build application
  run: pnpm build

- name: Run tests
  run: pnpm test # if tests exist

Overall Assessment

This workflow establishes a solid foundation for automated deployment with excellent security practices (Workload Identity Federation). However, the secret exposure issue in deploy.sh is critical and must be addressed before merging. Adding pre-deployment validation would significantly improve reliability.

Review Tasks

• Read and analyze the GitHub Actions workflow file
• Review security practices and authentication approach
• Check workflow structure and best practices
• Evaluate error handling and edge cases
• Provide comprehensive feedback

Priority: Fix the set -x flag in deploy.sh to prevent secret exposure in logs.

[oginom]

@claude please fix the set -x flag

[claude]

Claude finished @oginom's task —— View job

---

✅ Security Issue Fixed: Removed set -x Flag

Todo List:

• Read deploy.sh file to verify current state
• Fix the set -x flag to prevent secret exposure
• Commit the security fix to the PR branch

🔒 Security Fix Summary

Issue: The set -eux flag in deploy.sh:2 would echo all commands to GitHub Actions logs, exposing secrets like OPENAI_API_KEY in plain text.

Solution: Changed set -eux to set -eu to:

• ✅ Remove command echoing (-x flag) to prevent secret exposure
• ✅ Keep error handling (-e flag) to exit on any command failure
• ✅ Keep undefined variable checking (-u flag) for script safety

Result: The deployment script now runs securely without exposing sensitive environment variables in the GitHub Actions logs.

---

View commit |

[oginom]

memo: we also need this role

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:${SA_EMAIL}" \
    --role="roles/artifactregistry.writer"