chore(staging): isolate apps VM stack for whatsapp feature work

[mikezio]

Summary

• add an isolated staging compose stack (docker-compose.staging.yml) for feature work
• add helper scripts for staging lifecycle (scripts/staging-up.sh, staging-status.sh, staging-down.sh)
• add .env.staging.example with non-secret template values
• document apps VM staging workflow in README.md

Isolation guarantees

• separate containers: instalab-api-staging, instalab-ui-staging
• separate ports: API 5100, UI 8102
• separate secrets: /srv/secrets/instalab-staging.*
• separate data: /srv/data/instalab-staging
• separate Postgres db/user: instalab_staging

Validation on apps VM

• started staging stack and confirmed healthy:
  • instalab-api-staging on 192.168.4.30:5100
  • instalab-ui-staging on 127.0.0.1:8102
• confirmed production stack remained healthy on 5000 / 8002
• confirmed staging DB is separate and empty (runs=0, schedules=0)

[gemini-code-assist]

Summary of Changes

Hello @mikezio, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request establishes a robust and isolated staging environment designed specifically for feature development, such as the upcoming WhatsApp functionality. By introducing a dedicated Docker Compose stack and helper scripts, developers can now work on new features without impacting existing environments, ensuring a cleaner and more controlled development workflow. The changes also include comprehensive documentation to guide users through the setup and management of this new isolated staging setup.

Highlights

• Isolated Staging Environment: Introduced a dedicated Docker Compose staging stack (docker-compose.staging.yml) to provide an isolated environment for feature development, such as the WhatsApp feature work.
• Staging Helper Scripts: Added helper shell scripts (staging-up.sh, staging-status.sh, staging-down.sh) to streamline the lifecycle management of the new staging environment.
• Staging Environment Configuration: Provided an example staging environment file (.env.staging.example) with non-secret template values for configuring the isolated staging stack.
• Documentation Update: Updated the README.md to include comprehensive documentation on the new Apps VM staging workflow, detailing its setup and usage.
• Isolation Guarantees: Ensured complete isolation for the staging environment, including separate containers, network ports, secret management, data volumes, and PostgreSQL database instances, preventing conflicts with existing production or development setups.

Changelog

• .env.staging.example
  • Added a new example environment file for staging configuration.
• README.md
  • Updated the 'Repo layout' section to include the new docker-compose.staging.yml.
  • Added a new section 'Apps VM staging isolation' detailing the setup, access points, and helper commands for the staging environment.
• docker-compose.staging.yml
  • Added a new Docker Compose file defining isolated instalab-api-staging and instalab-ui-staging services.
  • Configured distinct ports (API 5100, UI 8102), volume mounts for secrets and data, and environment variables specific to the staging environment.
• scripts/staging-down.sh
  • Added a new shell script to stop and remove the instalab-staging Docker Compose stack.
• scripts/staging-status.sh
  • Added a new shell script to display the status of the instalab-staging Docker Compose services.
• scripts/staging-up.sh
  • Added a new shell script to build and start the instalab-staging Docker Compose stack in detached mode.

Activity

• No human activity (comments, reviews, etc.) has been recorded on this pull request yet.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request effectively isolates a staging environment by adding a new Docker Compose stack, helper scripts, and documentation. This is a great initiative for safer feature development. My review focuses on improving the maintainability and portability of the new configuration. The main suggestions are to avoid hardcoded paths and IP addresses in the compose file and scripts by using environment variables or relative paths, and to reduce configuration duplication between the production and staging compose files. These changes will make the setup more robust and easier to manage.

[gemini-code-assist]

This Docker Compose file contains hardcoded absolute paths (e.g., /srv/apps/instalab-staging, /srv/secrets/..., /srv/data/...) and a hardcoded IP address (192.168.4.30). This makes the configuration brittle and not portable, as it's tied to a specific host machine setup.

Consider using environment variables with default values to make these paths and the IP configurable. This would improve maintainability and reusability.

For example:

services:
  instalab-api-staging:
    build:
      context: ${APP_ROOT:-/srv/apps/instalab-staging}
    ...
    ports:
      - "${HOST_IP:-192.168.4.30}:5100:5000"
    volumes:
      - ${APP_ROOT:-/srv/apps/instalab-staging}/app:/app
      - ${SECRETS_ROOT:-/srv/secrets}/instalab-staging.env:/srv/secrets/instalab-staging.env:ro
      # ... and so on for other paths

These variables could then be defined in an .env file.

[gemini-code-assist]

This file is almost a complete copy of docker-compose.yml, with only names, ports, and a few environment variables changed. This duplication can lead to maintenance issues, as changes to one service definition might need to be manually synchronized with the other.

To reduce duplication and improve maintainability, consider using Docker Compose's extends feature or YAML anchors and aliases. You could define a base service in a common file and then extend it in docker-compose.yml and docker-compose.staging.yml to apply environment-specific configurations.

[gemini-code-assist]

The script hardcodes the path /srv/apps/instalab-staging. This makes the script less portable and harder to use in different environments (e.g., local development). It's better to determine the project root relative to the script's location to make it runnable from anywhere.

Suggested change

	cd /srv/apps/instalab-staging
	cd "$(dirname "${BASH_SOURCE[0]}")/.."

[gemini-code-assist]

The script hardcodes the path /srv/apps/instalab-staging. This makes the script less portable and harder to use in different environments (e.g., local development). It's better to determine the project root relative to the script's location to make it runnable from anywhere.

Suggested change

	cd /srv/apps/instalab-staging
	cd "$(dirname "${BASH_SOURCE[0]}")/.."

[gemini-code-assist]

The script hardcodes the path /srv/apps/instalab-staging. This makes the script less portable and harder to use in different environments (e.g., local development). It's better to determine the project root relative to the script's location to make it runnable from anywhere.

Suggested change

	cd /srv/apps/instalab-staging
	cd "$(dirname "${BASH_SOURCE[0]}")/.."