Hacker Newsnew | past | comments | ask | show | jobs | submit | felicianotech's commentslogin

Even if you're not interested in Tailscale or VPNs, I made this because I found out there's now a way to create AppIndicators in Go and I had to try out it. https://github.com/dawidd6/go-appindicator


I really like your point about third party documentation. I've written the "this is dumb" line before but that's usually on a forum not a doc.


Nice. Good step forward.


I'm curious to see how this plays out but happy it's happening.


The Blue Yeti better stick around. I love it so much. It only needs USB type-C. :)


Hey Drew, long time no see.

Good posts. I see your point and I don't disagree with it. It's been a clear trend though that more and more people are moving away from email though.

I think with some people starting to get overwhelmed with Slack, especialling software engineerings, perhaps email will trend back up again and this can be feasible.

Personally, my favorite thing about GitHub isn't any single feature. It's the social aspect that's developed around it for open-source projects.

GitLab, Bitbucket, will struggle to take over without the social aspect. Email has it, in it's own way I guess.


They took down the link for a little while but it's back.


disclaimer: Developer Evangelist at CircleCI

re: parsing test results

CircleCI has been doing this for years. Not only does CircleCI read and store JUnit formatted test metadata but provides a dashboard called "Insights" to show this data overtime.

A Doc on collecting this data can be found here: https://circleci.com/docs/2.0/collect-test-data/

re: Code coverage spam

Thank you! I've often felt this way but never seen anyone else mention this. For many code coverage tools, you can integrate them at the GitHub point, which then gives you that "code coverage spam" or you can integrate it with a CI provider. This can simply fail a build if coverage drops. You can always have a status badge that shows coverage % in the readme as well.


True. For "official" Docker Hub orgs, they typically have a tag policy. There still needs to be som trust there in whether or not they'd follow that.

The only way to ensure you get what you started with is to use a digest. Every Docker image has a digest and that's basically a UUID for that image. If they push over the tag with another release, the new image will have a different digest.

Using the image digest in your CircleCI config file (or wherever else) and you'll always get that exact image.


Predicting customer needs is part of making a good product. Especially in a space so focused on speed and iteration.

Slower build times? That definitely isn't the norm for most projects which have transitioned over. Have you had anyone look over your config with you yet?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: