Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v2: upgrade build to include go1.21 #890

Merged
merged 31 commits into from
Sep 16, 2023
Merged

v2: upgrade build to include go1.21 #890

merged 31 commits into from
Sep 16, 2023

Conversation

iand
Copy link

@iand iand commented Sep 11, 2023

Tests pass locally with Go 1.20 and Go 1.21.0

The current UCI workflows don't support using different versions of Go in the same repo. To run the standard workflows we would need to upgrade v1 of go-libp2p-kad-dht to Go 1.21 compatible dependencies (due to quic-go refusing to build with Go 1.21 without an upgrade).

For now, we just want clean builds in v2 without touching v1 yet. This PR gives us that.

I've copied the standard UCI workflows from https://github.com/pl-strflt/uci/ and altered them to pass a working directory to the https://github.com/protocol/multiple-go-modules action. This restricts the checks and tests to run only on the v2 directory. This means that version 1 is not being tested, which is fine while this is on the v2-develop branch, but we will need to revisit when v2-develop is merged into master.

@iand iand added the v2 All issues related to the v2 rewrite label Sep 11, 2023
@iand
Copy link
Author

iand commented Sep 11, 2023

CI is having trouble with different go.mods in the root of the repo and v2

@iand iand self-assigned this Sep 12, 2023
@iand
Copy link
Author

iand commented Sep 13, 2023

The windows failures look real.

v2/config.go Outdated
@@ -178,7 +178,7 @@ type Config struct {
// instantiate a fully functional [DHT] client. All fields that are nil require
// some additional information to instantiate. The default values for these
// fields come from separate top-level methods prefixed with Default.
func DefaultConfig() *Config {
func DefaultConfig() (*Config, error) {
Copy link
Contributor

@dennis-tra dennis-tra Sep 13, 2023

Choose a reason for hiding this comment

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

I guess this is a result from a merge. We don't need an error return value here. This is the source for the comparatively large diff here.

Copy link
Author

Choose a reason for hiding this comment

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

I've removed in the next PR in the chain #887

Copy link
Author

Choose a reason for hiding this comment

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

Will remove here though - didn't realise there were so many

v2/go.mod Outdated Show resolved Hide resolved
v2/go.mod Outdated Show resolved Hide resolved
@dennis-tra
Copy link
Contributor

Most of the diff is just the change that DefaultConfig returns an error now. I would remove that before merging

@dennis-tra
Copy link
Contributor

dennis-tra commented Sep 13, 2023

I have no idea why the windows test is failing. It looks like the records receivedAt timestamp isn't parsed/set incorrectly.

In test TestDHT_handleGetValue_ipns_max_age_exceeded_in_datastore the returned response has a record attached to it although this can only happen if the record in the datastore is still valid. This cannot be the case because we set the MaxRecordAge to 0. A record can only be attached to the response if this condition is true. Assuming there are no errors this means r.cfg.clk.Since(receivedAt) is <= 0. This can only happen if either the clock is malconfigured or the receiveAt timestamp is set/parsed incorrectly 🤔 weird that it works with the other two OS's...

@iand
Copy link
Author

iand commented Sep 13, 2023

Most of the diff is just the change that DefaultConfig returns an error now. I would remove that before merging

Hadn't noticed these. They must be from the merge up from v2-develop this morning

@iand
Copy link
Author

iand commented Sep 13, 2023

I have no idea why the windows test is failing. It looks like the records receivedAt timestamp isn't parsed/set incorrectly.

In test TestDHT_handleGetValue_ipns_max_age_exceeded_in_datastore the returned response has a record attached to it although this can only happen if the record in the datastore is still valid. This cannot be the case because we set the MaxRecordAge to 0. A record can only be attached to the response if this condition is true. Assuming there are no errors this means r.cfg.clk.Since(receivedAt) is <= 0. This can only happen if either the clock is malconfigured or the receiveAt timestamp is set/parsed incorrectly 🤔 weird that it works with the other two OS's...

I know windows has or had a different clock granularity so maybe that is having an effect? This is where the mock clock would actually help.

v2/go.mod Outdated
@@ -1,6 +1,6 @@
module github.com/libp2p/go-libp2p-kad-dht/v2

go 1.20
go 1.21
Copy link
Contributor

Choose a reason for hiding this comment

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

This breaks the Go version compatibility promise adhered to by all of libp2p and PL Go packages in general. Is there a really good reason to do this?

Copy link
Author

Choose a reason for hiding this comment

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

Kubo/Boxo is expecting to upgrade within the next month.

go-libp2p-kad-dht v1 will remain at the current Go version for now. v2 is going to be experimental for a while yet. As long as we don't use any 1.21 features (or 1.20) then we can retain the 2 versions compatibility.

Copy link
Contributor

@marten-seemann marten-seemann Sep 13, 2023

Choose a reason for hiding this comment

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

Kubo and Boxo have the same compatibility guarantee, regardless of the version they’re building the binaries with.

I’ve made significant efforts to support the latest two Go versions in quic-go, even when it would have been a lot easier to just drop Go 1.20. Our users (not only Kubo!) are relying on us keeping our compatibility promise.

There should be really, really good reasons (on the order of weeks of developer time) to justify breaking that promise.

Copy link
Author

Choose a reason for hiding this comment

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

We can drop it back to 1.20. The main point of this pr is to be ready to build with go 1.21, which we were not

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, that makes sense. What uCI is designed to do is test with the latest 2 Go versions (i.e. Go 1.20 and Go 1.21, at this point). This means that the version in go.mod should be kept at the lower version.

Copy link
Author

Choose a reason for hiding this comment

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

Done. We target the go 1.20 language but test with both go 1.20 and go 1.21. If you're happy with this can you approve the PR @marten-seemann ?

.github/uci.yml Outdated
- .github/workflows/go-test.yml
force: true # Configure whether Unified CI should overwrite existing workflows; defaults to false
versions:
go: 1.21 # Configure what version of Go should be used; defaults to oldstable
Copy link
Contributor

Choose a reason for hiding this comment

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

This should include Go 1.20 as well.

Copy link
Author

Choose a reason for hiding this comment

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

This is actually no-op. uci.yaml isn't used by go-check or go-test (see https://filecoinproject.slack.com/archives/C03KLC57LKB/p1694518386936719?thread_ts=1694429677.253269&cid=C03KLC57LKB) Also we have customised both to pass in a v2 working directory, so this is irrelevant.

As mentions in the PR description the plan is to get working builds during v2 development and then integrate the CI with version 1 when we are closer to completion. Right now we are in the frustrating situation of not ever having clean builds.

@iand iand changed the title v2: upgrade to go1.21 v2: upgrade build to include go1.21 Sep 15, 2023
@iand iand merged commit 97e4e02 into v2-develop Sep 16, 2023
11 checks passed
@iand iand deleted the v2-go121 branch September 25, 2023 12:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
v2 All issues related to the v2 rewrite
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants