Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

Build succeeded.

• containerd-build-arm64 : RETRY_LIMIT in 3m 53s (non-voting)
• containerd-test-arm64 : RETRY_LIMIT in 6m 24s (non-voting)
• containerd-integration-test-arm64 : RETRY_LIMIT in 28m 52s (non-voting)

I wonder if you have met the error in #6586

I wonder if you have met the error in #6586

Yeah. I wanted to know what we really need and how does that work with Go 1.16.

@thaJeztah I don't fully understand the motivation of #5441. After removing the empty-mod hack, seems go mod vendor doesn't bring outdated dependencies but go.sum has these.

It's possible that go 1.17 improved some things (or that dependencies were updated) at the time, without it, some dependencies were resolved, causing other dependencies to be updated (or introduced)

Build succeeded.

• containerd-build-arm64 : RETRY_LIMIT in 3m 45s (non-voting)
• containerd-test-arm64 : RETRY_LIMIT in 6m 05s (non-voting)
• containerd-integration-test-arm64 : RETRY_LIMIT in 25m 08s (non-voting)

Build succeeded.

• containerd-build-arm64 : RETRY_LIMIT in 4m 41s (non-voting)
• containerd-test-arm64 : RETRY_LIMIT in 6m 32s (non-voting)
• containerd-integration-test-arm64 : RETRY_LIMIT in 30m 45s (non-voting)

It's possible that go 1.17 improved some things (or that dependencies were updated) at the time, without it, some dependencies were resolved, causing other dependencies to be updated (or introduced)

Hmm, so, do we care newly-added outdated dependencies in go.sum? I still don't quite understand the side-effect of them, if there is.

I don't think the extra ones in go.sum are a huge deal, other than potentially causing more conflicts between PRs. The original issue actually affected a dependency (which, from your comment, and from golang/go#51285 (comment) should no longer seems to be a problem).

It's a bit infuriating though that Go keeps on introducing breaking changes in modules, and not consider them "breaking" because "tooling is out of scope for the Go 1.x stability guarantee" ... sigh

Good. Then I'm going to remove the empty-mod directory here and keep this PR till Go 1.18's official release.

Meantime Go 1.18 has been released: https://go.dev/dl/
Worth to either update/rebase this PR or open a new one.

Meantime Go 1.18 has been released: https://go.dev/dl/ Worth to either update/rebase this PR or open a new one.

Yey! I've just rebased the PR.

No GitHub Actions... I need to dig in.

https://github.com/containerd/containerd/pull/6605/checks

No GitHub Actions... I need to dig in.

https://github.com/containerd/containerd/pull/6605/checks

https://www.githubstatus.com/incidents/fpk08rxnqjz2

I just manually queued them, but we'll see if they show up here..eventually

@estesp Sorry. I actually made the PR smaller, wondering whether my fix broke GitHub Actions or not. Let's wait GitHub's recovery first.

Build succeeded.

• containerd-build-arm64 : SUCCESS in 4m 34s (non-voting)
• containerd-test-arm64 : SUCCESS in 5m 46s (non-voting)
• containerd-integration-test-arm64 : SUCCESS in 25m 27s (non-voting)

@AkihiroSuda Could we get this to 1.6 branch?

@AkihiroSuda Could we get this to 1.6 branch?

Any specific reason?

Usually we don't upgrade Go for backport branches (until reaching EOL)

The current release branches do not build with go1.18 (#6586) , meaning for example that we can't update buildkit to 1.18 . I don't care if the containerd CI starts using 1.18 or not but it should at least build with the latest stable Go.

Yes the first commit can be backported

@tonistiigi I'm curious though; would GO111MODULE=off work as a (temporary) workaround? That should make it ignore go.mod, including the replace rule, and just look at the vendor directory. Looks like we're able to build the containerd binary in Moby, using go 1.18

Agreed that we should have 1.6 building with Go 1.18 in CI. The 1.6 branch is young and will likely outlive Go 1.17.