11–20 of 36 posts
Disclaimer: I work on trunk :)
Wouldn't this example do the incorrect thing in the event of a grep error (exit code 2)?
Consider what would happen if your unit test framework couldn’t compile the test files and failed with an error. Isn’t that also a test failure?
Wouldn't this example do the incorrect thing in the event of a grep error (exit code 2)?
(grep -q notwanted /hay/stack ; test $? == 1) && echo "No violations found"
Here is my favorite: https://github.com/ClickHouse/ClickHouse/blob/master/utils/c... "Too many exclamation marks"
> 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.
Wouldn't this example do the incorrect thing in the event of a grep error (exit code 2)?
Depends on what you mean by wrong. If the tests can’t run successfully because they detect an error or because they have an error, it still is a valuable signal to raise to the developer. Consider what would happen if your unit test framework couldn’t compile the test files and failed with an error. Isn’t that also a test failure?
To address this: many CI pipelines allow you to specify which exot codes to succeed and fail on per job, or if it doesn't the one liner will need some boolean logic to check the exit code.
grep and other shell tool one-liners also make excellent kubernetes liveness checks. I have some kubernetes daemonsets that don't do anything other than assert that things on the node are as they should, via grep exit status.
For example you could configure a Docker Compose health check to curl an endpoint for a 200 in production but in development override the health check command to call /bin/true so you don't get log spam in development from your health check while ensuring the health check still passes since /bin/true is an extremely minimal command that returns an exit code of 0. This can be controlled by a single environment variable too, no changes needed to your docker-compose.yml file.
I covered this pattern in a recent DockerCon talk at https://nickjanetakis.com/blog/best-practices-around-product....
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.
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.
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.