Skip to content

Conversation

@crazy-max
Copy link
Member

@crazy-max crazy-max commented Oct 21, 2025

First containerized most of the tasks to avoid drifting with external tooling like golangci-lint, go version and so on.

Adds bake definition so we can avoid arbitrary targets from Taskfile and be consistent and repro between inner loop and ci environment. Here is a breakdown of the changes:

  • The local stage in the Dockerfile has been removed since we now create non opinionated binary name.
  • A releaser stage has been added to create proper release artifacts if we want to upload them as GitHub Releases in the future.
  • Git info has been containerized to make everything portable.
  • The new bake definition includes the necessary targets for inner loop and ci environment:
    • Defaults to building binaries if no target is specified
    • validate target group runs lint, test and licenses
    • image and image-cross build the cagent image
    • release target does a cross-build of the binaries and output release artifacts to ./bin/release
    • binaries and binaries-cross build binaries and output to ./bin/build
    • test run go test with coverage and output coverage result to ./bin/coverage that could then be uploaded to codecov if we want to, like we do for other projects https://app.codecov.io/gh/docker
    • licenses runs go-licenses in a containerized env without need to install the binary.
    • lint runs golangci-lint also in a containerized env without need to install the binary.
  • GitHub Actions now uses bake to run validation, building binaries and the image. No need for extra tools to be installed on the runner. Just Docker.
    • I took the opportunity to do cross compilation for binaries related to Fails to build on Windows platform #562 so we can make sure there is no regression. Also uploads binaries to GitHub Artifacts. We could potentially create a GitHub Release when a tag is pushed and upload the binaries there but I let that for a follow-up.

@crazy-max crazy-max force-pushed the bake branch 7 times, most recently from fb3a92f to fbd52a6 Compare October 21, 2025 12:21
@crazy-max crazy-max changed the title bake definition Migrate from Taskfile to Buildx Bake Oct 22, 2025
@crazy-max crazy-max force-pushed the bake branch 6 times, most recently from 5268ebb to 7ba048f Compare October 27, 2025 11:41
assert.NotNil(t, db, "Database should be created successfully")

// Test with invalid path
_, err := NewMemoryDatabase("/:invalid:path")
Copy link
Member Author

@crazy-max crazy-max Oct 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/:invalid:path is technically valid:

#18 6.407 --- FAIL: TestNewMemoryDatabase (0.05s)
#18 6.407     sqlite_test.go:43:
#18 6.407               Error Trace:    /src/pkg/memory/database/sqlite/sqlite_test.go:43
#18 6.407               Error:          An error is expected but got nil.
#18 6.407               Test:           TestNewMemoryDatabase
#18 6.407               Messages:       Should fail with invalid database path
#18 6.407 FAIL

@crazy-max crazy-max changed the title Migrate from Taskfile to Buildx Bake Add bake definition Oct 27, 2025
@crazy-max crazy-max marked this pull request as ready for review October 27, 2025 14:24
@crazy-max crazy-max requested a review from a team as a code owner October 27, 2025 14:24
@@ -1,6 +1 @@
*
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dgageot prefers the "Ignore everything first and then add things that are needed one by one"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do :-)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Np, updated

Copy link
Member Author

@crazy-max crazy-max Nov 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hum this breaks the versioning: https://github.com/docker/cagent/actions/runs/19065808007/job/54456250623?pr=567#step:5:402

#23 0.115 + xx-go build -trimpath -ldflags '-s -w -X github.com/docker/cagent/pkg/version.Version=v1.9.7-68-g4acaa88.m -X github.com/docker/cagent/pkg/version.Commit=4acaa88ba46dfdb9108419234d1a385935dafa80.m' -o /binaries/cagent .

Because the working tree is not clean within the container now.

test:
desc: Run tests
cmd: go test ./...
sources:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did you remove the sources? Is this even needed now that we have the bake target, or maybe this should just call bake?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just kept this target so you can still run tests natively on your host. Specially important on darwin/windows that we can't run in containers.

@@ -1,6 +1,6 @@
module github.com/docker/cagent

go 1.25.3
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sure there is a completely valid reason, I would just like to know why please :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The go directive should theoretically declare the minimum required Go version for the module. The use of a patch version in go.mod (e.g., go 1.21.0) was introduced in Go 1.21:

Go 1.21 introduces a small change to the numbering of releases. In the past, we used Go 1.N to refer to both the overall Go language version and release family as well as the first release in that family.
Go 1.21 Release Notes

In other words, go 1.21 now refers to the release family, while go 1.21.0 refers to a specific version.

As of Go 1.21 and higher:

  • The go line declares a required minimum version of Go to use with this module.

  • Module Reference

It’s best practice to specify .0 for the patch version — for example, go 1.21.0.
Patch releases are, by design, non-breaking: they contain only backward-compatible fixes and improvements. Using .0 signals that the module is compatible with the entire patch series (1.21.x) without requiring users to upgrade to a specific patch version.

This approach ensures that we only compel users to upgrade their Go toolchain when the module genuinely depends on a feature introduced in a newer Go release. In general, keeping the patch version at .0 helps maintain compatibility and reduces friction for downstream users integrating the module.

Copy link
Member Author

@crazy-max crazy-max Nov 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But now looking at 5dda943

go: github.com/alpkeskin/[email protected]: module github.com/alpkeskin/[email protected] requires go >= 1.25.3

We need to set minimum to 1.25.3 anyway.

Also rename cross stage to binaries. cross does not make sense
as name as the output is based on target platforms.

Signed-off-by: CrazyMax <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants