Skip to content

chore: update Go version to v1.22.0 (new MSRV for v1.x and main)#2285

Merged
melekes merged 50 commits intocometbft:mainfrom
faddat:faddat/go-122
Apr 10, 2024
Merged

chore: update Go version to v1.22.0 (new MSRV for v1.x and main)#2285
melekes merged 50 commits intocometbft:mainfrom
faddat:faddat/go-122

Conversation

@faddat
Copy link
Contributor

@faddat faddat commented Feb 10, 2024

close: #2726

This PR updates go to v1.22.0


PR checklist

  • Tests written/updated
  • Changelog entry added in .changelog (we use unclog to manage our changelog)
  • Updated relevant documentation (docs/ or spec/) and code comments
  • Title follows the Conventional Commits spec

@faddat faddat changed the title deps: use golang v1.22.0 chore: use golang v1.22.0 Feb 10, 2024
@faddat
Copy link
Contributor Author

faddat commented Feb 10, 2024

issue with pre-commit

@faddat
Copy link
Contributor Author

faddat commented Feb 15, 2024

This PR requires that:

be merged in cometbft-db

@faddat
Copy link
Contributor Author

faddat commented Feb 22, 2024

@github-actions
Copy link

github-actions bot commented Mar 6, 2024

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale For use by stalebot label Mar 6, 2024
@github-actions github-actions bot closed this Mar 10, 2024
@sergio-mena sergio-mena reopened this Mar 13, 2024
@github-actions github-actions bot removed the stale For use by stalebot label Mar 14, 2024
@faddat
Copy link
Contributor Author

faddat commented Mar 14, 2024

@sergio-mena this PR is held up by:

But I just noticed that some people were succeeding by using the full version of go (eg 1.22.0) so I'll try that.

Yep, now just blocked by cometbft-db

@faddat
Copy link
Contributor Author

faddat commented Apr 8, 2024

pacman -S package=1.2.3-1

@faddat
Copy link
Contributor Author

faddat commented Apr 8, 2024

Note, by getting Docker out of tm-db (which means dropping rocksdb support or finding good precompiled binaries) we can get this crazy docker situation out of our lives.

Till then I do suggest that we have a dockerfile here, and a dockerfile there. That way, we aren't blocked here on trivial stuff, like the version of Go we use.

Note to reviewers:

The docker image used here is a custom build that ensures that there's good support for both arm and amd64 because arch doesn't natively support that.

I think that we could get a really sensible maxim out of this:

"let's not use cgo, it is far more trouble than it is worth, and harms performance"

I made a PR to the tm-db repo 2-3 years ago with an arch image that would have saved a lot of time in compiling, it wasn't desired so I'm not making the same PR there again, but since we're chronically blocked by the docker image, doing so here seems to make sense.

@faddat
Copy link
Contributor Author

faddat commented Apr 8, 2024

heh, that doesn't seem to work either. I'm going to head to bed, but should figure out another solution tomorrowish.

Note: I would be very happy to move cometbft-db into this repo, even as a part of v1 (fast, I mean) because that would really simplify a lot of work, and make things easier for validators and other operators of comet nodes.

Lmk if that is an appealing solution from the maintainer's side

@faddat faddat marked this pull request as draft April 8, 2024 17:15
Copy link
Collaborator

@andynog andynog left a comment

Choose a reason for hiding this comment

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

Overall looks good to me, added a few minor comments. The only comment that should drive a bit more attention is related to the change of the Docker image for the e2e. Maybe I'm missing the context on this one.

| main | Go version | 1.22 or higher | 1.22 |
| v1.x | Go version | 1.22 or higher | 1.22 |
| v0.38.x | Go version | 1.20 or higher | 1.22 |
| v0.37.x | Go version | 1.20 or higher | 1.22 |
Copy link
Collaborator

Choose a reason for hiding this comment

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

should we be bumping the v0.37.x to Tested with 1.22 if it is in 1.20 in go.mod ? (same comment as the e2e workflow for v0.37.x

Copy link
Contributor Author

Choose a reason for hiding this comment

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

My opinion here is that for

v0.34.x - we should not deprecate this comet at this time because it is the eternal release. Maybe it gets deprecated at 1.0 + 1 release after. I really like 34, even though it is super old. For as long as we will support bugfixes, I'm a proponent of bumping the golang on the 34 release series to the latest release, at all times. There's a technical reason for this -- when chains upgrade, they should always upgrade to the very latest go. This prevents a situation where there are mixed golang runtimes.
v0.37.x - we should bump it to 1.22
v0.38.x - we should bump it to 1.22

Copy link
Collaborator

Choose a reason for hiding this comment

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

Agree with @faddat wrt upgrades.

- uses: actions/setup-go@v5
with:
go-version: '1.21'
go-version: "1.22"
Copy link
Collaborator

Choose a reason for hiding this comment

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

should we be bumping the v0.37.x to Tested with 1.22 if it is in 1.20 in go.mod ? In the past we tested with one release higher than the one in go.mod, so should we leave this one as 1.21 ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Personally, I'd use 1.22, and I'd never use a deprecated Go for a release that's still supported -- afaik, Go supports only the current release, and one before it.

But this is definitely a judgement call.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Do we really need to change this e2e core Image for this PR ? It would be important to understand the reasoning for this change and how it relates to the core goal of this PR which is to bump v1 and main to go 1.22.

If this is not a requirement for the PR (e.g. it's a change for performance improvements), like bumping to 1.22 breaks the e2e tests and changing the image is the only way to fix it. Even though we'd probably need some additional assessment from people on the team that is more familiar with the e2e infra tests in order to evaluate the new image selected. So, if this is not a requirement I'd keep it separate from the PR since it can have implications to the e2e tests and it is unrelated.


```

## 1.1 Installing CometBFT
Copy link
Collaborator

Choose a reason for hiding this comment

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

should update here too

Copy link
Contributor Author

Choose a reason for hiding this comment

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

moment

@adizere
Copy link
Contributor

adizere commented Apr 9, 2024

@faddat do you plan to continue contrib here? if not, tomorrow we plan to take it over and push it to completion. cc @andynog

@faddat
Copy link
Contributor Author

faddat commented Apr 10, 2024

@andynog yeah, I think we just need to make a choice about that docker image. FYI it is a pretty hard and fast matter -- something needs to be done or it simply won't be able to run e2e tests.

Luckily I could be wrong here. Just a moment...

@faddat
Copy link
Contributor Author

faddat commented Apr 10, 2024

Ok :) I can mark this ready to go now, turns out we push the docker image at each commit that hits main in cometbft-db

@faddat faddat marked this pull request as ready for review April 10, 2024 08:44
Co-authored-by: Andy Nogueira <me@andynogueira.dev>
Copy link
Collaborator

@melekes melekes left a comment

Choose a reason for hiding this comment

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

👍

@melekes melekes added this pull request to the merge queue Apr 10, 2024
Merged via the queue into cometbft:main with commit 15eb404 Apr 10, 2024
mergify bot pushed a commit that referenced this pull request Apr 10, 2024
…2285)

close: #2726

This PR updates go to v1.22.0

---

#### PR checklist

- [ ] Tests written/updated
- [ ] Changelog entry added in `.changelog` (we use
[unclog](https://github.com/informalsystems/unclog) to manage our
changelog)
- [ ] Updated relevant documentation (`docs/` or `spec/`) and code
comments
- [ ] Title follows the [Conventional
Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec

---------

Co-authored-by: Sergio Mena <sergio@informal.systems>
Co-authored-by: Anton Kaliaev <anton.kalyaev@gmail.com>
Co-authored-by: Andy Nogueira <me@andynogueira.dev>
(cherry picked from commit 15eb404)

# Conflicts:
#	.github/workflows/e2e-nightly-1x.yml
melekes added a commit that referenced this pull request Apr 10, 2024
…ackport #2285) (#2768)

close: #2726 

This PR updates go to v1.22.0

---

#### PR checklist

- [ ] Tests written/updated
- [ ] Changelog entry added in `.changelog` (we use
[unclog](https://github.com/informalsystems/unclog) to manage our
changelog)
- [ ] Updated relevant documentation (`docs/` or `spec/`) and code
comments
- [ ] Title follows the [Conventional
Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec
<hr>This is an automatic backport of pull request #2285 done by
[Mergify](https://mergify.com).

---------

Co-authored-by: Jacob Gadikian <jacobgadikian@gmail.com>
Co-authored-by: Anton Kaliaev <anton.kalyaev@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

No open projects
Status: Done

Development

Successfully merging this pull request may close these issues.

chore: Bump minimum Go version on main and v1 to v1.22

6 participants