denis256 notes and projects

Terratest continues its steady pace of maintenance with a focus on keeping its Kubernetes integration current and refining its internal development workflows. The latest updates bring support for Kubernetes v0.36.2 dependencies and a cleanup of the continuous integration configuration to remove inherited rules that no longer apply.

Kubernetes v0.36.2 and Dependency Management

The most impactful change for users working in the cloud native space is the update of the Kubernetes dependencies. The maintainers bumped the k8s.io dependencies to v0.36.2, ensuring that the library remains compatible with the latest releases of the orchestration platform.

Managing Kubernetes dependencies in a Go project is often a complex task. The ecosystem relies on a large number of sub packages that must be kept in sync to avoid version conflicts. When you update k8s.io/client-go, you must also ensure that k8s.io/api and k8s.io/apimachinery match that specific version. This update touches the core of how Terratest interacts with clusters, affecting everything from basic resource creation to complex waiting logic.

For engineers using Terratest to verify their Helm charts or Kubernetes manifests, this update provides a more stable foundation. It pulls in recent bug fixes and performance improvements from the upstream Kubernetes client libraries. You can see the specific version changes in the go.mod file, which now reflects the alignment with the v0.36.2 release cycle.

require (
    k8s.io/api v0.36.2
    k8s.io/apimachinery v0.36.2
    k8s.io/client-go v0.36.2
)

Keeping these dependencies fresh is vital because it allows Terratest to support the latest API features introduced in recent Kubernetes versions. If you are testing resources that use new fields or beta features, having an up to date client library is the only way to ensure your tests can actually “see” and interact with those objects correctly.

Cleaning Up CI with Depguard Refactoring

Code quality in the gruntwork-io/terratest repository is maintained through an extensive suite of linters. One of the tools used is depguard, which allows maintainers to restrict which packages can be imported into specific parts of the codebase. This is particularly useful for preventing the use of internal or deprecated libraries.

In a recent commit, the team decided to drop a Terragrunt specific no direct go getter rule from the linter configuration. This rule was originally designed for the Terragrunt project to ensure that all downloads went through a specific internal wrapper. However, because many Gruntwork projects share configuration templates, this rule accidentally leaked into the terratest repository.

The removal of this rule from the .golangci.yml file simplifies the contribution process. Engineers who want to contribute to the library no longer have to worry about linter errors that reference internal packages from an entirely different project. It is a small but important bit of technical debt cleanup that makes the codebase easier to reason about for outside contributors.

Using depguard effectively requires a balance between strictness and developer experience. While it is good to prevent architectural leaks, keeping rules that are not relevant to the current project only creates confusion. This cleanup shows a commitment to maintaining a high quality but also practical development environment.

Automation with the Stale Bot

Maintaining a popular open source library like Terratest involves managing a large volume of issues and pull requests. To keep the project healthy and focused on active work, the maintainers added a stale bot to auto close inactive items.

The new stale.yml workflow defines the rules for when an issue or pull request is considered inactive. This type of automation is common in large projects because it prevents the backlog from becoming overwhelming. When a contributor opens an issue but does not respond to clarifying questions, the bot will eventually mark it as stale and close it if no further activity occurs.

For users of the project, this means the issue tracker will stay more relevant. You are less likely to encounter “ghost” issues from several years ago that were never resolved and no longer apply to the current version of the code. It also encourages faster feedback loops, as contributors are reminded when their input is needed to move a change forward.

The configuration for the stale bot is usually quite conservative. It provides ample time for a human to intervene before any action is taken. This ensures that valuable but slow moving discussions are not cut short prematurely, while still allowing the project to clear out the noise of abandoned requests.

What to Watch

The move to Kubernetes v0.36.2 and the refinement of the CI pipeline suggests that the project is preparing for a new wave of updates. Here is what you should keep an eye on in the coming weeks:

• Enhanced Kubernetes Helpers. With the new dependency base, we might see more specialized helpers for newer resource types. The recent addition of DaemonSet availability checks is a sign that the team is filling in gaps in the existing API coverage.
• Improved Release Reliability. The recent work on building and publishing release binaries automatically means that new versions of the library will reach users faster and with more consistent artifacts.
• CI Performance. As the team continues to tune the golangci-lint settings, expect the CI runs to become faster and more accurate. This reduces the time it takes for community contributions to be reviewed and merged.

If you are currently using Terratest, it is a good time to update your go.mod to align with these latest changes. Keeping your testing tools in sync with your infrastructure provider versions is the best way to catch regressions early and ensure your automation remains robust as the cloud ecosystem evolves.