non-container runner

[lispyclouds]

Now that we can have different types of runners, would be nice to have a runner which implements the same pipeline spec without containers. Should be useful for non container OSes like MacOS and other special needs. Probably is better of not bundled but as an opt-in thing maintained my the bob-cd org?

[lispyclouds]

Implements the step as a raw fork exec.

[lispyclouds]

this would enable generalised executions and specially enable #115

[Vaelatern]

It would also allow scheduling jobs on top of Hashicorp Nomad for scaling your build cluster easily.

[Vaelatern]

I've read the runner/README.md and don't see what API I should conform to as a runner.

Ideally I'd write a runner that sits on top of the hashistack for easy integration there.

[lispyclouds]

Hey @Vaelatern thanks a lot for the interest! 😄

I must admit that I pretty much work on Bob in free time and haven't really done much marketing on it! Hence the lack of serious usage and better docs. Will take this as a chance to improve it!

Having said that, I'm really glad you're interested in getting the hashistack/nomad runner wired up and I think it would be an awesome addition!

Here are some links that could take you in the right direction:

• Bob's architechture, see the section The Execution Model to have an idea of the steps it takes.
• The Pipeline

Essentially, for a runner the following needs to be fulfilled:

• Needs to be able to work with RabbitMQ
• Should declare a queue bob.nomad.jobs. The current one declares bob.container.jobs. The idea is when a pipeline runs, it can declare a dependency on the runner type which is the second segment in the name
• Should declare a queue bob.broadcasts.<unique-id>. this is to receive broadcast messages like stop, pause etc which are runner specific.
• Bind the jobs queue to the bob.direct exchange and the broadcasts queue to the bob.fanout exchange.
• It should implement the Pipeline spec as described above and read the pipeline definitions from XTDB
• It should log its progress and pipeline status to XTDB

Here are some links with point to the implementation in the current runner for reference:

• The queue setup
• Common config for the queue and db connections.
• Logging to XT
• Clojure specs for all of the data and commands that passes between boundaries in the Bob cluster including the pipeline spec
• Implementation of the Pipeline spec

This as you can see is a bit non-trivial but I for me this seems necessary to achieve enough decoupling for scale. I'm happy to give more info and anything else that's needed and will take in things from this to improve docs! Thanks again!

[lispyclouds]

Also I'm totally up for revisiting the pipeline spec and the API expectations! If some things don't make sense in some contexts we should address it and I think such scenarios might just come up. Happy to explore recommendations!

[Vaelatern]

So my biggest issue with this right now is that nomad runs jobs... if we are to do a single step in a pipeline, we'd need to issue a job to nomad using some container like kaniko and then run the line and push to a registry....

Kaniko is best given just a Dockerfile and building that. That would map very well to nomad jobs: one build, one job.

But this too leads to a problem where Pipelines basically become one build step: run kaniko (with possible other steps for other resources and artifacts...)

Thoughts on this abstraction mismatch?