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.

[davidgamez]

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

[davidgamez]

This can be done in TF. Having it in TF will allow us to have different "clean up" rules per environment. Example-missing rules, that we should add..

[davidgamez]

[suggestion]: I would move this file out of the root folder, as it might give the wrong first impression to developers that this is a Java project.

[davidgamez]

Let's add the release trigger here to deploy the API using the git tag as the version.

[jcpitre]

Just to be clear, it's a release on the infra code that will trigger, not a release on gbfs-validator-java.
That means there will be a version number for gbfs-validator-java and another one for the infra. It does not mean as much for infra, apart from debugging, but why not.
If you mean a release of gbfs-validator-java, we would probably need a repository_dispatch trigger, sent by gbfs-validator-java. I was hesitant to do that because it depends on a MobilityData secret and makes it less generic. But we could check for the existence of the secret before sending the trigger.

[davidgamez]

This is a release on the gbfs-validator-java-infra, not the gbfs-validator-java. Tags don't need to match; in fact, they probably won't. We can update the service independently with no changes to the validator's code. What will be nice is to have some "notification" that we need to update the Java jar, as there is another gbfs-java-validator. This can be done by creating an issue.