TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Local CI. Sign off on your own work

48 点作者 lwhsiao28 天前

18 条评论

politelemon28 天前
This simply creates a passing status in the repo so that the pr can be merged.<p>There is no obligation on the dev to actually run the tests locally, so you could just save time by disabling status checks.<p>The point of a ci pipeline is that the build ran in a more controlled environment and here is the build log for everyone to see proof.
评论 #43677858 未加载
评论 #43677722 未加载
评论 #43677803 未加载
评论 #43677828 未加载
评论 #43677827 未加载
nothrabannosir28 天前
Not to sound like a shill but Nix solves this very elegantly: tests are just a special kind of build (usually with a synthetic output like &quot;echo ok &gt; $out&quot;) and can therefore be &quot;cached&quot; like any other build. But because build recipes are deterministic, and Nix uses sandboxed, pure build environments, &quot;caching&quot; is just a special case of &quot;uploading build artifacts&quot;. Meaning your cache = build artifact server (&quot;binary store&quot;), and it&#x27;s shared between everyone (CI, build farm, dev laptops, ..), again because build recipes are deterministic. Meaning: if your laptop (or VM) is the same architecture as your CI you can just run your CI steps locally and push that to the shared store, and your CI will now automatically see the tests have already been run and not run them again. And vice-versa. Across all branches and all collaborators who share that same cache.<p>This is all deterministic and doesn&#x27;t require any human in the loop: the test result is hashed by all of the inputs, so you never accidentally spuriously pass a test locally which shouldn&#x27;t have.<p>It requires almost no setup at all. There are SaaS which make this basically turnkey (cachix, nixbuild.net, garnix, ..). Getting your app to build in Nix in the first place, though? Years of tears.<p>Nix lives in this group of tools where &quot;easy things are hard, hard things are easy&quot;, and this is a classic example.
danpalmer28 天前
Lots of confusion between two things in this thread: 1) is this a good idea? 2) is this a good implementation of the idea?<p>Whether this is a good idea has been discussed to death already, but <i>assuming you want this</i> (which most people won&#x27;t, the readme says as much), is this a good implementation of the idea? Yeah, it is.<p>Requiring a CI pass to merge, and a tool to add the CI pass after some unspecified process, seems like a neat, minimal implementation that still prompts the author enough to prevent most accidental misses. Is it complete? Of course not, but checklists don&#x27;t need to be complete to be useful. Atul Gawande&#x27;s book &quot;The Checklist Manifesto&quot; talks about this a bit, just the act of asking is often enough to break us out of habits and get us thinking, and will often turn up more issues than are on the checklist itself.<p>At Google we have a ton of tooling that amounts to light automation around self-certification. Many checks on PRs (CLs) only require you to say &quot;yes I&#x27;ve done the thing&quot;, because that&#x27;s often sufficient.
评论 #43677995 未加载
评论 #43677848 未加载
wavemode28 天前
I could certainly see the appeal of this sort of idea. Once your engineering org gets to a certain size, you can end up spending an eye-watering amount of money on CI compute - spinning up runners and executing thousands of tests for every single commit of every single pull request. That cost could decrease by a lot if, for PRs at least, you could use the dev&#x27;s local machine instead.<p>The three prerequisites in my mind would be, that the CI workflow runs inside a local cluster of VMs (to match a real CI environment), that the results of the CI run are still uploaded and published somewhere, and that it&#x27;s only used for pull requests (whereas a real CI is still used for the main branch).
评论 #43677816 未加载
polygot28 天前
I could _maybe, maybe_ see self-hosted GitHub runners inside of VMs running on developer machines. The VMs would have to be re-created after every request however.<p>I don&#x27;t think this is a great idea, however, as now CI is dependent on my flaky laptop&#x27;s wifi&#x2F;internet connection&#x2F;IP address, has the potential to be contaminated by something running on my machine, build logs can be modified, environment shape&#x2F;architectures are all different and can&#x27;t be easily controlled, I now have access to all of the CI secrets and can impersonate the CI, etc.
serbrech28 天前
Why not actually running CI on your computer? Most CI system work via an agent, so you can join your laptop as a worker to the CI system?<p><a href="https:&#x2F;&#x2F;docs.github.com&#x2F;en&#x2F;actions&#x2F;hosting-your-own-runners&#x2F;managing-self-hosted-runners&#x2F;about-self-hosted-runners" rel="nofollow">https:&#x2F;&#x2F;docs.github.com&#x2F;en&#x2F;actions&#x2F;hosting-your-own-runners&#x2F;...</a><p>You could &quot;favor&quot; your own laptop as a target runner for the CI when it&#x27;s your PR for example<p><a href="https:&#x2F;&#x2F;docs.github.com&#x2F;en&#x2F;actions&#x2F;writing-workflows&#x2F;choosing-where-your-workflow-runs&#x2F;choosing-the-runner-for-a-job" rel="nofollow">https:&#x2F;&#x2F;docs.github.com&#x2F;en&#x2F;actions&#x2F;writing-workflows&#x2F;choosin...</a>
hiyer28 天前
If this is just running tests locally, it seems deeply flawed - e.g. the tests would work even if I forgot to commit new files.<p>OTOH if starting a new container, pulling my branch and then doing everything, it&#x27;s definitely as good as running on remote CI because it&#x27;s basically replicating the same behaviour. And it would likely still be much faster since:<p>* CI machines are underpowered compared to dev laptops&#x2F;desktops. e.g. our CI builds run on a container with 4 vCPUs and 16GB RAM. In contrast my laptop has 16 cores and 48 GB RAM<p>* docker pull itself takes a relatively long time on CI. If I&#x27;m running it locally it would just use the cached layers
评论 #43677793 未加载
评论 #43677801 未加载
schneems28 天前
I wrote and released a similar concept in 2012 in response to co-workers constantly breaking my code and not running tests before committing. <a href="https:&#x2F;&#x2F;rubygems.org&#x2F;gems&#x2F;git_test&#x2F;" rel="nofollow">https:&#x2F;&#x2F;rubygems.org&#x2F;gems&#x2F;git_test&#x2F;</a><p>That was before we had a reliable CI server and let me tell you, fixing the CI server was a much better investment than convincing everyone to run and document their tests locally. The basecamp tool is more polished than what I cobbled together, but I personally won’t be reaching for it any time soon.
评论 #43677769 未加载
rtpg28 天前
I do like the idea of a variant of this that also includes some signing and logs that share, well, more of the state involved in this.<p>This sort of work would likely mean that test suites would be built in a way to be run in a more diverse sets of environments. That leads to just less brittle tests overall, and hopefully a better foundation to debug things.
jatins28 天前
Given how fast dev machines are, doing this might not be a bad idea for small teams _if_ you have some way to ensure reproducible builds&#x2F;tests. Otherwise I can imagine a lot of &quot;works on my machine&quot; cases<p>Though if you are an org of 1000+ engineers working in big monorepos better stick to CI
评论 #43677946 未加载
syntaxing28 天前
This might sound crazy to a lot of people, but I actually wish I had the same lint&#x2F;mypy&#x2F;flake8 CI from work on my personal projects. I don’t need anything fancy but something on github that’s single click that forces discipline.
评论 #43678001 未加载
评论 #43677843 未加载
matthewfcarlson28 天前
I agree with the premise (dev machines are under utilized) but the environment (or lack thereof) of the CI machine is its major selling point. No stupid forgot to add dependency x. Of course it works, you developed it on your machine.
kevmo31428 天前
At that rate you might as well force merge, no? That&#x27;s equivalent to signing off and doesn&#x27;t make the CI have a false positive signal when it hasn&#x27;t actually run.
llIIllIIllIIl28 天前
Passes on every undeclared dependency that is available locally but would render the official artifact unusable.
arnath28 天前
I’m deeply confused … what does this actually do? Mark your commit as having tests passed?
评论 #43677593 未加载
ezyang28 天前
I mean, obviously you want to run the local CI in some isolated way. But it&#x27;s not such a bad idea for many projects.<p>At PyTorch, we have the reverse problem, it&#x27;s basically infeasible to run the CI locally, you really do need the cloud setup to cover all of the operating system &#x2F; hardware configurations, and the parallelization in cloud also saves you loads of time.
xyst28 天前
Now we are back to &quot;hey bro, it signed off on my computer&quot; :shrug_emoji:
评论 #43677724 未加载
thiht28 天前
This misses the point of CI. The CI environment is neutral, one of its goals is to avoid the &quot;it works on my machine&quot; effect. If it doesn’t at least run in a container or a VM, it’s not CI.