linter: migrate linter config, upgrade linter, enable gomod linter

[lzap]

commit c21d511 (HEAD -> lintmigrate2, origin/lintmigrate2)
Author: Lukas Zapletal lzap+git@redhat.com
Date: Mon Aug 4 10:17:38 2025 +0200

linter: upgrade linter GHA to v2.3

Upgrades linter to the latest version that will work with Go 1.23.

commit 01fff3d
Author: Lukas Zapletal lzap+git@redhat.com
Date: Mon Aug 4 10:15:05 2025 +0200

linter: enable gomoddirectives linter

We accidentally pushed a gomod "replace" directive into the main branch,
this commit enables a dedicated linter in order to prevent that.

commit a4591ad
Author: Lukas Zapletal lzap+git@redhat.com
Date: Mon Aug 4 10:13:11 2025 +0200

linter: upgrade to v2 configuration

The linter is no longer compatible with the v1 YAML, this commit was
made via the build-in "migrate" sub-command from the golangci-lint.
Then, comments and empty lines were added back manually.

No changes were made to the configuration other than those made with the
migration tool.

---

Blindly trying if v2.3 will actually work on GHA. If not, will have to downgrade it a bit.

[mvo5]

Looks fine - it will be interesting to see what kinds of new linter errors it will find.

[lzap]

Used AI to create the following summary of the 144 linter issues found by staticcheck. The issues are ordered by frequency.

Personally, I am okay fixing all of them except the unnecessary field selector (QF1008) which I find a little bit too strict or controversial and I lean towards disabling it alltogether. Opinions?

---

Code Simplification Issues (124)

This category includes suggestions for making the code more idiomatic, readable, and efficient by using simpler or more direct language constructs.

QF1008: Unnecessary field selector (58 occurrences)

Issue: The code uses a selector for a field of an embedded struct that can be accessed directly. For example, foo.Bar.Baz could be simplified to foo.Baz if Bar is an embedded field.

Explanation Link

QF1003: Could use tagged switch (12 occurrences)

Issue: An if-else if chain compares the same variable against different values. This can be more cleanly expressed as a switch statement.

Explanation Link

QF1004: Use strings.ReplaceAll (8 occurrences)

Issue: The code uses strings.Replace with an n value of -1, which means "replace all". This is better expressed using the more explicit strings.ReplaceAll function.

Explanation Link

QF1001: Apply De Morgan's law (2 occurrences)

Issue: A boolean expression like !a && !b can be simplified to !(a || b), which is often easier to read.

Explanation Link

S1021: Merge variable declaration and assignment (1 occurrence)

Issue: A variable is declared on one line and then immediately assigned a value on the next. These two lines can be merged into a single declaration and initialization statement (var x = value).

Explanation Link

QF1012: Inefficient fmt.Sprintf usage (1 occurrence)

Issue: The code uses io.Writer.Write([]byte(fmt.Sprintf(...))). It's more efficient to use fmt.Fprintf(writer, ...) directly, as this avoids an unnecessary memory allocation and copy.

Explanation Link

Style Issues (42)

These issues relate to coding style and conventions that improve consistency and readability across the codebase.

ST1005: Incorrectly formatted error string (36 occurrences)

Issue: Error strings should not be capitalized or end with punctuation, as they are often joined with other context.

Explanation Link

ST1023: Redundant type declaration (4 occurrences)

Issue: The type is explicitly declared for a variable when it can be inferred by the compiler from the value on the right-hand side of the assignment. For example, var x int = 5 can be simplified to var x = 5.

Explanation Link

ST1018: Unicode control characters in string (2 occurrences)

Issue: A string literal contains a raw Unicode control character. It's better to use an escape sequence (e.g., \x1e) to make the special character visible and explicit.

Explanation Link

[lzap]

Fixed issue with code formatting. @mvo5 can you give me re-review? Also I remember we talked about this with @supakeen mind giving this a read? Cheers.

[lzap]

I am confused with the CI failure:

go: github.com/osbuild/osbuild-composer/cmd/osbuild-upload-azure imports
	github.com/osbuild/images/pkg/upload/azure: module github.com/osbuild/images@latest found (v0.169.0, replaced by github.com/osbuild/images@v0.169.1-0.20250804180103-fc95b5d8ccd8), but does not contain package github.com/osbuild/images/pkg/upload/azure

[achilleas-k]

Thanks. LGTM in general (minor nitpick below for commit message).

[achilleas-k]

Nitpick: Commit message says "use sprintf" instead of "use fprintf".

[achilleas-k]

This is also going to conflict with #1216, where I already switched the if-else-if sequences to switch-cases.

[supakeen]

Note that the accidental replace push happened in image-builder-cli, so perhaps you can enable the gomod linter there next? :)

[lzap]

This is also going to conflict with #1216

I am screwed in the race to merge then, I have no idea how to get images or composer CI green usually :-D

Will file a PR for the CLI sure. Rebasing now, not sure why tests are unhappy.

[lzap]

Rebased on top of AWS changes, fixed the commit message.

[supakeen]

The tests are unhappy because you changed some of the error messages and they assert those error messages. Probably should change them in the tests as well.

[lzap]

I rebased, I have decided to give up the errors capitalization for now, the blueprint extraction made it much more difficult to sort it out I am constantly running into conflicts. I had to disable few more other new linters, the full list:

• unnecessary field selector: the codebase massively takes advantage of this Go lang feature
• error strings should not be capitalized: a lot of lines, now it is mixed with blueprints repo as well
• unicode control character (tests only): makes one test little bit less readable
• possible nil pointer dereference (tests only): false positives for all functions which make use of t.Skip

This is now ready for re-review, please read carefully because I ran into ton of conflicts which I had to fix up manually.

[mvo5]

I like this (a lot actually). Some tiny nitpick suggestions inline but I can't wait to ship it.

[lzap]

I have rebased and reviewed all commit messages, fixed all of the mentioned by @mvo5 plus improved few of them. I have realized that one linter rule was fixed by two separate commits so I squashed the two into just one.

[supakeen]

Thank you.