TT-17742: scope eol-notifier distro tracking to policy-approved cycles by rafalgolarz · Pull Request #154 · TykTechnologies/github-actions

rafalgolarz · 2026-08-19T12:13:53Z

Summary

Add an optional cycles field to Dependencyin the eol-notifier config, letting an entry restrict tracking to specific release cycles (e.g. ["7", "8", "9"] for RHEL) instead of every cycle a product publishes.
Fix .github/eol-notifier/dependencies.yaml: the RHEL/Ubuntu/Debian entries named specific versions in their comments and display names, but with no filtering mechanism the notifier was alerting on every cycle each product publishes (e.g. RHEL 6 and 10, not just the policy-approved 7/8/9). Wire cycles in so tracking now matches what the names claim.
Add the previously-missing EE-FIPS validated-set tracking entries (RHEL 7/8/9, Ubuntu 24.04 only) - the config had a comment describing this set but no actual entries for it.

Why

dependencies.yaml had version numbers in dependency names and comments (e.g. "RPM (RHEL 7, 8, 9)"), but Dependency had no field to scope tracking to those cycles - dependenciesFor matched purely on product, so product: rhel picked up every RHEL release cycle from the endoflife.date API regardless of the name. This meant alerts could fire for versions outside the policy's approved set, and the EE-FIPS set (a narrower list than the general DEB/RPM sets) wasn't tracked at all.

Jira Ticket

TT-17742

Description

Type of Change

Changes Made

Testing

Manually triggered the affected workflow(s) and verified expected behaviour
Checked that existing workflows are not broken

Checklist

dependencies.yaml named specific RHEL/Ubuntu/Debian versions in comments and entry names, but the notifier has no concept of a release cycle filter, so each entry alerted on every cycle its product publishes (e.g. RHEL 6 and 10, not just the approved 7/8/9). The EE-FIPS validated set (RHEL 7/8/9, Ubuntu 24.04 only) had no tracking entries at all. Add an optional `cycles` field to a dependency so it can restrict tracking to named release cycles, and wire it through new-version and EOL detection. Update dependencies.yaml to use it and add the missing EE-FIPS entries.

github-actions · 2026-08-19T12:14:34Z

zizmor findings

Severity	Count
High	90
Medium	88
Low	2
Info	11

Full details are in the workflow run.

probelabs · 2026-08-19T12:14:39Z

This PR enhances the eol-notifier by introducing a cycles field to its configuration. This allows end-of-life tracking to be scoped to specific release cycles (e.g., RHEL "7", "8", "9"), preventing alerts for versions outside of the defined policy and enabling more precise monitoring.

The configuration in .github/eol-notifier/dependencies.yaml is updated to use this new feature, aligning the tracked RHEL, Ubuntu, and Debian versions with their descriptions. The PR also adds previously missing entries for the EE-FIPS validated set, which covers a specific subset of RHEL and Ubuntu versions.

Files Changed Analysis

The changes are focused on the eol-notifier tool and its configuration:

.github/eol-notifier/dependencies.yaml: The main configuration is updated to utilize the new cycles filter for RHEL, Ubuntu, and Debian, and adds new entries for the EE-FIPS set.
eol-notifier/README.md: Documentation is updated to describe the new cycles configuration option.
eol-notifier/cmd/notifier/config.go: The Dependency struct is extended with a Cycles []string field. Validation logic is added to ensure cycles are not empty or duplicated, and a tracksCycle method is introduced for filtering.
eol-notifier/cmd/notifier/lifecycle.go: The core alert detection logic is modified. The dependenciesFor function now filters dependencies based on the release cycle, making alerting more specific. A key detail is that new version alerts intentionally bypass this filter to ensure newly released cycles are always reported.
eol-notifier/cmd/notifier/config_test.go & lifecycle_test.go: Comprehensive unit tests are added to validate the new configuration options and ensure the cycle-based filtering works as expected, including edge cases for new version alerts.

Architecture & Impact Assessment

What this PR accomplishes: It refines the eol-notifier to allow fine-grained control over which product release cycles are tracked. This reduces alert noise from irrelevant versions and allows for precise configuration based on internal support policies.
Key technical changes introduced:
- A cycles array is added to the dependency configuration schema, allowing users to specify which release versions to track.
- The core logic in lifecycle.go is updated to filter product releases against this cycles list before generating end-of-life alerts.
- Input validation is added in config.go to handle the new field correctly.
Affected system components: The eol-notifier GitHub Action is the sole component affected. The change is backward-compatible, as the cycles field is optional. If omitted, the notifier retains its previous behavior of tracking all release cycles for a given product.
Visualization of Logic Change:

graph TD
    subgraph "Previous Logic"
        A[For each release] --> B{Is product tracked?};
        B --> C{Is phase tracked?};
        C --> D[Generate EOL Alert];
    end

    subgraph "New Logic"
        E[For each release] --> F{Is product tracked?};
        F --> G{Is phase tracked?};
        G --> H{"Is release cycle in 'cycles' list?
(or list is empty)"};
        H --> I[Generate EOL Alert];
    end

Scope Discovery & Context Expansion

The changes are well-contained within the eol-notifier action and its configuration. The primary impact is on the output of the notifier, making its alerts more accurate and relevant to the configured policies.

The action's entry point is eol-notifier/cmd/notifier/main.go, which orchestrates loading the configuration and running the alert detection.
The workflow file .github/workflows/eol-notifier.yaml defines how this action is triggered and used within the repository's CI/CD pipeline.
By modifying the core filtering logic, this PR ensures that any system or team relying on the eol-notifier's alerts will receive more precise information, reducing the need for manual filtering of notifications for out-of-scope product versions.

Metadata

Review Effort: 2 / 5
Primary Label: enhancement

Powered by Visor from Probelabs

Last updated: 2026-08-20T13:50:36.281Z | Triggered by: pr_updated | Commit: 3affbca

💡 TIP: You can chat with Visor using /visor ask <your question>

probelabs · 2026-08-19T12:15:05Z

✅ Security Check Passed

No security issues found – changes LGTM.

✅ Architecture Check Passed

No architecture issues found – changes LGTM.

✅ Security Check Passed

No security issues found – changes LGTM.

\n\n

✅ Architecture Check Passed

No architecture issues found – changes LGTM.

\n\n \n\n

✅ Quality Check Passed

No quality issues found – changes LGTM.

Powered by Visor from Probelabs

Last updated: 2026-08-20T13:50:35.141Z | Triggered by: pr_updated | Commit: 3affbca

💡 TIP: You can chat with Visor using /visor ask <your question>

buraksezer

I added a few comments.

buraksezer · 2026-08-19T13:01:53Z

-					IsLTS:        release.IsLTS,
-					Dependencies: dependenciesFor(config, name, ""),
-				})
+				if dependencies := dependenciesFor(config, name, "", release.Name); len(dependencies) > 0 {


I think we should not apply the filter to new-version alerts That alert is there to tell us the vendor shipped something our config doesn't know about yet, so putting it through the config's own list means it can never fire for rhel, ubuntu or debian. And we can't recover it later. recordRun stores every release the API returns, so RHEL 11 counts as seen the day it lands. Add "11" to cycles a year from now and you still hear nothing about it. Phase has the same problem and is passed empty on purpose; the comment on line 348 says why. I'd do the same with the cycle.

good catch! thank you.
Please re-review.

The phases look good now. I ran the latest code against the live state. RHEL 9's full support (2027-05-31) appears in the first digest. So that part works. Not tracking eoas for Ubuntu is also correct. For 24.04 and 26.04 it has the same date as eol, so every line should appear twice.

The new-version change is not there. lifecycle.go is the same in both commits. Line-153 still filters by cycle.

And one more small thing. TestDetectAlertsDistroTracksEveryPhase never checks eoes but the comment says it is the phase we would otherwise miss.

Thanks Burak, reviewing it now 🙏

buraksezer · 2026-08-19T13:04:18Z

    product: mariadb
    track: [eol, eoes]

+  # RPM: RHEL 7, 8, and 9.


All three entries track eol only. I checked and found that RHEL 9 then alerts on 2032.05.31 while Full Support ends 2027.05.31 and we would call Debian 12 dead while Debian LTS runs to 2028-06-30. What about tracking eoes and eoas tracks?

konrad-sol · 2026-08-20T11:16:31Z

+  - name: RPM (RHEL 7, 8, 9)
+    product: rhel
+    track: [eoas, eol, eoes]
+    cycles: ["7", "8", "9"]


was not adding RHEL 10 planned? we still have 4 years of support, so not sure

I took the list from:
https://tyktech.atlassian.net/wiki/spaces/CVBGF/pages/4247093265/Proposal+-+Package+Distro+and+EoL+Policy

per Slack, added 10. thank you

konrad-sol · 2026-08-20T11:20:32Z

+  # DEB: Ubuntu 22.04 LTS, 24.04 LTS, 26.04 LTS, and Debian 12 (Bookworm),
+  # 13 (Trixie). Debian's eoes (Debian LTS) runs well past its eol (Debian
+  # Security Support), so eol alone would call a release dead years early.
+  - name: DEB (Ubuntu 22.04 LTS, 24.04 LTS, 26.04 LTS)


what about amazonlinux:2023 and rockylinux:9?
eoas in less than a year

per Slack, we should skip it

rafalgolarz requested a review from buraksezer August 19, 2026 12:13

rafalgolarz self-assigned this Aug 19, 2026

rafalgolarz requested review from a team and konrad-sol August 19, 2026 12:13

buraksezer reviewed Aug 19, 2026

View reviewed changes

TT-17742 address code review

1518d2c

rafalgolarz requested a review from buraksezer August 19, 2026 13:33

konrad-sol reviewed Aug 20, 2026

View reviewed changes

TT-17742 address code review

3affbca

rafalgolarz requested a review from konrad-sol August 20, 2026 13:50

Uh oh!

Conversation

rafalgolarz commented Aug 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Why

Jira Ticket

Description

Type of Change

Changes Made

Testing

Checklist

Uh oh!

github-actions Bot commented Aug 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

zizmor findings

Uh oh!

probelabs Bot commented Aug 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Files Changed Analysis

Architecture & Impact Assessment

Scope Discovery & Context Expansion

Uh oh!

probelabs Bot commented Aug 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Security Check Passed

✅ Architecture Check Passed

✅ Security Check Passed

✅ Architecture Check Passed

✅ Quality Check Passed

Uh oh!

buraksezer left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

rafalgolarz commented Aug 19, 2026 •

edited

Loading

github-actions Bot commented Aug 19, 2026 •

edited

Loading

probelabs Bot commented Aug 19, 2026 •

edited

Loading

probelabs Bot commented Aug 19, 2026 •

edited

Loading