112 karma · joined September 9, 2016
Every sw dev knows this is a very dangerous, and unrealistic, assumption.
Tnx for checking, and reconfirming!
1: https://circleci.com/docs/guides/execution-managed/ssh-acces...
(Disclaimer: i work at 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)
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)
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 :)
"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.
I think most do. Or at least the infrastructure/compute costs are not coming from their own dept budget anymore ;)
For some examples of more advanced usecases take a look: https://circleci.com/blog/platform-toolkit/
Disclaimer: i work for CircleCI.
Are you looking for something specific that you're missing in the current offerings regarding test reporting?
(Disclaimer: I work at CircleCI)
(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...
(disclaimer: i'm a CircleCI employee)
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?