Firstly, and very importantly, the agent is open source (https://github.com/boxci/boxci) so you can see exactly what it does and even build it from source if you want. I should mention Box CI isn't launched yet, everything is still in beta including the agent.
The Box CI service doesn't have any way to send requests to or send commands to agents - the requests are one-way, agent to service only, with agents polling the service for build jobs to run, running them, and sending logs and results to the service.
Build scripts and configuration are all in your source code. This is a tradeoff, because it definitely means you have to trust your source (and everyone committing to it) if you're going to be running agents on your dev machine for instance.
There are obviously mitigations to this though, like running the agents on a dedicated Cloud VM with nothing on the filesystem and internet access locked down to package manager and cloud provider hosts. A future plan is to provide pre-configured VMs for various cloud providers so this can be set up in a few clicks for low cost ($20 a month or whatever a reasonable build machine VM would cost).
The real security point of the the agents though, the other side of these tradeoffs, is that your code and your production secrets never leave hardware you control - the CI service never has access to them. That's a massive security advantage Vs centralised CI services which do have full read access to your source and effectively full write access to your production infrastructure via keys you give them - compared to what I've described above this is a massively bigger and more dangerous potential security hole.
You can probably tell by the length of this comment I'm super interested in this aspect (along with dev experience I see it as the key advantage of the model and one of the reasons I'm building it) there's a lot more depth to this and if you'd like to discuss further, I'd love to :-) Email's in my profile.
Neat! I love the model of giving powerful CI tools directly to the user. I ended up with a similar solution for my personal projects: a private bors-style CI GitHub bot, written from scratch, running on my own hardware, that I control via GitHub comments (the bot ignores comments from other users).
It's quite spartan, but it gets the job done, and I love that a) it's fast, b) I can see exactly what happened, down to ssh'ing into the build directory and poking around, and c) If there's a feature I want, I can just add it!
Very cool - yeah I know exactly what you mean, running CI workflows on your own machine is just so nice.
When something fails it makes the debug and retry loop just as simple and fast as when you're developing, and there's really nothing like watching a production build run and ship in literally like a minute, just as fast as if you're building and starting your local dev server :-)
Firstly, and very importantly, the agent is open source (https://github.com/boxci/boxci) so you can see exactly what it does and even build it from source if you want. I should mention Box CI isn't launched yet, everything is still in beta including the agent.
The Box CI service doesn't have any way to send requests to or send commands to agents - the requests are one-way, agent to service only, with agents polling the service for build jobs to run, running them, and sending logs and results to the service.
Build scripts and configuration are all in your source code. This is a tradeoff, because it definitely means you have to trust your source (and everyone committing to it) if you're going to be running agents on your dev machine for instance.
There are obviously mitigations to this though, like running the agents on a dedicated Cloud VM with nothing on the filesystem and internet access locked down to package manager and cloud provider hosts. A future plan is to provide pre-configured VMs for various cloud providers so this can be set up in a few clicks for low cost ($20 a month or whatever a reasonable build machine VM would cost).
The real security point of the the agents though, the other side of these tradeoffs, is that your code and your production secrets never leave hardware you control - the CI service never has access to them. That's a massive security advantage Vs centralised CI services which do have full read access to your source and effectively full write access to your production infrastructure via keys you give them - compared to what I've described above this is a massively bigger and more dangerous potential security hole.
You can probably tell by the length of this comment I'm super interested in this aspect (along with dev experience I see it as the key advantage of the model and one of the reasons I'm building it) there's a lot more depth to this and if you'd like to discuss further, I'd love to :-) Email's in my profile.