[WIP] [POC] Awesome runner - #178
Conversation
66d040b to
f6c4259
Compare
|
updates:
|
|
update:
|
| require "concurrent/array" | ||
|
|
||
| module Floe | ||
| class AwesomeProcess < Thread |
There was a problem hiding this comment.
would have preferred not using a thread per process and not using an AwesomeSpan centric model.
436600d to
af7918d
Compare
f518699 to
61d4123
Compare
|
update:
update:
|
|
This pull request has been automatically marked as stale because it has not been updated for at least 3 months. If these changes are still valid, please remove the |
|
This pull request has been automatically marked as stale because it has not been updated for at least 3 months. If these changes are still valid, please remove the |
1 similar comment
|
This pull request has been automatically marked as stale because it has not been updated for at least 3 months. If these changes are still valid, please remove the |
514bed0 to
b28abb7
Compare
|
update:
still WIP |
|
naming-wise I don't like the awesome part - externally awesome:// means nothing. If this is basically just shell execution, let's call it shell:// or if it's bash specific then bash:// |
| "Resource": "awesome://ls -l Gemfile", | ||
| "Comment": "awesome://ls -l $FILENAME", | ||
| "Next": "c", | ||
| "Parameters": { | ||
| "FILENAME" : "Gemfile" | ||
| } |
There was a problem hiding this comment.
I'm thinking we should adhere to the AwesomeSpawn style of params handling, so something roughtly like:
| "Resource": "awesome://ls -l Gemfile", | |
| "Comment": "awesome://ls -l $FILENAME", | |
| "Next": "c", | |
| "Parameters": { | |
| "FILENAME" : "Gemfile" | |
| } | |
| "Resource": "awesome://ls", | |
| "Comment": "awesome://ls -l $FILENAME", | |
| "Next": "c", | |
| "Parameters": { | |
| "-l": null, | |
| "Gemfile": null | |
| } |
Though, I'm not sure how we would handle duplicate parameters.
There was a problem hiding this comment.
aah. I think $FILENAME did not work and that is why I put that comment in there.
Couldn't get shell env var expansion working. (There was a legit use case in there)
|
FWIW, I would not want this in ManageIQ, but it could be useful outside of ManageIQ. The reason is because we run user-created workflows, and this would give access to the underlying OS/filesystem, which would open up potential security issues. However, if I wanted to automate, say, my own personal stuff on my computer, this would be very useful. |
|
I was thinking for tests. But yea |
|
Checked commits kbrock/floe@8624923~...b28abb7 with ruby 3.1.7, rubocop 1.56.3, haml-lint 0.64.0, and yamllint lib/floe/awesome_runner.rb
|
|
This pull request is not mergeable. Please rebase and repush. |
|
I'm considering bringing this in as an optional built-in runner, but I want to refactor the way we do built-in runners first. I have some ideas I want to write up. |
|
I was really frustrated that variables could not be passed into the shell to pick up on the env. But I guess using ruby variables instead may fix for many of the use cases |
|
This pull request has been automatically marked as stale because it has not been updated for at least 3 months. If these changes are still valid, please remove the |
3 participants
depends upon:
Overview
So that begs to ask the question on how to implement a runner that manages its own subprocesses.
Implementation
I came up with a synchronous and an asynchronous implementation. They get converted across with a commit.
I feel the synchronous implementation may be the best one, otherwise it has a bunch of threads hanging around.
commits:
Issues
This doesn't work perfectly since
AwesomeSpawnescapes$VARand that makes this pretty useless.But the goal was more focused on the Threads and stuff rather than the actual awesome spawn part.