LOOPIN-73A — Create Repeatable Staging Deployment and Basic Validation Workflow

[shaig-mahmudov]

Type: CI/CD / Deployment
Priority: High

Description

Create a repeatable GitHub Actions workflow that deploys a selected Loopin API commit to the staging environment and validates that the deployed release is healthy before it is considered successful.

The workflow must use staging-specific configuration and protected GitHub environment secrets. It should record exactly which commit, image and Cloud Run revision were deployed.

Scope

• Create a dedicated staging deployment workflow, for example:

  .github/workflows/deploy-staging.yml

• Trigger the workflow manually through workflow_dispatch.

• Accept a Git ref, commit SHA or branch as an input.

• Resolve the selected ref to an immutable commit SHA.

• Build and push a Docker image tagged with the selected commit SHA.

• Deploy the image to the staging Cloud Run service.

• Use:

  SPRING_PROFILES_ACTIVE=staging

• Use the GitHub Actions protected environment:

  environment: staging

• Load staging configuration from protected GitHub variables, GitHub secrets and the deployment platform secret store.

• Configure required staging dependencies:

  • PostgreSQL
  • Redis
  • JWT configuration
  • Google OAuth client configuration
  • CORS origins
  • object-storage configuration where required for application startup

• Record:

  • deployed commit SHA
  • image URI
  • image digest where available
  • deployed Cloud Run revision
  • deployment URL
  • previously active revision

• Wait for deployment completion.

• Verify liveness:

  GET /api/actuator/health/liveness

• Verify readiness:

  GET /api/actuator/health/readiness

• Use bounded retry and timeout logic rather than fixed sleeps.

• Run a basic unauthenticated API smoke request:

  GET /api/v1/events?page=0&size=1

• Validate successful HTTP responses and valid JSON bodies.

• Mark the deployment unsuccessful when:

  • deployment fails;
  • liveness fails;
  • readiness does not become UP;
  • the public API smoke request fails.

• Print useful deployment information and health-check diagnostics.

• Upload relevant failure logs or command outputs where practical.

• Add staging deployment and rollback documentation.

Rollback Requirements

Before deployment, capture the currently active Cloud Run revision.

Document how to restore traffic to the previous revision using the Cloud Run CLI or console.

The workflow should include the previous revision and rollback command in the GitHub Actions job summary.

Automatic rollback is not required in this issue unless it can be implemented safely without obscuring the original deployment failure.

Security Requirements

• Do not commit staging secrets.
• Do not use production secrets in staging.
• Do not print credentials, tokens or storage signatures.
• Use GitHub Actions OIDC or the existing Workload Identity Federation setup.
• Restrict the workflow to the protected staging GitHub environment.
• Use a staging-specific Cloud Run service and staging-specific backing services.
• Do not enable the development login endpoint in staging.

Documentation

Update the relevant documentation, including:

• docs/DEPLOYMENT.md
• docs/ENVIRONMENT.md

Document:

• required GitHub repository variables;
• required GitHub environment secrets;
• required deployment-platform secrets;
• how to trigger a deployment;
• how the selected ref is resolved;
• health-check URLs;
• how the deployed SHA and revision are recorded;
• how to inspect a failed deployment;
• how to rollback to the previous revision.

Acceptance Criteria

• Staging deployment can be triggered manually through GitHub Actions.
• A selected branch, tag or commit can be deployed.
• The selected ref is resolved to an immutable commit SHA.
• The Docker image is tagged with the deployed commit SHA.
• The workflow uses the protected GitHub staging environment.
• The application starts with the staging Spring profile.
• PostgreSQL and Redis are reachable by the deployed application.
• Liquibase migrations complete successfully.
• Liveness returns UP within the configured timeout.
• Readiness returns UP within the configured timeout.
• The public events API returns a successful valid JSON response.
• The workflow records the commit SHA, image and deployed revision.
• A failed validation marks the workflow and deployment as unsuccessful.
• The previous revision and rollback command are available.
• No production or repository secrets are exposed.
• Deployment and rollback instructions are documented.

Deliverables

• Dedicated staging GitHub Actions workflow
• Bounded health-check script or reusable helper
• Deployment metadata in the GitHub Actions summary
• Failure diagnostics
• Rollback documentation
• Updated environment and deployment documentation

Out of Scope

• Full authenticated Events and Groups CRUD flows
• Real media upload validation
• WebSocket STOMP validation
• Frontend deployment
• Production deployment automation
• Automatic production promotion
• Enabling development authentication in staging