feat: use go.mod when no version inputs specified

[raeperd]

Description:

This PR adds automatic go.mod detection when neither go-version nor go-version-file is specified. This simplifies workflows for Go projects that already have a go.mod file.

Before:

steps:
  - uses: actions/checkout@v5
  - uses: actions/setup-go@v6
    with:
      go-version-file: go.mod
  - run: go version

After:

steps:
  - uses: actions/checkout@v5
  - uses: actions/setup-go@v6
    # Automatically detects and uses go.mod from repository root
  - run: go version

Related issue:
Closes #523

Check list:

• Mark if documentation changes are required.
• Mark if tests were added or updated to cover the changes.

[raeperd]

Hi @aparnajyothi-y @priyagupta108,

As a user of this action, this would be a nice quality-of-life improvement — I find myself specifying go-version-file: go.mod in every workflow even though it's the most common setup.

I saw you both reviewed related changes in #705 and #673, so your feedback here would be really valuable. Happy to make any changes needed.

Thank you!

[priya-kinthali]

Hi @raeperd 👋,
Thanks for the PR! We've reviewed it, and based on our analysis the main trade-off with making go.mod the default is backward compatibility, it would be a breaking change for workflows that currently rely on the pre-installed version (they'd silently switch to the go.mod version).

A few related concerns:

• Behaviour change: some workflows intentionally use pre-installed Go; defaulting to go.mod alters runtime setup and download/cache behaviour unexpectedly.
• Hidden patch drift: when go.mod only specifies major.minor (e.g. go 1.21), setup-go resolves the latest patch, which can change over time unless the exact patch is pinned.
• Monorepo ambiguity: defaulting to the root go.mod is wrong for many multi-module repos unless the path is chosen explicitly.
• Runner drift: GitHub-hosted runners keep updating pre-installed Go and remove EOL versions, so the current fallback isn't static either.

Since the opt-in(go-version-file: go.mod) already exists, could you please share whether you still need this as a default? That'll help us decide the best path forward. Thanks!

[raeperd]

Thanks for the detailed review. Yes, I still think this is a useful and reasonable default.

This PR uses the root go.mod only when neither version input is specified and the file exists. Otherwise, the current pre-installed-version fallback remains unchanged.

Regarding the concerns:

• Behavior change: This affects only workflows that have a root go.mod but intentionally prefer the runner’s Go version. I believe that is a niche compatibility case rather than a broad breaking change.
• Patch drift: This already occurs with go-version-file: go.mod. Projects requiring an exact patch can declare one or specify it explicitly.
• Monorepos: Repositories with only nested go.mod files are unaffected. A different module can be selected explicitly.
• Runner drift: This supports the change: the pre-installed version also changes, while go.mod provides a repository-controlled version signal.
• Download/cache: These follow the existing behavior of explicitly using go-version-file: go.mod.

For the common single-module case, using the root go.mod is a reasonable and predictable default with limited compatibility impact.

[priya-kinthali]

Thank you for the detailed response, @raeperd.

Our primary concern remains that changing the default behavior introduces a silent breaking change. Workflows that currently have a root go.mod but do not specify a version input would automatically switch from the pre-installed Go to the version defined in go.mod. Given how widely this action is used, even a seemingly niche scenario can translate into a significant number of affected workflows.

We'd also like to highlight that while the patch drift and download/cache behaviors are consistent with go-version-file: go.mod, that path is an explicit, user-initiated choice. Making it the default applies the same behaviour to users who never opted in, which reduces predictability. Similarly, in monorepo setups, defaulting to the root go.mod may unintentionally resolve to the wrong module's version.

[raeperd]

@priya-kinthali Thanks, that makes sense.

Since the primary concern is backward compatibility rather than the proposed behavior itself, would you be open to considering this change for the next major release? The new default could then be clearly communicated in the release notes and migration guidance.