Closed obalunenko closed 4 months ago
So, it's already there via https://github.com/stretchr/testify/blob/bb548d0473d4e1c9b7bbfd6602c7bf12f7a84dd2/.github/workflows/main.yml#L10
In my opinion, we should run only the build
workflow and only against go-version: stable
, go-version: oldstable
, and go-version-file: ./go.mod
. Today this would test on 1.22, 1.21, and 1.17 because that's what's written in the go.mod file. The latter protects us against accidentally introducing changes that require it to be increased.
The test
workflow is a subset of the build
workflow, and exists because older versions of go will gofmt differently. I think go.mod (1.17) actually has to be this subset, for now.
@brackendawson Thank you for your review. It's a fair point. I'll close this PR
Description
Please add GoLang 1.22 to our Continuous Integration Matrix. This is crucial for verifying the package's compatibility with the new version of the Go programming language.
Proposed solution
We can add a new version of Go (1.22) to the
.github/workflows/ci.yml
file in the testing matrix. This will ensure that the package is tested against this version in our CI/CD process.Use case
As we are constantly looking to update our package for compatibility with the latest versions of language, introducing Go 1.22 to our CI Matrix is an essential part of this process. As of now, we have been checking compatibility manually or relying on user feedback for any issues which isn't reliable or efficient.