We are looking into it. It feels like quite a different use case though, so we'll see how things go.
11 karma · joined July 9, 2019
Oh I see thanks for the clarification, the name comes after Firecracker, the framework that we use for microVMs
> Have you considered a model in which people can license this service and drop it inside their own infrastructure (AWS/Azure/GC or on premise bare metal (Kubernetes, Openshift and friends))?
Yes, you can run the services inside your own infra (AWS/AZURE/GC and on-prem bare metal), I think I should make that more clear on the page and maybe the post so this is clarified, thanks for the question and feedback!
> TL/DR: this is "github runners as a service", and claimed build time improvement appears because they OpenFire gives more CPU/RAM resources that default Github runners. I guess a good idea if you rely on github's default runners... but if you are already using your own runners the benefit may or may not appear. For example hosting runners on EC2 is 2x cheaper, and gives you stuff like shared cache.
I'm happy that you got the idea behind Open Fire "github runners as a service", yes you can run your runners in an EC2 instance, but on top of that, we're taking the burden of running those instances, having all the dependencies updated and working on building new features around the platform like analytics for your pipelines, local caches so the networking stop being a bottleneck for you runners, incremental building, instant checkout and more to come
> Also, "just change 1 line of code" is a bit of exaggeration.. It is more like "sign up with Open Fire, enter your credit card, grant them access to all your git repos, change 1 line of code, don't forget to pay the bills".
yeap, that is pretty much the idea, pretty neat for onboarding a new solution, right?
sorry I didn't your first part about the chat server
> And what is this? This is an expensive security breach.
Great question, From the data perspective, we don't store any kind of information, the logs are retained by GitHub, for each run we issue a registration token and use it for spinning up the runner and it is gone. When the job is finished the VM and the filesystem get deleted, and if your security needs prohibit you from using a SaaS you can use Open Fire in your own infrastructure. We're working on our process of getting the SOC-2
> How can it be cheaper to have a runner elsewhere? And how hard is to self host a runner?
like any engineering problem, self-hosted solutions come with tradeoffs and at the end of the day all depends if the benefits will overcome the effort that you need to put to build, operate and run your solution, in the post, I made a not exhaustive list of thing that you need to do in the self-hosted case if you can pay that price and still get benefits then that is the way to go in your use case, as always the question is the same, why use Dropbox if I can build it myself? Yes, you can build it but is it worth it? or just pay 5 bucks and use it.
Thanks for your questions, I hope you have some more
Good news everyone! we're happy to announce our new release of Wololo CI
In this release, we focused on giving the maximum information of theirs build to our users, check it out
* Build Addressable Assets
* Skip Wololo Build Player default
* Now you can run your own build script inside Wololo build pipelines
* Build Steps: The different steps involved in making you build, how long they took, and what messages were printed during those steps (if any).
* Source Assets: A list of all assets which are used in the build, and how much they contribute to your build size
* Output files: here you can see all the files associated with your build, the role and size- Build support for different platforms (Android, iOS, StandaloneOSX, StandaloneWindows, WebGL, Linux).
- Build Triggers for Github, GitLab, Bitbucket (build on push).
- Added Unity3D Advanced Options
- Commons:
Build custom scenes
Development build
Strict mode build
Run API updater
Scripting define symbols
Pre/Post-Export method
Pre/Post-Build script (.sh)
Define custom environment variables
Compression type (default, lz4, lz4hc)
Android app bundle (.aab)
Split application binary (Apk & .obb)
Android build system.
Handless build
-Improvements on the UI/UX of the site, so now you can find quickly what you want to find.
if you wanna know more just ping me jean@wololoci.com
Cheers, Jean.
Cheers, Jean