add go.mod - #72
Merged
Merged
Conversation
We delayed adding a go.mod and to stick with vendor.mod in case we wanted to transfer this repository to the moby org. However, renaming / moving a module will always be impactful, and there's no "clean" way to do a move; if the old location didn't have a `go.mod`, no naming is enforced, so a reference could be used either as "old module name" or "new module name". If a `go.mod` was present before, and after the rename, then go tools can still handle it incorrectly; it resolves the reference (git sha or tag) _BEFORE_ checking if the module name matches what's defined in `go.mod` (if present). The only alternative is to create a "blessed" hard-fork, and archive the old repository (marking it as deprecated in its `go.mod`) to steer users to the new module name. Either approach won't see downsides to having a `go.mod` present, and in fact for the "blessed hard fork", is even preferable, so let's add one. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
vvoland
approved these changes
Aug 28, 2026
There was a problem hiding this comment.
Pull request overview
Adds first-class Go module metadata to github.com/docker/go-events (moving away from the prior CI-time symlink approach) and updates CI workflows accordingly.
Changes:
- Introduces
go.modandgo.sumfor module-aware builds. - Removes the “Create go.mod” symlink step from CI and CodeQL workflows now that module files exist.
Reviewed changes
Copilot reviewed 2 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| go.mod | Adds module definition, Go version, and initial requirements. |
| go.sum | Adds dependency checksums for module verification. |
| .github/workflows/ci.yml | Removes go.mod/go.sum symlink creation step from CI jobs. |
| .github/workflows/codeql.yml | Removes go.mod/go.sum symlink creation step from CodeQL workflow. |
Suppressed comments (1)
.github/workflows/ci.yml:36
- The workflow’s lint job pins Go to
oldstable. Now thatgo.modexists (and the test job uses it viago-version-file), lint may run on a different Go version than the module’s declared minimum; ifoldstableresolves to a version lower than thegodirective, this job will fail with “go.mod requires go >= …”. Consider usinggo-version-file: go.modhere to keep CI consistent with the module definition.
- uses: actions/setup-go@b7ad1dad31e06c5925ef5d2fc7ad053ef454303e # v7.0.0
with:
go-version: "oldstable"
cache: false
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Member
Author
|
Will do some small follow-ups; now that we have a |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
add go.mod
We delayed adding a go.mod and to stick with vendor.mod in case
we wanted to transfer this repository to the moby org.
However, renaming / moving a module will always be impactful, and
there's no "clean" way to do a move; if the old location didn't
have a
go.mod, no naming is enforced, so a reference could beused either as "old module name" or "new module name".
If a
go.modwas present before, and after the rename, then gotools can still handle it incorrectly; it resolves the reference
(git sha or tag) BEFORE checking if the module name matches
what's defined in
go.mod(if present).The only alternative is to create a "blessed" hard-fork, and
archive the old repository (marking it as deprecated in its
go.mod) to steer users to the new module name.Either approach won't see downsides to having a
go.modpresent,and in fact for the "blessed hard fork", is even preferable, so
let's add one.