Now it's smartphones and devices, but in the past it was work. Personally I think these days kids get a lot more attention from their parents than anytime in the past. Even so much that it can be irritating/damaging (parents being "friends/playmates" instead of parents).
HN user
olafmol
This little line from the article scares me: "but a software engineer would iron out the remaining potential bugs that I could not find quickly"
Every sw dev knows this is a very dangerous, and unrealistic, assumption.
Phew, was this a test? ;P
Tnx for checking, and reconfirming!
This is exactly the reason why I like to work with local models on a regular specced machine. The fact that the agent moves slower allows me to stay in the loop much better, compared to skimming through a huge amount of generated content and data and then going to the end really fast to make sense of it all, in the interest of time (and thus losing track and quality). The fact that I can run it locally makes it (much) cheaper too.
An LLM should not "generate specs", a human should. The LLM can work from the specs. It can never infer meaning from a vague prompt. If so, it will start guessing. Every human that ever did functional specification or information analysis at some point knows this. Or has learned the hard way, something with assumptions and asses ;)
Gitea might be an option also.
Out of interest: what does "better AI integration" mean? Any specific functional or non-functional requirements?
Out of interest: what VCS where you using with CircleCI? (as CircleCI is VCS agnostic)
Correction: Gitlab is not Dutch. It has a Dutch co-founder, and was a B.V. for about one year before moving to the US and become an Inc. The original founder is from Ukraine.
Let engineers do Vibe-accounting because, AI.
Debug with SSH(1) is still one of our (CircleCI) most loved and praised features. I really believe that these little QoL features can make a world of difference for sw developers and engineers, and this stays a strong focus for us.
1: https://circleci.com/docs/guides/execution-managed/ssh-acces...
(Disclaimer: i work at CircleCI)
This is exactly what my team told me when they switched from Concourse CI to CircleCI. I was surprised, this wasn't really discussed, but the pressure on the team to deliver features was increasing, and they were struggling to much with all the tooling instead of delivering functionality. So they deciced to switch to something not so sexy but dependable and stable. Funny thing, about 1 year later we got acquired by CircleCI :)
I like to compare CircleCI to a Volvo, not the most sexy thing in the world, but when you need something dependable that gets the job done and helps you to focus on what really matters, getting from A to B, it's one of the bettter choices.
(disclaimer, i'm still with CircleCI)
I think we (CircleCI) are doing quite well: https://status.circleci.com/
It’s open source right? You know what to do ;)
Almost nothing i assume. NI really lost the plot several years ago when the original founders left the company. Crappy after-sales support, lack of product vision and corresponding crappy execution, and a ton of technical debt all over their product-range. Plus competitors made better/right moves, came alongside, and then moved faster and better, leaving NI in the dust. It's sad to see a company that once was leading in several categories now in this state.
We (CircleCI) are still there, and doing just fine :) Out of interest, what are you currently missing and what would those "essential" V2 features be? tnx for sharing your thoughts!
I'd like to point out that CircleCI is typically faster (and more consistent) than GH Actions, and also offers a free tier (with more free build credits for opensource projects: https://circleci.com/open-source/)
Personally I believe that GH Actions' adoption was mostly a case of "we already use github as our VCS, so we get Actions for free with our MS licenses" combined with "hey, we can easily use all those Actions that people put online" (with all the security and compliancy issues that come with such a YOLO mindset lol)
(Disclaimer: i work for CircleCI)
It's not obfuscated. The free plan gives you a max of 5 concurrent self-hosted runners. If you need more you can upgrade your plan: https://circleci.com/pricing/#comparison-table
There simply is no free lunch, somewhere someone needs to spend effort and time on managing the orchestration layer for the runners, and there is also network traffic and storage in play that costs money. If you need a future-proof CI/CD platform, it takes some investment. I agree that the Github "pay per minute" approach doesn't feel right, most people would probably find a "pay per orchestration job" or something more acceptable.
Anyway, there are alternatives out there :)
Agreed that caching needs (and can be, and will be) improved.
CircleCI does only charge for self-hosted runners generated egress and/or artifact storage:
"Any Network Egress to CircleCI will be charged. At this current time, this includes CircleCI Caches, Workspaces, and Artifacts and will be charged at the normal rate according to your Usage Controls.
The only network traffic that will result in billing is accrued through restoring caches and workspaces, and downloading artifacts to self-hosted runners. Retention of artifacts, workspace, and cache objects will result in billing for storage usage.
Since your builds will not be running on CircleCI's Infrastructure, you will not be charged compute credits"
https://support.circleci.com/hc/en-us/articles/2064321965685...
I think that's fair. In my personal opinion most people started using GitHub Actions because it “came for free with the VCS and/or our MS contract” and it was “good enough for the job”. Now might be a good time to look around at the alternatives again. There is a reason that f.e. CircleCI is doing fully focused CI/CD for 10+ years and is still going strong. Plenty of businesses don’t want to put all their eggs in one (MS) basket, for all kinds of reasons. I guess today one of these reasons became obvious.
Disclaimer: I work at CircleCI.
This. There are plenty of good/better CICD solutions out there, but it's tricky to compete with "comes for free with our VCS". I guess it's clear now there is no such thing as a free lunch. I feel it's a good thing for the "CICD industry" that people will be looking around to alternatives, and do a honest Total Cost of Ownership analysis.
"That said, most teams don't self-host purely to save money"
I think most do. Or at least the infrastructure/compute costs are not coming from their own dept budget anymore ;)
CircleCI made great steps the last few years, f.e. to better support proper DRY working, supporting OPA policies-as-code, VSCode extensions with "dry-run" options.
For some examples of more advanced usecases take a look: https://circleci.com/blog/platform-toolkit/
Disclaimer: i work for CircleCI.
Thanks for clarifying, appreciate it! It's true we don't support all the events that Github exposes, but we believe we support the most common and useful ones. Also, this is not set in stone and expanding all the time, f.e. https://circleci.com/changelog/trigger-pipelines-on-github-p...
You mention you're looking for (ao) "proper test reporting". CircleCI has a "Test Insights" view (https://circleci.com/docs/insights-tests/) and can collect test-results from a wide range of formats: https://circleci.com/docs/collect-test-data/#test-runner-exa...
Are you looking for something specific that you're missing in the current offerings regarding test reporting?
(Disclaimer: I work at CircleCI)
Although there are definitely merits in moving the complex logic outside of the CI/CD JSON/YAML DSL, especially when using monorepo setups that can become rather complex in their logic (that they made Google create Bazel, I can think of some interesting Borg/K8s analogies btw), I also believe that modern CI/CD platforms have made several sensible steps in the right direction to handle these more complicated use cases.
(Disclaimer: I work at CircleCI)
At CircleCI for example, we have added valuable features like a VSCode extension[0] to validate and "dry-run" config from within your IDE, we have local runners[1] that you can use to test and run pipelines on your local machine and your own infra, we have dynamic config[2], a Javascript/Typescript SDK[3], a CLI that can validate and run workflows locally[4], and QoL additions like a no-op job type[5] and flexible requires, along with flexible when statements and expression based job filters[6].
And finally, it's of course also possible to combine different approaches into a "best of both worlds" approach, f.e. combining Dagger with CircleCI[7].
[0]https://circleci.com/docs/vs-code-extension-overview/
[1]https://circleci.com/blog/using-runner-for-local-testing/
[2]https://circleci.com/docs/dynamic-config/
[3]https://circleci.com/docs/circleci-config-sdk/
[4]https://circleci.com/docs/how-to-use-the-circleci-local-cli/
[5]https://circleci.com/changelog/new-job-type-no-op-job-can-ma...
[6]https://circleci.com/changelog/more-flexible-job-required-ca...
understood, tnx!
I didn't make myself clear I think. You mention that you love Captain, and wish you had access to it when migrating away from CircleCI. I'm interested in understanding the specific reason(s) for your love for Captain's features, that seem to also be available in CircleCI?
Out of interest: CircleCI also has flaky test detection, rerun failed tests etc. Or did you mean that the CI that you were moving towards could benefit from Captains features?
(disclaimer: i'm a CircleCI employee)
Hi @atombender,
with the new SDK you would be able to parse your K8s manifests, and create (dynamic) configs with the parsed info. This is actually an interesting usecase, tnx!
Could you explain what you mean with "running a single job across multiple machines"? How would that exactly work clustering- and result-agreggation wise? Of course it's perfectly possible to run parallel jobs over multiple machines (https://circleci.com/docs/2.0/parallelism-faster-jobs/) but i guess you mean something different?