Hey thanks for the Q: We will support other CI systems than GitHub Actions, but exact timeline of which and when is TBD.
With regards to cost, you can self-host GitHub Actions runners. Internally we use an autoscaling group of spot instances via k8s, which is much cheaper than GitHub-hosted runners. We actually didn't do it for the cost, we did it because we wanted a local cache to persist on machines during the day, for performance reasons. When cost is a factor, having an analytics system help you optimize your jobs is super important.
In SF, $35/walk is cheap. If you've watched 10hrs of dog training videos on youtube you can command $100/hr (the going rate for an unqualified dog trainer), or $150+/hr for a qualified dog trainer.
Especially if you're using a finite pool of CI runners. Lots of companies do run their own CI runners either for added security, or to get persistent CI machines with a hot local cache so builds/tests are much faster. Then everyone's PRs are blocked waiting for CI machines just because of people's weird push workflows or micro stacked PRs
I think this definition is outdated - linters find real bugs now. The boundaries between linters, static analyzers, and security tools in real life are basically nonexistent, it's entirely tool by tool. Also, autoformatters should style code, not linters. Used to be that linters told you about code style issues, and many still do, but ppl should turn all rules off and use autoformatters instead. Much easier/better.
If each of your commits are tested and make sense independently, they should be different PRs - sounds to me like you're just smashing 5 stacked PRs into 1 with highly fussy curated commits, which aren't guaranteed by github settings to each be passing CI
> As for squashing, I believe that everything should be rebased instead to maintain a proper, linear git history
Rebasing on your PR branches is up to you, it's subjective, but setting GitHub to rebase your PR commits onto your main branch as it's merge strategy is not proper at all. It might 'work' for a tiny hobby project, but it does NOT work for any kind of team activity / professional environment - it would be an immense amount of bloat onto your main branch, and git will eventually start to get slow as mud on every operation because of it. Fun fact, git performance does not scale linearly, and big monorepos hit this problem. Beyond performance, when looking through git history on the main branch:
- Every commit on the main branch should map 1:1 with a reviewed PR that passed CI tests/checks
- The 'mapping' can just be done by having the PR number in the commit message title. GitHub does that for you with the settings in this blog post
- It's not uncommon that someone has 30+ commits on their PR branch, many of which are in a totally broken state, have blatant typos, etc. People just don't (and it's not even desire-able for them to) structure their local commits while working on a PR to be some kind of iterative working state that is useful for others to look at. It's beyond clutter to have these 30 broken commits with crummy commit messages like "update" rebased onto the main branch for all to see for all time.
Trunk Merge is an intelligent service that orchestrates merging pull requests to maintain a repository of code that always passes tests. Airbnb, Uber, Twitter, Robinhood, and many other big tech companies internally have their own sophisticated merge queues. Now, you can get the same thing without having to build it.
100% agree that documenting the practices of your repo is a losing battle: automate it or don't bother. I don't think you go far enough here. Every file in your repo should minimally have an autoformatter and some kind of linter/static analyzer/validator set up. Even shell scripts, ci pipeline configs, dockerfiles, terraform, etc. I recommend https://docs.trunk.io ;)
Thanks for the comment! Go ahead and use it in private repos for personal use or on small teams for free - our pricing structure only targets private repo use by companies with eng teams > 10.
Even for ecosystems that do have tool dep pinning, folks are missing out because the linters/formatters you should be running aren't necessarily part of the language ecosystem you use. For example, you probably have shell scripts that should run shfmt and shellcheck, which aren't on npm, even if you otherwise use javascript.
Trunk is young, but we'll become the one stop shop for the full development experience of highly productive scalable repos: linting, formatting, code coverage, merge automation, test analytics, running/selecting tests, and more. What we've seen is companies & projects repeatedly recreating bad versions of this stuff in house - which leads to bad dev experience and is a waste of time & money.
Hey thanks - it should populate with issues for any files that you've modified, and as you browse files any file you have open. We don't have a way from vscode to run on the whole codebase yet, best run the cli for that, but it's coming!
Hi! I’m one of the co-founders of Trunk. Trunk Check is the first tool in the toolbox we're building to make scalable, productive repos possible out of the box. Modern repositories include many technologies, each with its own set of linters. With 30+ linters and counting, Trunk makes it dead-simple to identify, install, configure, and run the right linters, static analyzers, and formatters for all your repos. Use it on mac or linux from the command line, our vscode extension, or on CI. We’re on the thread so please ask any questions. We’d love to get feedback from the HN crowd. TYVM!
With regards to cost, you can self-host GitHub Actions runners. Internally we use an autoscaling group of spot instances via k8s, which is much cheaper than GitHub-hosted runners. We actually didn't do it for the cost, we did it because we wanted a local cache to persist on machines during the day, for performance reasons. When cost is a factor, having an analytics system help you optimize your jobs is super important.