You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: implement US-010 - Integrate PLG Deployment with GitHub Actions and Scripts
Add PLG Helm deployment to GitHub Actions workflow and oc-deploy.sh script.
PLG environment variables configurable per overlay. PLG is a separate Helm
release that does not affect existing Kustomize deployment.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The PLG (Prometheus, Loki, Grafana) monitoring stack is deployed as a separate Helm release alongside the application. It does not modify or interfere with the existing Kustomize-based application deployment. PLG deployment is integrated into both the GitHub Actions CI/CD pipeline and the local deployment scripts.
6
+
7
+
## Deployment Methods
8
+
9
+
### GitHub Actions (CI/CD)
10
+
11
+
The `build-apps.yml` workflow includes a `deploy-plg` job that runs after application images are built. This job:
12
+
13
+
1. Checks out the repository to access the Helm chart at `deployments/openshift/helm/plg/`
14
+
2. Installs the Helm and `oc` CLIs
15
+
3. Authenticates to OpenShift using environment secrets
16
+
4. Runs `helm upgrade --install` with the OpenShift values file
17
+
18
+
The job runs regardless of whether application images were built (it depends on `build-apps` succeeding or being skipped), ensuring the PLG stack stays up to date even when no application code changed.
19
+
20
+
#### Required GitHub Environment Secrets
21
+
22
+
| Secret | Description |
23
+
|--------|-------------|
24
+
|`OPENSHIFT_SERVER`| OpenShift API server URL |
25
+
|`OPENSHIFT_TOKEN`| Service account token for the target namespace |
|`GRAFANA_ADMIN_PASSWORD`| Grafana admin password (falls back to `admin` if unset) |
28
+
29
+
### Local Deployment (`oc-deploy.sh`)
30
+
31
+
The `scripts/oc-deploy.sh` script deploys the PLG stack as **Step 7**, between applying the Kustomize overlay (Step 6) and creating instance secrets (Step 8). This step:
32
+
33
+
1. Reads PLG-specific configuration from the environment profile (`dev.env` or `prod.env`)
34
+
2. Derives instance-specific Prometheus scrape targets from the Kustomize instance name
35
+
3. Runs `helm upgrade --install` with environment-specific values passed via `--set` flags
36
+
37
+
If the `helm` CLI is not installed, the PLG step is skipped with a warning. The application deployment continues normally.
38
+
39
+
#### Instance-Specific Helm Release
40
+
41
+
Each application instance gets its own PLG Helm release named `<instance>-plg`. Prometheus scrape targets are configured to point at the instance-specific Kubernetes service names (e.g., `my-instance-backend-services`, `my-instance-temporal`).
42
+
43
+
### Teardown (`oc-teardown.sh`)
44
+
45
+
The `scripts/oc-teardown.sh` script includes a step (3b) that uninstalls the PLG Helm release for the instance being torn down. If Helm is not installed or no PLG release exists, the step is skipped gracefully.
46
+
47
+
## Environment Configuration
48
+
49
+
PLG-specific variables are configured in the same environment profile files used by the application (`deployments/openshift/config/<env>.env`). They follow the existing config merge pattern: profile defaults can be overridden by instance-specific files.
|`LOKI_RETENTION_DAYS`|`30`| Log retention period in days |
55
+
|`LOKI_PVC_SIZE`|`10Gi`| Persistent volume size for Loki data |
56
+
|`PROMETHEUS_PVC_SIZE`|`10Gi`| Persistent volume size for Prometheus TSDB |
57
+
|`METRICS_SCRAPE_INTERVAL`|`15s`| How often Prometheus scrapes targets |
58
+
59
+
These variables are read by `oc-deploy.sh` via the `config-loader.sh` library and passed to Helm as `--set` overrides on top of the `values-openshift.yaml` base.
60
+
61
+
## Separation from Kustomize
62
+
63
+
The PLG deployment is completely independent of the Kustomize-based application deployment:
64
+
65
+
- PLG resources are managed by Helm, not Kustomize
66
+
- PLG uses its own labels (`app.kubernetes.io/managed-by: Helm`, `app.kubernetes.io/part-of: plg`)
67
+
- No Kustomize base or overlay files are modified for PLG
68
+
- If PLG deployment fails, the application deployment is unaffected
69
+
70
+
## Accessing Grafana
71
+
72
+
Grafana is not exposed via an OpenShift Route. Access it via port-forwarding:
73
+
74
+
```bash
75
+
# For instance-specific deployments (via oc-deploy.sh)
-**Given** the existing GitHub Actions workflow builds and deploys the application
11
11
-**When** the workflow runs
12
12
-**Then** it also deploys the PLG Helm chart to the same namespace as the application
13
13
14
-
-[]**Scenario 2**: Local deployment scripts deploy PLG
14
+
-[x]**Scenario 2**: Local deployment scripts deploy PLG
15
15
-**Given** the existing deployment scripts in `/scripts` handle application deployment
16
16
-**When** a developer runs the deployment scripts locally
17
17
-**Then** the PLG Helm chart is also deployed to the target namespace
18
18
19
-
-[]**Scenario 3**: PLG environment variables configurable per overlay
19
+
-[x]**Scenario 3**: PLG environment variables configurable per overlay
20
20
-**Given** environment-specific configuration exists for dev, test, and prod
21
21
-**When** deploying to a specific environment
22
22
-**Then** PLG-specific variables (`GRAFANA_ADMIN_PASSWORD`, `LOKI_RETENTION_DAYS`, `LOKI_PVC_SIZE`, `PROMETHEUS_PVC_SIZE`, `METRICS_SCRAPE_INTERVAL`) are sourced from the environment's configuration
23
23
24
-
-[]**Scenario 4**: PLG deployment does not affect existing Kustomize deployment
24
+
-[x]**Scenario 4**: PLG deployment does not affect existing Kustomize deployment
25
25
-**Given** the application is deployed via Kustomize
26
26
-**When** the PLG Helm chart is deployed
27
27
-**Then** the existing Kustomize resources are not modified or disrupted
0 commit comments