Feature request: add "log" endpoint

[bdd]

Feature request: add "log" endpoint

[cuu508]

For the usage pattern discussed in the linked issue, we'd want a way to tell runitor "when you're about to send a /fail signal, please send /log instead".

[bdd]

@blackscreen
Give the log-only-non-zero branch a try.

My manual testing:

%  ./build/runitor -slug gh-test -log-only-non-zero -- bash -c 'echo "i succeeded"'
%  ./build/runitor -slug gh-test -log-only-non-zero -- bash -c 'echo "i failed" >&2; exit 1'
%  ./build/runitor -slug gh-test -log-only-non-zero -- /nonexistent

yielded:

@cuu508 I'd appreciate a quick code review.

[BeyondVertical]

@blackscreen Give the log-only-non-zero branch a try.

The screenshot looks promising. Is there a build for linux I could download? I am not that familiar with go and building it from scratch. Sorry.

[bdd]

@blackscreen Give the log-only-non-zero branch a try.

The screenshot looks promising. Is there a build for linux I could download? I am not that familiar with go and building it from scratch. Sorry.

Alright. I made a beta release. Binaries for various operating systems and architectures are at https://github.com/bdd/runitor/releases/tag/v0.11.0-beta.1

[BeyondVertical]

Alright. I made a beta release. Binaries for various operating systems and architectures are at https://github.com/bdd/runitor/releases/tag/v0.11.0-beta.1

Thanks. I tested it and it works like a charm.

[cuu508]

Thanks for looking into it so promptly @bdd! The code change looks good to me. I experimented with the beta build too, and it did everything as I was expecting.

If runitor fails to execute the command (e.g. not found, no permission, system ran out of pids, ...) a failure ping is still sent.

A subtle thing that I didn't think of but makes total sense!

-log-only-non-zero can be interpreted two ways:

If the command exits with a non-zero status then log the fact only (do not signal a failure)

or

When inspecting the command's exit status, send a log ping only if the status is non-zero, and send something else in all other cases

Neither interpretation is wrong, so not really a problem. But perhaps -log-non-zero would work too? It is shorter, and to me reads as "if the status is non-zero, then log it".

[bdd]

When inspecting the command's exit status, send a log ping only if the status is non-zero, and send something else in all other cases

Neither interpretation is wrong, so not really a problem. But perhaps -log-non-zero would work too? It is shorter, and to me reads as "if the status is non-zero, then log it".

I spent an order of magnitude more time thinking what this flag should be than writing the code :)

I included "only" in flag's name thinking it'd relay the "log instead of concluding as failure" behavior. Given that it wasn't immediately obvious to you, it's fair to assume I wasn't very successful in naming this. The fact that logging as in sending the output of the command as part of status ping is the default for HC+runitor users, a different type of ping which is also called "log" makes this more challenging.

I plan to cut v0.11.0 release Friday afternoon (Pacific Time). So unless you come up with a different flag name, I'll adopt your recommendation and call it -log-nonzero (notice the drop of hyphenation in "non-zero". Merriam-Webster lists is
as a closed compound word https://www.merriam-webster.com/dictionary/nonzero)

[cuu508]

I think -log-nonzero would work.

A couple other ideas, no strong opinion, naming is hard, –

-tolerate-nonzero or -tolerate-nonzero-status – I think it is intuitive, except it by itself does not explain what "tolerating" means

-report-nonzero-as=log or -nonzero-mode=int|fail|log, where

• int means to use /<uuid>/%d
• fail means to use /<uuid>/fail
• log means to use /<uuid>/log

[BeyondVertical]

-report-nonzero-as=log or -nonzero-mode=int|fail|log, where

• int means to use /<uuid>/%d
• fail means to use /<uuid>/fail
• log means to use /<uuid>/log

That (report-nonzero-as) would be my choice, but I am fine with either one of the mentioned ideas. Naming is really hard, I know that. I am just glad it got implemented so fast. :)

[bdd]

I added the ability to customize the ping type for success, non-zero exit from command, and execution failure cases.

Usage text of the three new flags:

runitor --help |& grep -A 1 -- -on
  -on-exec-fail value
        Ping type to send when runitor cannot execute the command (exit-code|success|fail|log (default fail))
  -on-nonzero-exit value
        Ping type to send when command exits with a nonzero code (exit-code|success|fail|log (default exit-code))
  -on-success value
        Ping type to send when command exits successfully (exit-code|success|fail|log (default success))

Example use for the subject use-case of this issue:

runitor [...] -on-nonzero-exit log -- /opt/bin/flakey

With great flexibility comes great opportunities to do cursed things. So something like this is also possible:

runitor [...] -on-success fail -on-nonzero-exit success -- bash -c "exit ((RANDOM % 2))"

¯\_(ツ)_/¯  

This change slightly modifies runitor's default reporting behavior. I believe in a good way.

• Execution failure now reports "fail" instead of reporting exit status 1. Provides a subtle distinction between command's faults or runitor's troubles.
• Successful execution now reports "success" instead of exit status 0. You get the same green "OK" on the web and no redundant information of "exit status 0".

There is a good chance I missed or broke something. So please test the beta.2 release.

[BeyondVertical]

I tried beta 2 (only the "on-nonzero-exit"-flag) and it works great. I think you found the best solution with the new flags. The cursed things could be good for testing. Great job!

[cuu508]

I tested the new flags in various combinations, and in combinations with the other flags, and all looked good. I like the flag names you picked, not the shortest, but clear and descriptive.

[bdd]

I released v1.0.0 🎉 including this change.