fix: align kured_version logic with csi/calico pattern

[mysticaltech]

Summary

• Fixes the kured_version is null error when kured_version is omitted from kube.tf
• Aligns kured_version assignment with the established pattern used by csi_version and calico_version

Problem

When kured_version was omitted, the semver comparison on line 19 failed:

Error: Invalid function argument
  local.kured_version is null
  Invalid value for "version_a" parameter: argument must not be null.

Solution

Changed from:

kured_version = var.kured_version != null ? var.kured_version : data.github_release.kured[0].release_tag

To:

kured_version = length(data.github_release.kured) == 0 ? var.kured_version : data.github_release.kured[0].release_tag

This matches the pattern used for csi_version and calico_version, which checks the data source existence directly via length() rather than checking the variable.

Test plan

• terraform fmt passes
• terraform validate passes
• terraform plan works with kured_version omitted (uses GitHub latest)
• terraform plan works with explicit kured_version = "1.20.0"

Fixes #2017

[gemini-code-assist]

Summary of Changes

Hello @mysticaltech, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refactors the version assignment logic for kured within the locals.tf file. The change ensures that the kured_version is robustly determined, either by falling back to a user-provided variable if the GitHub release data source is empty, or by using the latest GitHub release. This resolves a specific null value error that occurred when the kured_version variable was not explicitly set, while also standardizing the version resolution approach across similar components.

Highlights

• Bug Fix: Resolved an issue where local.kured_version could become null when var.kured_version was omitted, leading to errors in subsequent semver comparisons.
• Code Consistency: Aligned the logic for determining kured_version with the established pattern used for csi_version and calico_version in locals.tf.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request correctly addresses a potential null value issue with kured_version by aligning its assignment logic with the more robust pattern used for csi_version and calico_version. The change is well-explained and fixes the described problem. My only suggestion is to also apply this fix to ccm_version for consistency and to prevent similar issues, as it currently uses the old, potentially problematic pattern.

[gemini-code-assist]

This change correctly aligns the logic for kured_version with the safer pattern used elsewhere. However, the same logic is used for ccm_version on line 13, which is not updated. To ensure consistency and prevent potential Terraform errors, ccm_version should also be updated to use the length() check.

For example:

ccm_version = length(data.github_release.hetzner_ccm) == 0 ? var.hetzner_ccm_version : data.github_release.hetzner_ccm[0].release_tag

[Copilot]

Pull request overview

This PR updates the logic for determining kured_version so that it follows the same pattern as csi_version and calico_version, preventing local.kured_version from becoming null when kured_version is omitted. The goal is to ensure the semver comparison for kured_yaml_suffix works reliably with or without an explicitly set kured_version.

Changes:

• Updated locals.tf to derive kured_version from data.github_release.kured when the data source is present and fall back to var.kured_version when it is not.
• Aligned the kured_version selection logic with the existing csi_version and calico_version length-based pattern to avoid indexing into an empty data source and to keep behavior consistent.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.