Add missing profile configs for portainer-automation #134

New Issue

Polly · 2026-07-06T19:25:56Z

Polly commented

2026-07-06 19:25:56 +00:00

Description

When setting up the portainer-automation service in different environments, I want application-prod.properties, application-ci.properties, and .env.example files to be present, so I can configure and deploy the service consistently across production and CI environments.

Acceptance Criteria

GIVEN the portainer-automation module directory WHEN listed THEN application-prod.properties exists with production-appropriate defaults
GIVEN the portainer-automation module directory WHEN listed THEN application-ci.properties exists with CI-appropriate overrides
GIVEN the project root WHEN listed THEN .env.example exists with all required environment variables documented
GIVEN all three new files WHEN reviewed THEN no hardcoded secrets are present (all secrets reference env vars)

Technical Notes

Follow the same pattern as existing profile configs in other modules
.env.example should document every variable with a comment explaining its purpose
CI profile should point to test/stub endpoints where applicable

Dependencies

Blocked by: portainer-automation core config structure

Effort: XS (1-2 days)

## Description When setting up the portainer-automation service in different environments, I want `application-prod.properties`, `application-ci.properties`, and `.env.example` files to be present, so I can configure and deploy the service consistently across production and CI environments. ## Acceptance Criteria - GIVEN the portainer-automation module directory WHEN listed THEN `application-prod.properties` exists with production-appropriate defaults - GIVEN the portainer-automation module directory WHEN listed THEN `application-ci.properties` exists with CI-appropriate overrides - GIVEN the project root WHEN listed THEN `.env.example` exists with all required environment variables documented - GIVEN all three new files WHEN reviewed THEN no hardcoded secrets are present (all secrets reference env vars) ## Technical Notes - Follow the same pattern as existing profile configs in other modules - `.env.example` should document every variable with a comment explaining its purpose - CI profile should point to test/stub endpoints where applicable ## Dependencies - Blocked by: portainer-automation core config structure ## Effort: XS (1-2 days)

Polly added the

config

effort:xs

labels 2026-07-06 19:26:01 +00:00

Archie commented

2026-07-06 19:28:06 +00:00

Architecture Review — #134

Context Reviewed

I reviewed the full repository, the test branch (where Phase 1 lives), and the existing profile config patterns from cftunnels-service.

What Exists vs What's Missing

File	Status
`portainer-automation/src/main/resources/application.properties`	✅ Exists on `test` branch
`portainer-automation/src/main/resources/application-local.properties`	✅ Exists on `test` branch
`portainer-automation/src/main/resources/application-prod.properties`	❌ Missing — this issue
`portainer-automation/src/main/resources/application-ci.properties`	❌ Missing — this issue
`portainer-automation/.env.example` (or root `.env.example` for PA)	❌ Missing dedicated PA env example — this issue

Existing `test` Branch Base Configs

application.properties (the default):

server.port=8081
portainer.base-url=https://192.168.0.100:9442
portainer.api-key=${PORTAINER_API_KEY:}
portainer.endpoint-id=1
portainer.service.api-key=${PORTAINER_SERVICE_API_KEY:change-me}

application-local.properties (for local dev via Cloudflare Tunnel):

portainer.base-url=https://devdocker.hithomelabs.com
portainer.api-key=${PORTAINER_API_KEY:dev-test-key}
portainer.endpoint-id=2
portainer.service.api-key=dev-test-key

Pattern Reference from Existing Module

The cftunnels-service uses the same pattern:

application.properties — base config with env-var placeholders
application-prod.properties — prod overrides, all secrets via ${...}
application-ci.properties — CI overrides with H2/test endpoints
No secrets hardcoded anywhere

Architecture Notes

application-local.properties exists but application-dev.properties doesn't — If a dev profile is needed later, consider adding it. Currently local serves that purpose.
SSL in prod: Portainer prod endpoint (:9443) uses proper SSL certs, so the !local profile's standard RestTemplate (no trust-all) will work correctly.
CI config: The CI Runner runs on the same Docker network, so http://portainer-test:9000 (if you set up a test Portainer) would be reachable. If no test Portainer exists, the CI config still validates that property binding works.
.env.example location: Put it at portainer-automation/.env.example rather than root, since root already has a cftunnels-service-focused .env.example.

Summary: Clean XS effort — straightforward, well-scoped. Just be sure to keep secrets out and follow the existing pattern from cftunnels-service.

## Architecture Review — #134 ### Context Reviewed I reviewed the full repository, the `test` branch (where Phase 1 lives), and the existing profile config patterns from `cftunnels-service`. ### What Exists vs What's Missing | File | Status | |------|--------| | `portainer-automation/src/main/resources/application.properties` | ✅ Exists on `test` branch | | `portainer-automation/src/main/resources/application-local.properties` | ✅ Exists on `test` branch | | `portainer-automation/src/main/resources/application-prod.properties` | ❌ Missing — **this issue** | | `portainer-automation/src/main/resources/application-ci.properties` | ❌ Missing — **this issue** | | `portainer-automation/.env.example` (or root `.env.example` for PA) | ❌ Missing dedicated PA env example — **this issue** | ### Existing `test` Branch Base Configs **`application.properties`** (the default): ```properties server.port=8081 portainer.base-url=https://192.168.0.100:9442 portainer.api-key=${PORTAINER_API_KEY:} portainer.endpoint-id=1 portainer.service.api-key=${PORTAINER_SERVICE_API_KEY:change-me} ``` **`application-local.properties`** (for local dev via Cloudflare Tunnel): ```properties portainer.base-url=https://devdocker.hithomelabs.com portainer.api-key=${PORTAINER_API_KEY:dev-test-key} portainer.endpoint-id=2 portainer.service.api-key=dev-test-key ``` ### Recommended Content for New Files #### 1. `application-prod.properties` Follow the pattern from `cftunnels-service/application-prod.properties` — no secrets, all env vars: ```properties # Production Portainer Configuration # Targets the production Portainer instance on the internal network portainer.base-url=https://192.168.0.100:9443 portainer.api-key=${PORTAINER_API_KEY} portainer.endpoint-id=1 portainer.service.api-key=${PORTAINER_SERVICE_API_KEY} ``` Key decisions: - **URL**: `https://192.168.0.100:9443` (per architecture issue #124 — Portainer Prod CE on `:9443`) - **endpoint-id**: `1` (matches the default — likely the primary Docker endpoint) - All secrets reference env vars with **no default values** (fail-fast in production) #### 2. `application-ci.properties` For CI environment — use stub/test endpoints: ```properties # CI-specific Portainer Configuration # Uses test/stub endpoints during CI pipeline testing portainer.base-url=http://portainer-test:9000 portainer.api-key=${PORTAINER_API_KEY:ci-test-key} portainer.endpoint-id=1 portainer.service.api-key=${PORTAINER_SERVICE_API_KEY:ci-test-key} ``` Key decisions: - **URL**: `http://portainer-test:9000` (HTTP, internal CI network — no SSL needed in CI) - Allows CI to validate config loading without real Portainer - Provides fallback defaults for test keys #### 3. `.env.example` (in `portainer-automation/` directory) Document every env var used by the module: ```bash # ============================================ # Portainer Automation Service — Environment Variables # ============================================ # Copy this file to .env and fill in your values. # This service is NOT exposed via Cloudflare Tunnel. # Portainer API Key for the target Portainer instance # Create via Portainer UI: Settings → Authentication → Access tokens PORTAINER_API_KEY=ptr_your_portainer_api_key_here # Portainer Service API Key (used for CI→Automation auth) # This is the key CI workflows send in the X-API-Key header PORTAINER_SERVICE_API_KEY=change-me # Active Spring profile (local | ci | prod) # Default: none (uses application.properties base config) SPRING_PROFILES_ACTIVE=local ``` ### Pattern Reference from Existing Module The `cftunnels-service` uses the same pattern: - `application.properties` — base config with env-var placeholders - `application-prod.properties` — prod overrides, all secrets via `${...}` - `application-ci.properties` — CI overrides with H2/test endpoints - No secrets hardcoded anywhere ### Architecture Notes 1. **`application-local.properties` exists but `application-dev.properties` doesn't** — If a `dev` profile is needed later, consider adding it. Currently `local` serves that purpose. 2. **SSL in prod**: Portainer prod endpoint (`:9443`) uses proper SSL certs, so the `!local` profile's standard `RestTemplate` (no trust-all) will work correctly. 3. **CI config**: The CI Runner runs on the same Docker network, so `http://portainer-test:9000` (if you set up a test Portainer) would be reachable. If no test Portainer exists, the CI config still validates that property binding works. 4. **`.env.example` location**: Put it at `portainer-automation/.env.example` rather than root, since root already has a `cftunnels-service`-focused `.env.example`. --- **Summary:** Clean XS effort — straightforward, well-scoped. Just be sure to keep secrets out and follow the existing pattern from `cftunnels-service`.

Archie added the

architect:complete

label 2026-07-06 19:28:12 +00:00

Archie referenced this issue

2026-07-08 19:37:49 +00:00

[ARCHITECTURE] Multi-Module Gradle Restructure + Portainer Automation Service #124

Polly referenced this issue

2026-07-09 20:54:00 +00:00

Fix SSL certificate handling in PortainerClientConfig for production profile #156

Archie referenced this issue

2026-07-09 20:55:38 +00:00

[ARCHITECTURE] Multi-Module Gradle Restructure + Portainer Automation Service #124