testify
testify copied to clipboard
fix: ci for go 1.19 and standard generated header
Summary
Fix continuous integration with go 1.19 and use the standard generated header for golang files.
Changes
- Use the standard generated header golang files.
- Fix ci so it works with go 1.19, only checking format and generate for this.
- Centralise ci in the workflow file.
- Run ci on the supported versions of golang 1.18 and 1.19.
- Run go mod tidy on _codegen module.
Motivation
Allows tools which comply with the recommended header to correctly detect the files are generated.
Allow users on go 1.19+ to contribute without having to install old versions of golang.
Centralise the ci in the github workflow file so its easier to maintain.
Hi, @stevenh ! I've got the same problem with CI for different go versions simultaneously. Look like code gets generated code in different ways with space characters, so it cannot fit all versions. Or may be checks should be different for different versions. https://github.com/stretchr/testify/pull/1252
Yer my take as just to go with the latest formatting 1.19+, and skip tests on earlier versions.
Too many unrelated changes in a single MR. This is too much work to review and accept/reject individual changes.
Please resubmit changes in separate MR well contained if they still apply.
About Centralise the ci in the github workflow file so its easier to maintain., I disagree because it make harder to debug the CI build steps on a developer's machine. You should at least explain why you think it's easier to maintain.
Have split this up into the 2 separate PRs with the two key change sets
- https://github.com/stretchr/testify/pull/1458
- https://github.com/stretchr/testify/pull/1460
For the workflow change if you want to test locally I would recommend act for that. However as the flows themselves are very basic, they are unlikely to need any debugging.
Two clean up steps:
go mod tidy- Only needed if dependencies are changed, something developers following best practices are used to runninggo generate ./...- Only needed if templates are changes, so something people should know to run.
Two validation steps, which are both handled by editors so should be no-op for the developer:
gofmt -w .go vet ./...
Hope this helps.
Looks like the standard headers have already been done, didn't spot that as this was still pending, so just workflow improvements left.