Airbrussh::Rake::Context needs to be redesigned to be thread-safe?

[mattbrictson]

The Context class is built around the assumption that a given Rake task is fully completed before moving onto the next task. For example, even when Capistrano is deploying to multiple servers in parallel, the concurrency happens within a single task. In other words, all SSH executions for that task must finish before moving onto the next task.

However this assumption fails when Capistrano's invoke DSL is used within an SSHKit on block. Doing this leads to scenarios where one Rake task partially executes, then another task, and then back to the original task. In a multi-server deployment, this task switching can happen at different times in different threads.

Airbrussh::Rake::Context fails to track the current task in such scenarios. In fact, Airbrussh's entire output formatting is predicated on the linear progression of Rake tasks.

I don't know if a redesign is warranted, but it is certainly something to think about, especially if invoke is used this way often.

Perhaps the solution is to use a stack to track task execution, rather than a single variable, and to keep a separate stack in each thread.

See original discussion in #78.

[neovatar]

Just stumbled over this. We use invokes like

task('options:parse').invoke([:release_tag, :project_name, :repo_url])

in our capistrano tasks (e.g. deploy). This invoke just checks for some required options from the rake command line. Then the original task (deploy) is continued. But airbussh outputs 'options:parse' as task.

I disabled it by setting the config option "monkey_patch_rake = false", because the output is very confusing (wrong task name). Is there a workaround for this, like setting the rake task context for airbrussh after calling an invoke?

[mattbrictson]

This is a tough one. I don't think there is an easy workaround. You could try explicitly setting the task name, but I'm not sure it would produce the right results:

Airbrussh::Rake::Context.current_task_name = "deploy"