feat: Add CI/CD workflows for deploying GBFS Validator Java API

[jcpitre]

Closes #2 and #3

Sets up the full CI/CD pipeline and GCP infrastructure bootstrapping for the GBFS Validator Java API across dev, qa, and prod environments.

What's included:

• setup-environment.sh — bootstraps a GCP project: enables APIs, creates the deployer SA, sets IAM roles, creates the shared Artifact Registry repo, reserves LB IPs, and provisions a Google-managed SSL cert
• setup-deployer-sa-permissions.sh — grants Terraform-specific roles to the deployer SA
• .github/workflows/gbfs-validator-staging.yml — triggers: PR open/sync → dev, push to main → qa, manual dispatch → dev (default) or qa
• .github/workflows/gbfs-validator-prod.yml — manual dispatch only; deploys to prod
• .github/workflows/gbfs-validator-deployer.yml — reusable workflow: builds and pushes Docker image to Artifact Registry, then runs Terraform
• infra/main.tf — passes project_id explicitly to cloud_run and load_balancer modules (critical for prod which uses a different GCP project)
• README.md — documents the environment structure, GCP setup steps, and deployment triggers

Notes:

• Prod uses bare domain gbfs.api.mobilitydatabase.org; dev/qa use {env}.gbfs.api.mobilitydatabase.org
• Prod deploys to project gbfs-validator-prod; staging environments share gbfs-validator-staging

---

Testing:

Since the workflows are not yet on main, they cannot be triggered from the GitHub Actions web UI. Use the gh CLI instead, targeting this branch (see below). You can set a release or snapshot version of gbfs-validator-java. See central.sonatype.com for the available releases. For snapshot unfortunately the snapshot repo cannot be browsed, but you can find some snapshots that were published here

# Deploy to dev
gh workflow run gbfs-validator-staging.yml \
  --repo MobilityData/gbfs-validator-java-infra \
  --ref 3-create-ci-scripts-for-gbfs-validator-java-api \
  -f target_environment=dev \
  -f app_version=2.0.68

# Deploy to qa
gh workflow run gbfs-validator-staging.yml \
  --repo MobilityData/gbfs-validator-java-infra \
  --ref 3-create-ci-scripts-for-gbfs-validator-java-api \
  -f target_environment=qa \
  -f app_version=2.0.68

# Deploy to prod
gh workflow run gbfs-validator-prod.yml \
  --repo MobilityData/gbfs-validator-java-infra \
  --ref 3-create-ci-scripts-for-gbfs-validator-java-api

Once deployed, validate a GBFS feed against each environment:

# dev
curl -s -X POST https://dev.gbfs.api.mobilitydatabase.org/validate \
  -H "Content-Type: application/json" \
  -d '{"feedUrl": "https://gbfs.velobixi.com/gbfs/gbfs.json"}' | jq .

# qa
curl -s -X POST https://qa.gbfs.api.mobilitydatabase.org/validate \
  -H "Content-Type: application/json" \
  -d '{"feedUrl": "https://gbfs.velobixi.com/gbfs/gbfs.json"}' | jq .

# prod
curl -s -X POST https://gbfs.api.mobilitydatabase.org/validate \
  -H "Content-Type: application/json" \
  -d '{"feedUrl": "https://gbfs.velobixi.com/gbfs/gbfs.json"}' | jq .

All three should return a JSON validation report with HTTP 200. The json should also include the gbfs-validator-java version used.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[davidgamez]

nitpick: I would add gbfs-validator-api-{environment} prefix instead of just environment, but I know that the IPs are already created, so we can discard this comment.

[jcpitre]

Agreed it should have been better chosen, but if I'm not mistaken this name is only visible within the project, so the chance of collision with other projects is nil.

[davidgamez]

That's correct, but prod-lb-ipv4 is not specific enough. We can have multiple APIs in the same project that require different DNS+IPs.

[davidgamez]

[out of scope]: In the case of an artifact registry, we should add rules to clean up "old" images.

[davidgamez]

LGTM