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
To maintain consistency, a GitHub workflow named **`banner-validate`** automatically validates all `banner-content.yaml` files against the schema defined in [`banner-schema.json`](./banner-schema.json).
33
65
@@ -47,26 +79,19 @@ To maintain consistency, a GitHub workflow named **`banner-validate`** automatic
47
79
- Review the error message in the PR checks.
48
80
- Compare your changes with the [schema](./banner-schema.json) and [examples in README](#usage-scenarios--examples).
The `banner-content.yaml` file defines one or more banners displayed in the Konflux UI. Each cluster has its own `banner-content.yaml` under its directory (e.g., `staging/stone-stage-p01/banner-content.yaml`).
53
85
54
-
###**Schema**
86
+
#### 2.2.1. <aname='Schema'></a>**Schema**
55
87
56
88
The schema for banner content is defined in [`banner-schema.json`](./banner-schema.json) and validated automatically by the `banner-validate` GitHub workflow on every PR.
57
89
58
90
The file must contain a **YAML list** where each item represents a banner configuration.
59
91
60
92
---
61
93
62
-
### **Important Behavior**
63
-
64
-
- The <strongstyle="color: red;">UI displays only the first valid active banner</strong> from the list, based on current date, time, and optional recurrence settings.
65
-
- If multiple banners are configured, <strongstyle="color: red;">order matters</strong>.
66
-
67
-
---
68
-
69
-
### **Required and Optional Fields for Each Banner**
94
+
#### 2.2.2. <aname='RequiredandOptionalFieldsforEachBanner'></a>**Required and Optional Fields for Each Banner**
70
95
71
96
📎 For the full schema used in CI validation, see banner-schema.json. This table is a human-friendly reference for banner authors.
72
97
@@ -86,9 +111,9 @@ The file must contain a **YAML list** where each item represents a banner config
@@ -177,7 +202,7 @@ When there are no events to announce:
177
202
178
203
---
179
204
180
-
##📝 How to submit a PR for Banner
205
+
### 2.4. <aname='HowtosubmitaPRforBanner'></a>📝 How to submit a PR for Banner
181
206
182
207
1. Locate the target cluster directory:
183
208
@@ -225,7 +250,15 @@ When there are no events to announce:
225
250
Purpose: Release announcement for Konflux 1.2
226
251
```
227
252
228
-
## ❓ Frequently Asked Questions
253
+
### 2.5. <a name='UIBehavior'></a>✅ UI Behavior
254
+
255
+
- The <strong style="color: red;">UI displays only the first valid active banner</strong> from the list, based on current date, time, and optional recurrence settings.
256
+
- If multiple banners are configured, <strong style="color: red;">order matters</strong>.
257
+
- <strong style="color: red;">Time-related fields like `startTime` and `endTime` are not shown in the UI</strong>; they only control when the banner is active.
258
+
- <strong style="color: red;">The type and summary fields are displayed directly in the UI</strong>. If you want to communicate duration or timing details, please include them within the summary.
259
+
- We enjoyed leveraging the [PatternFly Banner component (v5)](https://v5-archive.patternfly.org/components/banner/) to implement the UI, following its design principles for clarity and consistency.
- Why is only one banner shown even when multiple are configured?
231
264
@@ -245,41 +278,95 @@ When there are no events to announce:
245
278
246
279
<strong style="color: red;">📝 If multiple messages need to be shared at the same time, consider combining them into a well-written summary inside a single banner.</strong>
247
280
248
-
## 📢 Auto Alerts(WIP)
281
+
## 3. <a name='SystemNotifications'></a>📢 System Notifications
282
+
283
+
The infrastructure team uses System Notifications to automatically surface important operational notifications in the Konflux UI.
284
+
285
+
These notifications are generated from monitoring systems or automation scripts as Kubernetes ConfigMaps.
286
+
287
+
The Konflux UI detects and displays these notifications to inform users about system-wide conditions.
We enables the infrastructure team to automatically surface specific operational issues or warnings in the Konflux UI.
291
+
System notifications are stored as Kubernetes ConfigMaps in the `system-notifications/` directory.
251
292
252
-
These alerts would be auto-generated from monitoring systems or automation scripts, written as Kubernetes ConfigMaps, and automatically picked up by the Konflux UI to inform users of system-wide conditions.
293
+
Each ConfigMap contains notification data in the `notification-content.json` field as JSON.
253
294
254
-
### ✅ Alert YAML Format
295
+
<strong>Key points:</strong>
255
296
256
-
Each file under auto-alerts/ must be a valid Kubernetes ConfigMap, including at minimum:
297
+
- The JSON payload supports these fields for each notification object:
298
+
299
+
- <strong>title (optional)</strong>: A short heading. <strong>Defaults to `component.metadata.name` if omitted.</strong>
300
+
- <strong>summary (required)</strong>: A brief, user-facing message displayed as the notification content.
301
+
- <strong>type (required)</strong>: It sets the bell icon. Allowed values: `info`, `warning`, or `danger`.
302
+
303
+
- Payload structure:
304
+
305
+
We recommend using <strong>a single JSON object representing one notification</strong> in `notification-content.json`.
306
+
307
+
However, <strong>a JSON list (array) of notification objects is also allowed</strong> if multiple notifications need to be included in one ConfigMap.
Notifications are organized under the `system-notifications/` directory:
276
332
277
333
```bash
278
334
279
-
auto-alerts/ # Alert ConfigMaps (one file = one alert)
335
+
system-notifications/
280
336
.
281
-
├── alert-1.yaml # Fully valid ConfigMap YAML
282
-
├── alert-2.yaml
283
-
└── kustomization.yaml # Auto-generated, includes all alert YAMLs
337
+
├── notification-1.yaml # A ConfigMap representing one notification
338
+
├── notification-2.yaml
339
+
└── kustomization.yaml # Auto-generated, includes all notifications YAMLs
284
340
285
341
```
342
+
343
+
When there are no active notifications, both the `system-notifications/` folder and its reference in the parent `kustomization.yaml` should be removed automatically to avoid kustomize errors.
- The UI discovers and filters notifications by detecting ConfigMaps labeled with
348
+
`konflux.system.notification: "true".`
349
+
- When a valid notification ConfigMap exists, its notification will be shown in the UI.
350
+
- To remove a notification from the UI, the corresponding ConfigMap must be deleted or renamed so it no longer matches the label.
351
+
- When multiple notifications exist, the UI lists them ordered by their creation time (`creationTimestamp`), <strong>showing the most recent first</strong>.
352
+
- The `type` field controls both the notification’s visual style and the icon shown before the title in the Notification Drawer.
353
+
- We leveraged [PatternFly Notification Drawer (v5)](https://v5-archive.patternfly.org/components/notification-drawer/html/#ws-core-c-notification-drawer-basic) and [Notification Badge (v5)](https://v5-archive.patternfly.org/components/notification-badge) components to implement the UI, following their design principles for consistency and usability.
354
+
- All notifications are always shown as unread. There is no backend tracking for notification state, so <strong>`read/unread` functionality is not supported</strong>.
355
+
356
+
### 3.5. <a name='WhentoAddorRemoveNotifications'></a>✅ **When to Add or Remove Notifications**
357
+
358
+
<strong>These notification ConfigMaps are automatically generated or removed</strong> by monitoring or scripting systems based on current system status.
359
+
360
+
- Add a notification:
361
+
362
+
1. Generate a new ConfigMap YAML file under `system-notifications/`.
363
+
2. Refresh the `kustomization.yaml` in that folder to include the new file.
364
+
3. If the folder does not exist (e.g., no prior notifications), create it and its `kustomization.yaml`, and ensure the parent kustomization includes it.
365
+
366
+
- Remove a notification:
367
+
368
+
1. Delete the corresponding ConfigMap YAML file from `system-notifications/`.
369
+
2. Refresh `kustomization.yaml` to remove the reference.
370
+
3. If no notifications remain, delete the `system-notifications/` directory and remove its reference from the parent kustomization.
371
+
372
+
⚙️ Note: <strong>These add/remove operations are expected to be automated</strong>. Manual edits should only be done in emergencies or for debugging.
0 commit comments