Backlog

This issue documents the backlog which serves as the basis for future versions. If you have opinions on this, feel free to comment and start discussions. Some of these ideas may be implemented and your input matters.

Features

• Make bin configuration more streamlined:
  • Presets?
    • bash: sh -c
    • cmd: cmd /c
    • powershell: powershell -Command
  • Enable configuring bin via profile?
• ? External log monitors:
  • use arpx to monitor external log file and spawn processes ontrigger
• ?? Per-process log colors:
  • probably not for Arpx... more appropriate for a separate program ("prism"?)

Changes

• Log monitors should be able to stdin process threads if needed
• Consider renaming test property in log_monitors mappings to command, to be consistent with processes
• Consider renaming command to exec everywhere
• Consider renaming ontrigger property in log_monitors mappings to onsucceed, or assign it to a special exit code instead (such as 2) and call it on2
• Allow log monitors to execute multiple (concurrent) ontrigger actions
• Log monitors should spawn ontrigger actions on the process threads they watch (not on their own thread)
  • park process threads if needed and use message passing to prompt the task thread to unpark and run the ontrigger
• Consider making jobs composable (jobs can be actions too):
  • jobs would now have contingency
  • runtime ctx would need a job_map
  • thread max would be harder to enforce

Improvements

• Insofar as ctx is passed around, the entire log_monitor_map and process_map objects get copied. Can ctx be referenced instead?

Platform support

• Windows support pending this issue

Documentation

• Replace foobar examples throughout docs (and demo) with standard, practical examples (cluster init, webserver, api service, etc.)
• Migration guide for profiles
• Clarify how log monitors should be used

thanks for the good work! I'd like to add a simple feature:

• to download binary executable from a remote URL depending on current environment if it is missing

this make it functionally similar to a bootstrapping wrapper (gradlew, mavenw)

Thanks for the input, @tribbloid

Question about this idea. Couldn't this be accomplished by creating a custom task that calls curl to perform the download, depending on some condition? Then, this task could be called from your bootstrapping job.

Let me know if I'm missing your point

@jaredgorski sounds like a good idea, I'll need to experiment on this