6 ms·

A pre-commit hook in your revision control system can block checking in code that doesn't pass a lint check. That would reduce your CI build failures.

by asaph 8y ago

swsieber 8y ago
And you can generally set that hook up to be installed automatically through whatever build tool runs your stuff, like gradle for java stuff, or yarn/npm for js/ts stuff. And if it comes down to it, devs can still skip it if gets into a broken state for whatever reason. Attention to detail in developer tooling can reduce the amount of details developers have to pay attention to.
- SketchySeaBeast 8y ago
  > And if it comes down to it, devs can still skip it if gets into a broken state for whatever reason. In my experience, that is a state that would never end. It would work for a month, then break and would never get fixed again, and would fall into abyss of normalized deviance.
  - swsieber 8y ago
    Ah, that's too bad. We have one managed by yarn where I work, and it's only broken on me once. I occasionally get asked for help (maybe 1/3years/person) when somebody gets a cryptic error (well, not that cryptic, but they ask me because it's git related) from it, and rerunning the hook installation task has always fixed it.
bmj 8y ago
This assumes that we are currently using a sane system. But your point is well-taken.
ninkendo 8y ago
I'm not entirely sure I want to sit through a 10 minute linting process every time I do a quick `git add -A && git commit -m WIP` locally. Why does it need to be a pre-commit hook instead of a simple PR check? PR checks obviously need to be done anyway.
- dean177 8y ago
  10 minutes? A strategy I have used is: - only lint the files that have changed - only apply lint rules that can be auto-fixed This usually takes less than a second (short enough that you can't really tell the difference) and the developer doesn't have to do anything .
  - ninkendo 8y ago
    > 10 minutes? Yes. I work in a codebase that's 30GB checked out. It takes a long time to run our automated checks. That's why they happen on the server, when I make a pull request. The upshot is the same: it doesn't go to master until checks pass. But who gives a shit about what I'm committing locally? I reserve the right to save my work even if things aren't compiling. You (my teammate) won't see it anyway, it's all locally on my machine. Why do you care?
- purple_ducks 8y ago
  Your local pre-commit hooks are separate to your remote pre-commit hooks.
  - ninkendo 8y ago
    There's no such thing as a remote pre-commit hook. Do you mean a pre-push hook? That's a different story, but even then what you really want is to just deny access to shared branches, except to your CI system, which will run your checks before allowing you to merge. GitHub/GitLab/BitBucket/etc all have this kind of system, it's not new or interesting.
- asaph 8y ago
  git commit -m WIP I hope you're rebasing that terrible commit message away before pushing this remotely.
  - james_s_tayler 8y ago
    I hope the pre-commit hook validates the commit message follows the correct format which links the work to the correct ticket number and if you left off the ticket number inserts it for you based off the branch name etc.
catdog 8y ago
> A pre-commit hook in your revision control system can block checking in code that doesn't pass a lint check. That would reduce your CI build failures. Omg don't use commit hooks for that, just make it as easy to use as possible for the developer (e.g. integration into the editor/IDE). For verifying such things CI is the way to go. Simply never commit directly to your development branch, use feature branches and pull/merge requests. 1. Someone else (ideally the most experienced Person(s) available but even any second pair of eyes is better than nothing) can and should review the code 2. Hook it up to the CI, the CI should merge it into the target branch locally and do its thing, as long as a pull request fails the CI it will not be merged Software (e.g. Gitlab) to implement such a workflow is freely available, you just have to set it up but that's worth the effort.

A pre-commit hook in your revision control system can block checking in code that doesn't pass a lint check. That would reduce your CI build failures.

by asaph 8y ago

A pre-commit hook in your revision control system can block checking in code that doesn't pass a lint check. That would reduce your CI build failures.

swsieber 8y ago

And you can generally set that hook up to be installed automatically through whatever build tool runs your stuff, like gradle for java stuff, or yarn/npm for js/ts stuff. And if it comes down to it, devs can still skip it if gets into a broken state for whatever reason. Attention to detail in developer tooling can reduce the amount of details developers have to pay attention to.

SketchySeaBeast 8y ago
> And if it comes down to it, devs can still skip it if gets into a broken state for whatever reason. In my experience, that is a state that would never end. It would work for a month, then break and would never get fixed again, and would fall into abyss of normalized deviance.
- swsieber 8y ago
  Ah, that's too bad. We have one managed by yarn where I work, and it's only broken on me once. I occasionally get asked for help (maybe 1/3years/person) when somebody gets a cryptic error (well, not that cryptic, but they ask me because it's git related) from it, and rerunning the hook installation task has always fixed it.

bmj 8y ago

This assumes that we are currently using a sane system. But your point is well-taken.

ninkendo 8y ago

I'm not entirely sure I want to sit through a 10 minute linting process every time I do a quick `git add -A && git commit -m WIP` locally. Why does it need to be a pre-commit hook instead of a simple PR check? PR checks obviously need to be done anyway.

dean177 8y ago
10 minutes? A strategy I have used is: - only lint the files that have changed - only apply lint rules that can be auto-fixed This usually takes less than a second (short enough that you can't really tell the difference) and the developer doesn't have to do anything .
- ninkendo 8y ago
  > 10 minutes? Yes. I work in a codebase that's 30GB checked out. It takes a long time to run our automated checks. That's why they happen on the server, when I make a pull request. The upshot is the same: it doesn't go to master until checks pass. But who gives a shit about what I'm committing locally? I reserve the right to save my work even if things aren't compiling. You (my teammate) won't see it anyway, it's all locally on my machine. Why do you care?
purple_ducks 8y ago
Your local pre-commit hooks are separate to your remote pre-commit hooks.
- ninkendo 8y ago
  There's no such thing as a remote pre-commit hook. Do you mean a pre-push hook? That's a different story, but even then what you really want is to just deny access to shared branches, except to your CI system, which will run your checks before allowing you to merge. GitHub/GitLab/BitBucket/etc all have this kind of system, it's not new or interesting.
asaph 8y ago
git commit -m WIP I hope you're rebasing that terrible commit message away before pushing this remotely.
- james_s_tayler 8y ago
  I hope the pre-commit hook validates the commit message follows the correct format which links the work to the correct ticket number and if you left off the ticket number inserts it for you based off the branch name etc.

catdog 8y ago

> A pre-commit hook in your revision control system can block checking in code that doesn't pass a lint check. That would reduce your CI build failures. Omg don't use commit hooks for that, just make it as easy to use as possible for the developer (e.g. integration into the editor/IDE). For verifying such things CI is the way to go. Simply never commit directly to your development branch, use feature branches and pull/merge requests. 1. Someone else (ideally the most experienced Person(s) available but even any second pair of eyes is better than nothing) can and should review the code 2. Hook it up to the CI, the CI should merge it into the target branch locally and do its thing, as long as a pull request fails the CI it will not be merged Software (e.g. Gitlab) to implement such a workflow is freely available, you just have to set it up but that's worth the effort.