Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Grep one-liners as CI tasks

phili.pe

Post reply on HN
Print view View original

21–30 of 36 posts

Re: Grep one-liners as CI tasks

#21

Post by stavros »

xorcist wrote: post #19

Wouldn't quick sanity checks like these make more sense in a git push hook? No reason to wait for the CI. There's also the risk of broken intermediary commits unless the CI check each and every commit in isolation.

Agreed. The usual way I do this is I set up a pre-commit (pre-commit.com) configuration that runs locally, and then again on CI. That way, you get all the benefits on CI, but can optimize for speed by installing pre-commit locally (and run either the exact same or a subset of checks).

Re: Grep one-liners as CI tasks

#22

Post by chucksmash »

darknavi wrote: post #15
zX41ZdbW wrote: post #10

Here is my favorite: https://github.com/ClickHouse/ClickHouse/blob/master/utils/c... "Too many exclamation marks"

I wonder how they picked three as too many. Why not two? > Three shall be the number thou shalt count, and the number of the counting shall be three. Four shalt thou not count, neither count thou two, excepting that thou then proceed to three. Five is right out.

`!!thing` is a fairly common JS idiom for "I have a truthy/falsy thing and I want true or false."

Re: Grep one-liners as CI tasks

#23

Post by rbonvall »

darknavi wrote: post #15
zX41ZdbW wrote: post #10

Here is my favorite: https://github.com/ClickHouse/ClickHouse/blob/master/utils/c... "Too many exclamation marks"

I wonder how they picked three as too many. Why not two? > Three shall be the number thou shalt count, and the number of the counting shall be three. Four shalt thou not count, neither count thou two, excepting that thou then proceed to three. Five is right out.

Maybe because of the use of the "double bang" pattern to convert a value to boolean:

    !!41 === true
    !!0  === false

Re: Grep one-liners as CI tasks

#25

Post by ljm »

zX41ZdbW wrote: post #10

Here is my favorite: https://github.com/ClickHouse/ClickHouse/blob/master/utils/c... "Too many exclamation marks"

I enjoy seeing a nice shell script. This one is easy to follow and is consistently formatted.

Re: Grep one-liners as CI tasks

#26

Post by irrational »

darknavi wrote: post #15
zX41ZdbW wrote: post #10

Here is my favorite: https://github.com/ClickHouse/ClickHouse/blob/master/utils/c... "Too many exclamation marks"

I wonder how they picked three as too many. Why not two? > Three shall be the number thou shalt count, and the number of the counting shall be three. Four shalt thou not count, neither count thou two, excepting that thou then proceed to three. Five is right out.

This is the obvious answer.

Re: Grep one-liners as CI tasks

#27

Post by accoil »

darknavi wrote: post #15
zX41ZdbW wrote: post #10

Here is my favorite: https://github.com/ClickHouse/ClickHouse/blob/master/utils/c... "Too many exclamation marks"

I wonder how they picked three as too many. Why not two? > Three shall be the number thou shalt count, and the number of the counting shall be three. Four shalt thou not count, neither count thou two, excepting that thou then proceed to three. Five is right out.

Two really does seem too many. I worry about these times when any passing coder can ni-gate at will.

Re: Grep one-liners as CI tasks

#28

Post by joatmon-snoo »

gravypod wrote: post #3

I think this is a great example of where build systems, that understand the need for testing, can help out. In a build system I use quite often (Bazel) you can express this as an `sh_test()` [0] which provides documentation about what you're attempting to do and provides you with a way to reproduce the failure locally. You don't have to push the code and wait for CI to fail to find out, or debug, this error. Extra fu…

Tests are a good way to assert an invariant that you expect of your codebase, but as with all things, resolving the error can get a bit tricky/frustrating.

The canonical example in my mind is any kind of autofix-able linter, where there's some kind of patch (or more nuanced autofix) that the linter can generate on-the-spot for you. With a sh_test construct (or any other test), you generally find yourself printing out some command that the user can run to fix things, which in a sufficiently large codebase can get really frustrating. (The worst offenders of this that I remember dealing with at Google were when generated code/artifacts had to be checked into the repo instead of getting being wired into the build system because and a large-scale change you were doing looked at one of them the wrong way...)

(My company - https://trunk.io - is actually building a universal linter as part of our product offering, and we already have a system to write custom linters with varying levels of sophistication that can plug into both your IDE and CI system!)

Re: Grep one-liners as CI tasks

#29

Post by vlovich123 »

joatmon-snoo wrote: post #28
gravypod wrote: post #3

I think this is a great example of where build systems, that understand the need for testing, can help out. In a build system I use quite often (Bazel) you can express this as an `sh_test()` [0] which provides documentation about what you're attempting to do and provides you with a way to reproduce the failure locally. You don't have to push the code and wait for CI to fail to find out, or debug, this error. Extra fu…

Tests are a good way to assert an invariant that you expect of your codebase, but as with all things, resolving the error can get a bit tricky/frustrating. The canonical example in my mind is any kind of autofix-able linter, where there's some kind of patch (or more nuanced autofix) that the linter can generate on-the-spot for you. With a sh_test construct (or any other test), you generally find yourself printing out…

The problem with automatic linting is that there’s no good answer. Either you just fail and ask the user to resubmit or you fix up the formatting on their behalf. If you do the latter, you’re likely also pushing to the review system meaning the code under review and your local version no longer match which causes problems when rebasing and whatnot. The secondary problem is that the lint tool chain running locally sometimes doesn’t version match what’s in CI which poses a set of problems too, although in practice I think that’s raised as a concern only by teams that don’t establish good hygiene of checking in the set of tools (maintenance of multiple platforms is real there though).

I’ve yet to see a good answer to this problem though as each approach has upsides/downsides and no one ever ends up happy in a large enough team. Good luck.

Re: Grep one-liners as CI tasks

#30

Post by hiptobecubic »

gravypod wrote: post #3

I think this is a great example of where build systems, that understand the need for testing, can help out. In a build system I use quite often (Bazel) you can express this as an `sh_test()` [0] which provides documentation about what you're attempting to do and provides you with a way to reproduce the failure locally. You don't have to push the code and wait for CI to fail to find out, or debug, this error. Extra fu…

I was really annoyed when I first started using bazel, but it really is just an excellent build system. All the things I thought I didn't like about it, I have come to like.
Post reply on HN