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
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.
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.
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?
I'm not 100% sure how the homepage should be configured yet. Right now, the only type of content are just Discourse Communities (sites). However, i'm planning on adding plugins soon. They'll be a different content type with a different way of displaying, searching, etc.
So I just segmented the communities list off to begin with until I figure out something better.
To be clear, CircleCI doesn't support GitLab. So if you're using GitLab for a VCS host, you might as well use GitLab CI and the integration will be nice there.
If you're using GitHub or Bitbucket, you can't use GitLab CI as they only support their own product. So in that case, CircleCI will be the best choice.
So whether or not you want to use GitHub or GitLab is a different discussion. :)
note: There is a hack to get GitLab CI to work with other VCS hosts but that requires mirroring everything over to GitLab which isn't ideal.
For shipping an image yes, but that's not what you'll be doing.
For example, if you've used CircleCI 1.0 before, those builds run in LXC which is Docker's underlying technology. My suggestion is more down that path rather than 2.0's bring your own Dockerfile approach.
The base image you choose just means you don't need to install that specific language/toolset manually, which saves part of the build time and work writing the config.
Basically, there is no longer any concept of `pre` or `post`. The reason being, they were `pre` CircleCI inferred commands and `post` CircleCI inferred commands. `override` meant instead of inferred commands.
In CircleCI 2.0, there is no longer inferred commands. You just run the commands you want.