Same thing, yeah, IIUC (i.e., running the agent/worker locally for testing). It's conceptually similar to self-hosted runners, yes, but also different in a few practical ways that may matter to you, depending on how you plan to run in production.
For one, with GitHub Actions, hosted and self-hosted runners are fundamentally different applications; hosted runners are fully configured container images, (with base OS, tools, etc., on board), whereas self-hosted runners are essentially thin, unconfigured shell scripts. This means that unless you're planning on using self-hosted runners in production (which some do of course, but most don't), it wouldn't make sense to dev/test with them locally, given how different they are. With Buildkite, there's only one "way" -- `buildkite-agent`, the single binary I linked to above.
The connection models are also different. While both GHA self-hosted runners and the Buildkite agent connect to a remote service to claim and run jobs, GHA runners must first be registered with a GitHub org or repository before you can use them, and then workflows must also be configured to use them (e.g., with `runs-on` params). With Buildkite, any `buildkite-agent` with a proper token can connect to a queue to run a job.
There are others, but hopefully that gives you an idea.
>Lack of local development. It's a known thing that there is no way of running GitHub Actions locally.
This is one thing I really love about Buildkite[0] -- being able to run the agent locally. (Full disclosure: I also work for Buildkite.) The Buildkite agent runs as a normal process too (rather than as a Docker container), which makes the process of workflow development way simpler, IMO. I also keep a handful of agents running locally on my laptop for personal projects, which is nice. (Why run those processes on someone else's infra if I don't have to?)
>Reusability and YAML
This is another one that I believe is unique to Buildkite and that I also find super useful. You can write your workflows in YAML of course -- but you can also write them in your language of choice, and then serialize to YAML or JSON when you're ready to start the run (or even add onto the run as it's running if you need to). This lets you encapsulate and reuse (and test, etc.) workflow logic as you need. We have many large customers that do some amazing things with this capability.
Pulumi engineer here. We did, as an experiment (and labeled it thusly), but we believed we’d have much more control over it than we have. After we began hearing these reports, we began taking them down. The vast majority have since been converted to return HTTP 410 with noindex directives, yet Google still hasn’t responded. It’s been frustrating for us also.
The obvious difference, though, is that you knowingly use all of these tools; you get to choose whether and how you use them. AI, like the weapons you point out, can invade your life without you knowing it even exists.
Pulumi docs engineer here. Really appreciate that feedback -- what sort of thing did you have to go digging for? We're definitely investing here so I'd love to hear more about what you were looking for and didn't find (or what you discovered along the way that we could've made clearer). Thanks!
Really? Why? Trying something new before becoming a "master" in something similar seems like a totally reasonable concept to me. I work on Pulumi, and even I don't actively discourage people from trying its alternatives. Use what makes you happy, I say.
+1 for node-webkit; I've been having a blast messing around with it lately, it's great stuff. With the pre-built binaries, you can be off and running (with full node support in your browser JS) in minutes.
There's no excuse for wasting your time like this; one can only assume they didn't or don't know how to properly evaluate a design candidate, so they compensated for their inexperience by taking advantage of you. Unprofessional to say the least.
You're right -- the appropriate and respectful thing to do would've been to bring you aboard as a contract-to-hire, and if things didn't work out, let you go -- after properly paying you for your time and product. If you can afford to hire someone, you can certainly afford the fractional (and risk-free) cost of trying them out.