5 ms·

This is an okay and mostly correct introduction for anyone who has never heard of CI, but lacks any sort of depth. The author sounds like he just discovered the

by marcv81 10y ago

This is an okay and mostly correct introduction for anyone who has never heard of CI, but lacks any sort of depth. The author sounds like he just discovered the concept and wants to share it, but lacks practical experience.

2T1Qka0rEiPr 10y ago
And yet is a blog post from a CI platform!
- marcv81 10y ago
  Yes, I realized after commenting. It's not a bad post, but I'm not sure why they tried their luck here.
  - Traubenfuchs 10y ago
    Hackernews provides a relevantly sized audience. "Roughly 2.6M views a day, 300K daily uniques, 3 to 3.5M monthly uniques. It depends on how you count, of course." And that was two years ago... https://news.ycombinator.com/item?id=9219581 https://news.ycombinator.com/item?id=9219581
    - marcv81 10y ago
      Yes, I suppose I am aware of their product now...
Traubenfuchs 10y ago
It's an advertisement for their CI software in the form of an informative blog post to hide that it is an ad so they can post it on websites like hacker news. The original poster is a cofounder of Semaphore.
- pc86 10y ago
  The domain is "semaphoreci.com" and the service is linked very early in the article, I don't think they're trying to hide anything. It's content marketing, just like 80% of the blog posts that end up here, except for Medium which seems to be exclusively marketing.
markoa 10y ago
Hi, author here. I do come from a team making a CI service, and it took us a lot of time to realize that it'd be useful to have a time-based hard limit for what's good enough. And for anything over that you're obliged to take action to make it better. E.g. one of our own builds took longer than 10mins at some point. You just assume that it's a function of size of the code and it's normal to rise over time. So my goal is to share that idea & why I think it matters, and get feedback. :)
- alkonaut 10y ago
  How is the hard limit enforced? By the CI tool as a failed build? It would be perfect if one could somehow keep the build quick using tools. A hard limit on a build might not be the best way. If the test is taking Limit minus one millisecond, and I add one new test that takes one millisecond, I break the build. But the culprit was really commit yesterday that added a test that takes 9 minutes. The worst thing one can do in CI is somehow flag the build as "not good enough" and point the blame the wrong way. A tool that treated test quality/perf like any other asset and fails builds based on time limits etc would be perfect. It's really hard to do that especially on shared CI servers because of fluctuating performance.
  - markoa 10y ago
    Yeah sorry for not being clear there, by hard limit I didn't mean that CI should fail the build. But that the number should be a fixed threshold for the team to optimize for. Thanks for your feedback.
- noxToken 10y ago
  If it's not a function of the size of the code, then what does build time map to? I understand that dependency management, effective testing, proper build configs, etc. also factor into that function. I also understand that size of the code does not have to be a linear scalar, but it seems that a constant hard limit is very arbitrary. I'm really not trying to crap on your decisions. I just want to know the rationale behind it. There are projects where everything is written in house with 10K lines of code. There are behemoths with 500k+ LoC and numerous dependencies. How does this factor into the decision?

by marcv81 10y ago

2T1Qka0rEiPr 10y ago

And yet is a blog post from a CI platform!

marcv81 10y ago
Yes, I realized after commenting. It's not a bad post, but I'm not sure why they tried their luck here.
- Traubenfuchs 10y ago
  Hackernews provides a relevantly sized audience. "Roughly 2.6M views a day, 300K daily uniques, 3 to 3.5M monthly uniques. It depends on how you count, of course." And that was two years ago... https://news.ycombinator.com/item?id=9219581 https://news.ycombinator.com/item?id=9219581
  - marcv81 10y ago
    Yes, I suppose I am aware of their product now...

Traubenfuchs 10y ago

It's an advertisement for their CI software in the form of an informative blog post to hide that it is an ad so they can post it on websites like hacker news. The original poster is a cofounder of Semaphore.

pc86 10y ago
The domain is "semaphoreci.com" and the service is linked very early in the article, I don't think they're trying to hide anything. It's content marketing, just like 80% of the blog posts that end up here, except for Medium which seems to be exclusively marketing.

markoa 10y ago

Hi, author here. I do come from a team making a CI service, and it took us a lot of time to realize that it'd be useful to have a time-based hard limit for what's good enough. And for anything over that you're obliged to take action to make it better. E.g. one of our own builds took longer than 10mins at some point. You just assume that it's a function of size of the code and it's normal to rise over time. So my goal is to share that idea & why I think it matters, and get feedback. :)

alkonaut 10y ago
How is the hard limit enforced? By the CI tool as a failed build? It would be perfect if one could somehow keep the build quick using tools. A hard limit on a build might not be the best way. If the test is taking Limit minus one millisecond, and I add one new test that takes one millisecond, I break the build. But the culprit was really commit yesterday that added a test that takes 9 minutes. The worst thing one can do in CI is somehow flag the build as "not good enough" and point the blame the wrong way. A tool that treated test quality/perf like any other asset and fails builds based on time limits etc would be perfect. It's really hard to do that especially on shared CI servers because of fluctuating performance.
- markoa 10y ago
  Yeah sorry for not being clear there, by hard limit I didn't mean that CI should fail the build. But that the number should be a fixed threshold for the team to optimize for. Thanks for your feedback.
noxToken 10y ago
If it's not a function of the size of the code, then what does build time map to? I understand that dependency management, effective testing, proper build configs, etc. also factor into that function. I also understand that size of the code does not have to be a linear scalar, but it seems that a constant hard limit is very arbitrary. I'm really not trying to crap on your decisions. I just want to know the rationale behind it. There are projects where everything is written in house with 10K lines of code. There are behemoths with 500k+ LoC and numerous dependencies. How does this factor into the decision?