[Feature] Make long-running jobs easier to work with

[ryancannon88]

I've been using cargo-watch to re-compile my web server as I iterate on it. I simply run cargo watch -w src/ -x run in my terminal.

With Bacon, I must first add a bacon.toml file to the root of my project directory and then modify the run job in that file to the following:

[jobs.run]
command = [
    "cargo", "run",
    "--color", "always",
]
need_stdout = true
allow_warnings = true
background = false # Needed for long-running jobs!
on_change_strategy = "kill_then_restart" # Needed for long-running jobs!

It took me a good amount of time to figure out this configuration was needed. I wonder if we can make long-running jobs easier to work with. I would guess that working with servers is a common use case. Ideally, no config file would be necessary, so end-users can simply run a command in the terminal.

Here are some options I have in mind:

1. Create a default job called “run-long” which has the background and on_change_strategy job fields set appropriately.
   • Pros
     • Simple and easy to discover through the CLI --help menu
     • Hides job config details from end-users
     • Very easy to implement
   • Cons
     • Too niche? Not sure if this exact config is popular enough to warrant its own default job.
     • Currently, jobs are differentiated by command arguments, not job fields when you run bacon --list-jobs. This means the run-long job would look exactly the same as the run job. We would need to add some information noting the difference between these two jobs.
2. Allow job fields to be specified via CLI arguments
   1. Cargo-watch example:
      1. cargo watch -q -c -w src/ -x run
   2. Bacon examples:
      1. bacon run —background false —on-change-strategy kill-then-restart
      2. bacon run —bg false —on-change kill
   3. Pros/Cons
      • Pros
        • This solution allows for fine-grain configuration through CLI arguments and could be useful outside of the long-running jobs use case.
      • Cons
        • Scope creep? Not sure if exposing job fields is generally useful. If not, then doing this only for this one use case might be overkill.
3. Do both options 1 and 2

Thoughts?

[Canop]

A run-long job would be simple enough to add and wouldn't really add to the length or verbosit of the default bacon.toml file, as it would help shorten the comments of the run job.

I'd like to avoid specifying jobs in cli arguments. For reuse or sharing, they need you to write scripts/makefiles so there's nothing gained.

[ryancannon88]

@Canop Ok, if you don't mind I'd like to work on this so I can get some experience with this repo :)

[Canop]

You mean propose a run-long job in the defaul conf file ? You can make a PR, but this is just comments and won't get you much more experience.

[ryancannon88]

@Canop Yes exactly. I know it's silly but I'd still like to do it.