Proper pre-commit checks, tests, and linting #19

Closed
opened 2021-08-02 04:35:07 +00:00 by roxxers · 3 comments

I think we need to be really anal on code quailty for Go. Pre-commit hooks for anyone directly commiting to the project that run tests, linting and code quality (go-fmt, staticcheck, golangci-lint (uses go-critic), golint). Then using those tests and linters on drone (which isn't setup on the new coopcloud site rn???) for builds and that can run on PRs.

I think we need to be really anal on code quailty for Go. Pre-commit hooks for anyone directly commiting to the project that run tests, linting and code quality (go-fmt, staticcheck, golangci-lint (uses go-critic), golint). Then using those tests and linters on drone (which isn't setup on the new coopcloud site rn???) for builds and that can run on PRs.
roxxers added the
meta
contributing
build
labels 2021-08-02 04:35:07 +00:00
Owner

I think we need to be really anal on code quailty for Go.

You forgot The Reason Why again 🙃 For change log stuff or?

I'm up for some level of rigour but FYI there is no precedent for that in any Autonomic project and idk if you meant it this way but setting up pre-commit scripts in a repo for each new contributor is a barrier to contributing imho.

Having build failure notifications for abra and people picking up responsibility for fixing stuff worked for us so far. Having the CI in a state of migration right now is not really helping I guess.

> I think we need to be really anal on code quailty for Go. You forgot The Reason Why again 🙃 For change log stuff or? I'm up for some level of rigour but FYI there is no precedent for that in any Autonomic project and idk if you meant it this way but setting up pre-commit scripts in a repo for each new contributor is a barrier to contributing imho. Having build failure notifications for `abra` and people picking up responsibility for fixing stuff worked for us so far. Having the CI in a state of migration right now is not really helping I guess.
Author

I'm up for some level of rigour but FYI there is no precedent for that in any Autonomic project and idk if you meant it this way but setting up pre-commit scripts in a repo for each new contributor is a barrier to contributing imho.

by direct access I mean any autonomic member really. No one who would use PRs to commit to.

I care this much because it seems people are not using the same tooling as me and this is creating errors when their systems are not testing the code at the same level my PC is. I don't think it is really a big barrier to copy paste some lines into a file that run tests when you commit to main. Esp with the fact that on the previous repo our dev build wasj just main. So id assume our dev version on this project will be the latest commit's build outputs. Which should not be broken.

You forgot The Reason Why again 🙃 For change log stuff or?

Not breaking main with uncompilable code or reducing te code quality where it would be needed to go back an do large refactors cause those are annoying and painful and I'd rather we maintain a level of quality in that way.

> I'm up for some level of rigour but FYI there is no precedent for that in any Autonomic project and idk if you meant it this way but setting up pre-commit scripts in a repo for each new contributor is a barrier to contributing imho. by direct access I mean any autonomic member really. No one who would use PRs to commit to. I care this much because it seems people are not using the same tooling as me and this is creating errors when their systems are not testing the code at the same level my PC is. I don't think it is really a big barrier to copy paste some lines into a file that run tests when you commit to main. Esp with the fact that on the previous repo our dev build wasj just main. So id assume our dev version on this project will be the latest commit's build outputs. Which should not be broken. > You forgot The Reason Why again 🙃 For change log stuff or? Not breaking main with uncompilable code or reducing te code quality where it would be needed to go back an do large refactors cause those are annoying and painful and I'd rather we maintain a level of quality in that way.
Owner
> https://git.coopcloud.tech/coop-cloud/organising/issues/126
Sign in to join this conversation.
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: toolshed/abra#19
No description provided.