Feat: bundle builds

[SRWieZ]

No description provided.

[simonhamp]

Something is making all of the tests crash here. Not sure what

[simonhamp]

I've superficially fixed the tests here... I think the changes in that commit highlight some things about the implementations and the changes that have crept in.

I think it's fine for now, but I'm a little concerned around the QueueWorker alias stuff... the complexity there seems to be that we have an alias for the ChildProcess itself (which seems to have grown a queue_ prefix) and a --name for the queue worker.

It looks like these aliases were identical before, but that perhaps you tried to disambiguate?

I'm fine for it to be in its current state, but we should rationalise the ideal state and settle on it now before v1. My concern is that neither approach is perfect and that in either case we will need something in the docs to explain to devs what's happening.

[PeteBishwhip]

Dropped in a quick little merge conflict resolution commit.

[SRWieZ]

I've superficially fixed the tests here... I think the changes in that commit highlight some things about the implementations and the changes that have crept in.

I think it's fine for now, but I'm a little concerned around the QueueWorker alias stuff... the complexity there seems to be that we have an alias for the ChildProcess itself (which seems to have grown a queue_ prefix) and a --name for the queue worker.

It looks like these aliases were identical before, but that perhaps you tried to disambiguate?

Yes.

Because, by default, a child process named default was launched and shown in the console/logs, but a newcomer would not understand that it's the queue worker that has been launched.

I made this change to separate queue workers from other child processes and avoid conflicting names. The name of the queue didn't change, but the alias on the child process has a prefix now.

I looked at and approved your test fix. They correctly reflects my changes.

I'm fine for it to be in its current state, but we should rationalise the ideal state and settle on it now before v1. My concern is that neither approach is perfect and that in either case we will need something in the docs to explain to devs what's happening.

Yep.