4 ms·

The purpose of continuous integration is to fail

49 points by Norfair 7mo ago

jgbuddy 7mo ago
This is of course true as a blanket "gotcha" headline- although I wouldn't call a failed test the CI itself failing. A real failure would be a false positive, a pass where there wasn't coverage, or a failure when there was no breaking change. Covering all of these edge cases can become as tiresome as maintaining the application in the first place (of course this is a generalization)
- chriswarbo 7mo ago
  > a pass where there wasn't coverage I always feel obliged to point out that we can have 100% coverage without making a single assertion (beware Goodhart's law)
  - n2d4 7mo ago
    True, but you can't have complete tests without 100% coverage. It's a necessary, but not a sufficient condition; as long as it doesn't become the sole goal, it's still a useful metric.
- SAI_Peregrinus 7mo ago
  100% coverage is an EXPTIME problem.
chriswarbo 7mo ago
I agree. The same can be said for testing too: their main purpose is to find mistakes (with secondary benefits of documenting, etc.). Whenever I see my tests fail, I'm happy that they caught a problem in my understanding (manifested either as a bug in my implementation, or a bug in my test statement).
- cogman10 7mo ago
  This ultimately is what shapes my view of what a good test is vs a bad test. An issue I have with a lot of unit tests is they are too strongly coupled to the implementation. What that means is any change to the implementation ultimately means you have to change tests. IMO, good tests are relatively immutable. You should be able to have multiple valid implementations. You should add new tests to describe the new functionality of that implementation, however, the old tests should remain relatively untouched. If it turns out that a single change to an implementation requires you to change and update 20 tests, those are bad tests. What I want as a dev is to immediately think "I must have broken something" when a test fails, not "I need to go fix 20 tests". For example, let's say you have a method which sorts data. A bad test will check "did you call this `swap` function 5 times". A good test will say "I gave the method this unsorted data set, is the data set sorted?". Heck, a good test can even say something like "was this large data set sorted in under x time". That's more tricky to do well, but still a better test than the "did you call swap the right number of times" or even worse "Did you invoke this sequence of swap calls".
  - vova_hn2 7mo ago
    > IMO, good tests are relatively immutable. You should be able to have multiple valid implementations. You should add new tests to describe the new functionality of that implementation, however, the old tests should remain relatively untouched. Taken to extreme this would mean getting rid of unit tests altogether in favor of functional and/or end-to-end testing. Which is... a strategy. I don't know if it is a good or bad strategy, but I can see it being viable for some projects.
    - cogman10 7mo ago
      If you can't tell, I actually think functional tests have a lot more value than most unit tests :) Kent Dodd agrees with me. [1] This isn't to say I see no value in unit tests, just that they should tend towards describing the function of the code under test, not the implementation. [1] https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications https://kentcdodds.com/blog/the-testing-trophy-and-testing-c...
ralferoo 7mo ago
The premise of the article has some weight, but the final conclusion with the suggestion to change the icons seems completely crazy. Green meaning "to the best of our knowledge, everything is good with the software" is well understood. Using green to mean "we know that this doesn't work at all" is incredibly poor UI (EDITED from "beyond idiotic" due to feedback, my bad). And whilst flaky tests are the most problematic for a CI system, it's because they often work (and usually, from my experience most flaky tests are because they are modelling situations that don't usually happen in production) and so are often potentially viable builds for deployment with a caveat. If anything, they should be marked orange if they are tests that are known to be problematic.
- chrisweekly 7mo ago
  Good insights but I'd suggest "beyond idiotic" -> "misleading | poor UX" (I agree it's a terrible choice, but civility matters, and strengthens your case.)
  - ralferoo 7mo ago
    Fair point, updated my wording.
- Norfair 7mo ago
  Hey, author here: I completely agree, that's why I also haven't used those strange colours for https://nix-ci.com https://nix-ci.com. I just thought they would make for a cool visual representation of the point of the blog post.
9rx 7mo ago
> When it passes, it's just overhead: the same outcome you'd get without CI. The outcome still isn't the same. CI, even when everything passes, enables other developers to build on top of your partially-built work as it becomes available. This is the real purpose of CI. Test automation is necessary, but only to keep things sane amid you continually throwing in fractionally-complete work.
- cestith 7mo ago
  It also allows for much better record keeping than just spinning up new versions in production without the pipeline.
1970-01-01 7mo ago
Oversimplified click bait. The purpose never changed from catching bad bugs before it was sent to prod. The goal of CI is to prevent the resulting problems from doing damage and requiring emergency repairs.
- bilkow 7mo ago
  I don't really understand the point you're trying to make, I don't see anywhere in the post nor the title claiming the purpose changed and the title is directly related to the content. In fact, it seems like you are just agreeing with the post. I think people can get frustrated at CI when it fails, so they're explaining that that's the whole purpose of it and why it's is a actually good thing. I would personally actually frame it slightly different than the author. Non-flaky CI errors: your code failed CI. Flaky CI errors: CI failed. Just to be clear, that's more precise but would never catch on because people would simplify "your code failed CI" to "CI failed" over time, but I don't thing that changes it from being an interesting way to frame.
  - viktorianer 7mo ago
    [flagged]
zelos 7mo ago
> Whenever a CI run fails, we can re-run it. If it passes the second time, we are sure it was flaky. Or you have a concurrency issue in your production code?
- cestith 7mo ago
  It's possibly something else nondeterministic, which may be even more subtle from an external look than a race condition. That should be rare, but it’s been known to happen.
- fxwin 7mo ago
  I thought that line was kind of funny: When a CI run fails, you don't rerun it and wait for the result, you rerun it and check why the original run failed in the meantime. Is it flaky? Is it a pipeline issue? Connectivity issue? Did some Key expire? If you just rerun and don't go to find out what exactly caused CI to fail, you end up at the author's conclusion: > (but it could also just have been flaky again).
- Norfair 7mo ago
  Then the test is still flaky. If there's a bug you want the test to consistently fail, not just sometimes.
  - 9rx 7mo ago
    The parent is talking about when the implementation is flaky, not the test. When you go to fix the problem under that scenario there is no reason for you to modify the test. The test is fine.
    - rkangel 7mo ago
      What you're describing is the every day reality but what you WANT is that if your implementation has a race condition, then you want a test that 100% of the time detects that there is a race condition (rather than 1% of the time).
      - 7mo ago
globular-toast 7mo ago
I think this can be generalised into saying that the purpose of tests is to fail. I've seen far too many tests that are written to pass. You need to write tests to fail.
genie3io 7mo ago
[dead]
mihir_kanzariya 7mo ago
[flagged]
- flowerbreeze 7mo ago
  The "just retry" approach is truly bothersome. I think it is at least partly an organizational issue, because it happens far more often when QA is a separate team.
- ant6n 7mo ago
  If a build fails 10% of the time, it actually takes 100x longer before to fail for the 10%x10%x10% case.
- jbstack 7mo ago
  I don't understand this at all. Why not just skip CI altogether if you're not interested in the results?
deathanatos 7mo ago
> One dreaded and very common situation is when a failing CI run can be made to pass by simply re-running it. We call this flaky CI. > Flaky CI is nasty because it means that a CI failure no longer reliably indicates that a mistake was caught. And it is doubly nasty because it is unfixable (in theory); sometimes machines just explode. > Luckily flakiness can be detected: Whenever a CI run fails, we can re-run it. If it passes the second time, we are sure it was flaky. One of the specialties that I have (unwillingly!) specialized in at my current company is CI flakes. Nearly all flakes, well over 90% of them, are not "unfixable", nor are they even really some boogy man unreliable thing that can't be understood. The single biggest change I think we made that helped was having our CI system record the order¹ in which tests are run. Rerunning the tests, in the same order, makes most flakes instantly reproduce locally. Probably the next biggest reproducer is "what was the time the test ran?" and/or running it in UTC. But once you get from "it's flakey" (and fails "seeming" "at" "random") to "it fails 100% of the time on my laptop when run this way" then it becomes easier to debug, b/c you can re-run it, attach a debugger, etc. Database sort issues (SQL is not deterministically ordered unless you ORDER BY), issues with database IDs (e.g., test expects row ID 3, usually gets row ID 3, but some other test has bumped us to row ID 4²), timezones — those are probably the biggest categories of "flakes". While I know what people express with "flake", "flake" as a word is usually "failure mode I don't understand". (Excluding truly transitory issues like a network failure interfering with a docker image pull, or something.) (¹there are a lot of reasons people don't have deterministically ordered CI runs. Parallelism, for example. Our order is deterministic, b/c we made a value judgement that random orderings introduce too much chaos. But we still shard our tests across multiple VMs, and that sharding introduces its own changes to the order, as sometimes we rebalance one test to a different shard as devs add or remove tests.) ²this isn't usually because the ID is hardcoded, it is usually b/c, in the test, someone is doing `assert Foo.id == Bar.id`, unknowningly. (The code is usually not straight-forward about what the ID is an ID to.) I call this ID type confusion, and it's basically weakly-typed IDs in langs where all IDs are just some i32 type. FooId and BarId types would be better, and if I had a real type system in my work's lang of choice…
- win311fwg 7mo ago
  > those are probably the biggest categories of "flakes". Interesting. In my experience, it is always either a concurrency issue in the program under test or PBTs finding some extreme edge case that was never visited before.
IshKebab 7mo ago
This is stupidly obvious but you'd be surprised how many people have the attitude that competent developers should have tested their code manually before making PRs so you shouldn't need CI.
lgunsch 7mo ago
Some of the other practices of CI are also important. Not explicitly mentioned by the article, but perhaps implied. CI is a lot more than just running tests on pull request. It's a whole suite of practices enabling teams to perform and ship better. Some of which include keeping branches short lived by merging back to main early and often. Keeping code ready for deployment at any time by using strategies like feature switches. This keeps the cost of shipping a feature as low as possible, avoiding issues like spending lots of time rebasing and merging long lived feature branches.
jquaint 7mo ago
https://github.com/srid/nixci https://github.com/srid/nixci Is this the project or is this a completely different Nix based CI/CD tool? I can't find a Github or anything on the website.
- Norfair 7mo ago
  Author here: NixCI (https://nix-ci.com https://nix-ci.com) is not open-source. https://github.com/srid/nixci https://github.com/srid/nixci has been replaced by om ci: https://omnix.page/om/ci.html https://omnix.page/om/ci.html
stego-tech 7mo ago
I’m one of today’s lucky 10k, because this judo-threw me with how I (didn’t) understand CI/CD. My experience with it has largely been a cumbersome add-on to existing processes that are often incredibly fragile and impossible to amend; turns out, that’s kind of the point. Understanding that it’s the equivalent of doing rocket tests on kit you expect to fail and using that to build better rockets suddenly makes its value far more recognizable, at least to my eyes. Solid writeup. Definitely keeping in my personal notes.

49 points by Norfair 7mo ago

This is of course true as a blanket "gotcha" headline- although I wouldn't call a failed test the CI itself failing. A real failure would be a false positive, a pass where there wasn't coverage, or a failure when there was no breaking change. Covering all of these edge cases can become as tiresome as maintaining the application in the first place (of course this is a generalization)

chriswarbo 7mo ago
> a pass where there wasn't coverage I always feel obliged to point out that we can have 100% coverage without making a single assertion (beware Goodhart's law)
- n2d4 7mo ago
  True, but you can't have complete tests without 100% coverage. It's a necessary, but not a sufficient condition; as long as it doesn't become the sole goal, it's still a useful metric.
SAI_Peregrinus 7mo ago
100% coverage is an EXPTIME problem.

chriswarbo 7mo ago

I agree. The same can be said for testing too: their main purpose is to find mistakes (with secondary benefits of documenting, etc.). Whenever I see my tests fail, I'm happy that they caught a problem in my understanding (manifested either as a bug in my implementation, or a bug in my test statement).

cogman10 7mo ago
This ultimately is what shapes my view of what a good test is vs a bad test. An issue I have with a lot of unit tests is they are too strongly coupled to the implementation. What that means is any change to the implementation ultimately means you have to change tests. IMO, good tests are relatively immutable. You should be able to have multiple valid implementations. You should add new tests to describe the new functionality of that implementation, however, the old tests should remain relatively untouched. If it turns out that a single change to an implementation requires you to change and update 20 tests, those are bad tests. What I want as a dev is to immediately think "I must have broken something" when a test fails, not "I need to go fix 20 tests". For example, let's say you have a method which sorts data. A bad test will check "did you call this `swap` function 5 times". A good test will say "I gave the method this unsorted data set, is the data set sorted?". Heck, a good test can even say something like "was this large data set sorted in under x time". That's more tricky to do well, but still a better test than the "did you call swap the right number of times" or even worse "Did you invoke this sequence of swap calls".
- vova_hn2 7mo ago
  > IMO, good tests are relatively immutable. You should be able to have multiple valid implementations. You should add new tests to describe the new functionality of that implementation, however, the old tests should remain relatively untouched. Taken to extreme this would mean getting rid of unit tests altogether in favor of functional and/or end-to-end testing. Which is... a strategy. I don't know if it is a good or bad strategy, but I can see it being viable for some projects.
  - cogman10 7mo ago
    If you can't tell, I actually think functional tests have a lot more value than most unit tests :) Kent Dodd agrees with me. [1] This isn't to say I see no value in unit tests, just that they should tend towards describing the function of the code under test, not the implementation. [1] https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications https://kentcdodds.com/blog/the-testing-trophy-and-testing-c...

ralferoo 7mo ago

The premise of the article has some weight, but the final conclusion with the suggestion to change the icons seems completely crazy. Green meaning "to the best of our knowledge, everything is good with the software" is well understood. Using green to mean "we know that this doesn't work at all" is incredibly poor UI (EDITED from "beyond idiotic" due to feedback, my bad). And whilst flaky tests are the most problematic for a CI system, it's because they often work (and usually, from my experience most flaky tests are because they are modelling situations that don't usually happen in production) and so are often potentially viable builds for deployment with a caveat. If anything, they should be marked orange if they are tests that are known to be problematic.

chrisweekly 7mo ago
Good insights but I'd suggest "beyond idiotic" -> "misleading | poor UX" (I agree it's a terrible choice, but civility matters, and strengthens your case.)
- ralferoo 7mo ago
  Fair point, updated my wording.
Norfair 7mo ago
Hey, author here: I completely agree, that's why I also haven't used those strange colours for https://nix-ci.com https://nix-ci.com. I just thought they would make for a cool visual representation of the point of the blog post.

9rx 7mo ago

> When it passes, it's just overhead: the same outcome you'd get without CI. The outcome still isn't the same. CI, even when everything passes, enables other developers to build on top of your partially-built work as it becomes available. This is the real purpose of CI. Test automation is necessary, but only to keep things sane amid you continually throwing in fractionally-complete work.

cestith 7mo ago
It also allows for much better record keeping than just spinning up new versions in production without the pipeline.

1970-01-01 7mo ago

Oversimplified click bait. The purpose never changed from catching bad bugs before it was sent to prod. The goal of CI is to prevent the resulting problems from doing damage and requiring emergency repairs.

bilkow 7mo ago
I don't really understand the point you're trying to make, I don't see anywhere in the post nor the title claiming the purpose changed and the title is directly related to the content. In fact, it seems like you are just agreeing with the post. I think people can get frustrated at CI when it fails, so they're explaining that that's the whole purpose of it and why it's is a actually good thing. I would personally actually frame it slightly different than the author. Non-flaky CI errors: your code failed CI. Flaky CI errors: CI failed. Just to be clear, that's more precise but would never catch on because people would simplify "your code failed CI" to "CI failed" over time, but I don't thing that changes it from being an interesting way to frame.
- viktorianer 7mo ago
  [flagged]

zelos 7mo ago

> Whenever a CI run fails, we can re-run it. If it passes the second time, we are sure it was flaky. Or you have a concurrency issue in your production code?

cestith 7mo ago
It's possibly something else nondeterministic, which may be even more subtle from an external look than a race condition. That should be rare, but it’s been known to happen.
fxwin 7mo ago
I thought that line was kind of funny: When a CI run fails, you don't rerun it and wait for the result, you rerun it and check why the original run failed in the meantime. Is it flaky? Is it a pipeline issue? Connectivity issue? Did some Key expire? If you just rerun and don't go to find out what exactly caused CI to fail, you end up at the author's conclusion: > (but it could also just have been flaky again).
Norfair 7mo ago
Then the test is still flaky. If there's a bug you want the test to consistently fail, not just sometimes.
- 9rx 7mo ago
  The parent is talking about when the implementation is flaky, not the test. When you go to fix the problem under that scenario there is no reason for you to modify the test. The test is fine.
  - rkangel 7mo ago
    What you're describing is the every day reality but what you WANT is that if your implementation has a race condition, then you want a test that 100% of the time detects that there is a race condition (rather than 1% of the time).
    - 7mo ago

globular-toast 7mo ago

I think this can be generalised into saying that the purpose of tests is to fail. I've seen far too many tests that are written to pass. You need to write tests to fail.

genie3io 7mo ago

[dead]

mihir_kanzariya 7mo ago

[flagged]

flowerbreeze 7mo ago
The "just retry" approach is truly bothersome. I think it is at least partly an organizational issue, because it happens far more often when QA is a separate team.
ant6n 7mo ago
If a build fails 10% of the time, it actually takes 100x longer before to fail for the 10%x10%x10% case.
jbstack 7mo ago
I don't understand this at all. Why not just skip CI altogether if you're not interested in the results?

deathanatos 7mo ago

> One dreaded and very common situation is when a failing CI run can be made to pass by simply re-running it. We call this flaky CI. > Flaky CI is nasty because it means that a CI failure no longer reliably indicates that a mistake was caught. And it is doubly nasty because it is unfixable (in theory); sometimes machines just explode. > Luckily flakiness can be detected: Whenever a CI run fails, we can re-run it. If it passes the second time, we are sure it was flaky. One of the specialties that I have (unwillingly!) specialized in at my current company is CI flakes. Nearly all flakes, well over 90% of them, are not "unfixable", nor are they even really some boogy man unreliable thing that can't be understood. The single biggest change I think we made that helped was having our CI system record the order¹ in which tests are run. Rerunning the tests, in the same order, makes most flakes instantly reproduce locally. Probably the next biggest reproducer is "what was the time the test ran?" and/or running it in UTC. But once you get from "it's flakey" (and fails "seeming" "at" "random") to "it fails 100% of the time on my laptop when run this way" then it becomes easier to debug, b/c you can re-run it, attach a debugger, etc. Database sort issues (SQL is not deterministically ordered unless you ORDER BY), issues with database IDs (e.g., test expects row ID 3, usually gets row ID 3, but some other test has bumped us to row ID 4²), timezones — those are probably the biggest categories of "flakes". While I know what people express with "flake", "flake" as a word is usually "failure mode I don't understand". (Excluding truly transitory issues like a network failure interfering with a docker image pull, or something.) (¹there are a lot of reasons people don't have deterministically ordered CI runs. Parallelism, for example. Our order is deterministic, b/c we made a value judgement that random orderings introduce too much chaos. But we still shard our tests across multiple VMs, and that sharding introduces its own changes to the order, as sometimes we rebalance one test to a different shard as devs add or remove tests.) ²this isn't usually because the ID is hardcoded, it is usually b/c, in the test, someone is doing `assert Foo.id == Bar.id`, unknowningly. (The code is usually not straight-forward about what the ID is an ID to.) I call this ID type confusion, and it's basically weakly-typed IDs in langs where all IDs are just some i32 type. FooId and BarId types would be better, and if I had a real type system in my work's lang of choice…

win311fwg 7mo ago
> those are probably the biggest categories of "flakes". Interesting. In my experience, it is always either a concurrency issue in the program under test or PBTs finding some extreme edge case that was never visited before.

IshKebab 7mo ago

This is stupidly obvious but you'd be surprised how many people have the attitude that competent developers should have tested their code manually before making PRs so you shouldn't need CI.

lgunsch 7mo ago

Some of the other practices of CI are also important. Not explicitly mentioned by the article, but perhaps implied. CI is a lot more than just running tests on pull request. It's a whole suite of practices enabling teams to perform and ship better. Some of which include keeping branches short lived by merging back to main early and often. Keeping code ready for deployment at any time by using strategies like feature switches. This keeps the cost of shipping a feature as low as possible, avoiding issues like spending lots of time rebasing and merging long lived feature branches.

jquaint 7mo ago

https://github.com/srid/nixci https://github.com/srid/nixci Is this the project or is this a completely different Nix based CI/CD tool? I can't find a Github or anything on the website.

Norfair 7mo ago
Author here: NixCI (https://nix-ci.com https://nix-ci.com) is not open-source. https://github.com/srid/nixci https://github.com/srid/nixci has been replaced by om ci: https://omnix.page/om/ci.html https://omnix.page/om/ci.html

stego-tech 7mo ago

I’m one of today’s lucky 10k, because this judo-threw me with how I (didn’t) understand CI/CD. My experience with it has largely been a cumbersome add-on to existing processes that are often incredibly fragile and impossible to amend; turns out, that’s kind of the point. Understanding that it’s the equivalent of doing rocket tests on kit you expect to fail and using that to build better rockets suddenly makes its value far more recognizable, at least to my eyes. Solid writeup. Definitely keeping in my personal notes.