Skip to content

Conversation

@FilipB
Copy link
Collaborator

@FilipB FilipB commented Nov 5, 2025

Adds a custom Claude Code slash command (/update-eol-versions) that automates the process of marking End-of-Life Istio versions in versions.yaml. The command fetches the current supported versions from istio.io and updates the EOL status accordingly.

🤖 Generated with Claude Code

Adds a custom Claude Code slash command (/update-eol-versions) that
automates the process of marking End-of-Life Istio versions in
versions.yaml. The command fetches the current supported versions from
istio.io and updates the EOL status accordingly.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>
Signed-off-by: Filip Brychta <[email protected]>
@FilipB FilipB requested a review from a team as a code owner November 5, 2025 10:58
@codecov
Copy link

codecov bot commented Nov 5, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.11%. Comparing base (38ddb8a) to head (709a1b7).
⚠️ Report is 21 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1326      +/-   ##
==========================================
+ Coverage   77.69%   79.11%   +1.41%     
==========================================
  Files          44       44              
  Lines        2834     2255     -579     
==========================================
- Hits         2202     1784     -418     
+ Misses        524      365     -159     
+ Partials      108      106       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

- Only mark versions as EOL if they are confirmed to be EOL upstream
- Preserve all existing version entries - do not remove them from the file
- The `eol: true` flag makes versions uninstallable but keeps them as valid spec.version values for API compatibility
- After marking as EOL, the charts array should be removed since EOL versions don't need chart URLs
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess not just the charts array but all fields except name and eol, right?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's doing that even with current steps but for sure it will be better to be more specific. I will update this. Thanks!

@dgn
Copy link
Collaborator

dgn commented Nov 5, 2025

Cool idea!

Copy link
Contributor

@sridhargaddam sridhargaddam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, nice @FilipB

Added a /hold so that others can take a look. Feel free to remove it if required.

Copy link
Contributor

@fjglira fjglira left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only a small comment, but I really like this. We should add a note in the release issue to execute this to get the EOL version

- If a version has `eol: true` but is still supported upstream, remove the `eol: true` flag (this handles corrections)
- Preserve the YAML structure and comments
- For EOL versions, keep only `name:`, `eol:` and `ref:` sections

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change


## Important Notes

- Only mark versions as EOL if they are confirmed to be EOL upstream
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To avoid some errors, we should specify what is upstream and give Claude the URL for the repository that we consider upstream in this case. In this maybe we should said something like

Suggested change
- Only mark versions as EOL if they are confirmed to be EOL upstream
- Only mark versions as EOL if they are confirmed to be EOL upstream Istio [project](https://istio.io/latest/docs/releases/supported-releases/)

- Preserve all existing version entries - do not remove them from the file
- The `eol: true` flag makes versions uninstallable but keeps them as valid spec.version values for API compatibility
- For EOL versions, keep only `name:`, `eol:` and `ref:` sections
- Always verify the changes before committing
Copy link
Contributor

@fjglira fjglira Nov 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Always verify the changes before committing
- Show the changes and ask the user to confirm the changes before committing

Maybe be more specific to avoid different kinds of results

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants