Automate update `known_good_version` with AI coding

[yu-iskw]

Motivation

We update known_good_version of linters on a daily basis. It would be great to leverage AI coding for the chores. For instance, GitHub Copilot Agent might be good, as we can trigger an automation to update linter default versions by a GitHub issue.

Example: Cursor

I testedd Cursor whether or not I can automate the task to update know_good_version of linters. The subsequent cursor rule worked. I'm sure we can also leverage other AI coding tools as GitHub Copilot Agent for the task as well.

# Upgrade Linter Known Good Version

This rule guides the AI on how to update the `known_good_version` field for linters in the codebase.

To upgrade a linter's `known_good_version`:

1.  Identify the specific linter's `plugin.yaml` file in the `linters/` directory (e.g., @linters/yamllint/plugin.yaml).
2.  Locate the `known_good_version` field within the file.
3.  Perform a web search to find the latest stable version of the specific linter.
4.  Double-check that the version found online is valid and exists (e.g., by checking releases on the linter's repository).
5.  Update the `known_good_version` value in the `plugin.yaml` file to the newly found latest version.

[yu-iskw]

@TylerJang27 I don't want to bother you but I appreciate if you could give your thoughts on it. And can you please look into the pull requests to upgrade the versions of linters. Thanks.

https://github.com/trunk-io/plugins/pulls?q=is%3Aopen+is%3Apr+author%3Ayu-iskw+known_good_version

[TylerJang27]

Hi @yu-iskw thanks for the PRs! A couple notes here:

1. For almost all of linters (there are exceptions), we automatically upgrade the linter versions that users have to the latest version that we have validated. While known_good_version is the fallback value that we use, users shouldn't have to modify it at all. This is applied when users run trunk upgrade, and is can be automated for a repo using the action
2. If that upgrade flow isn't working for you, there's likely something else going wrong.
   a. Can you confirm that if you run trunk check enable pylint@2.11.1 and then trunk upgrade --filter=pylint you should get the latest (3.3.7) version?

I'll take a look at leveraging your suggestion for the linters that we don't auto upgrade, but I want to pin down what is missing here first.

[yu-iskw]

@TylerJang27 Thank you for the feedback. And thank you the great product, trunk.

I thoughts trunk automatically follows the latest stable versions of linters. So, I haven't manually specify the installed version of a linter. For instance, I encountered the situation that the version of the linter terraform remains 1.1.0, though I used 1.12.1 in a terraform workspace. The outdated version couldn't catch up with new manners of provider-provided terraform functions. So, I just realized that linters are updated based on known_good_version.

$ trunk check enable terraform
1 linter was enabled:
  terraform 1.1.0

# 1.1.0 still remains
$ trunk upgrade --filter=terraform
Checking for tool upgrades 100% [===================================>]  2/2  1.1s 
Formatting Configs 100% [=========================================>]  12/12  3.7s 
                                                                                  
Already up to date

Aside from the situation, it might be great if trunk tries to recognize used versions of some linters. For instance, I take advantage of .terraform-version with tfenv to pin the terraform version in a terraform workspace. Some other tools as goenv, nodenv, uv and so on support something similar.

[TylerJang27]

Terraform is one of the exceptions 🙃 . We can easily auto-upgrade right now if:

• The tool has a GH release (covers a large subset of tools)
• We install the tool with python or node

Others will have to be manually bumped. I'll go through the PRs you raised that require manual changes.

Aside from the situation, it might be great if trunk tries to recognize used versions of some linters.
That's a good idea, and one we've gotten before. I will make a feature request to formally track it, although it might require a lot of deep integrations.

[TylerJang27]

https://github.com/orgs/trunk-io/discussions/407