mte/unikernel/duniverse/dune_/test/blackbox-tests/test-cases/actions/action-stdxxx-on-success.t

Test for --action-stdxxx-on-success
====================================

  $ export BUILD_PATH_PREFIX_MAP="sh=$(command -v sh):$BUILD_PATH_PREFIX_MAP"

  $ echo '(lang dune 3.0)' > dune-project

  $ cat > dune <<EOF
  > (rule
  >  (alias default)
  >  (action (system "echo 'Hello, world!'")))
  > 
  > (rule
  >  (alias default)
  >  (action (system "echo 'Something went wrong!' >&2")))
  > 
  > (rule
  >  (alias both-stdout-and-stderr-output)
  >  (action (system "echo stdout; echo stderr >&2")))
  > EOF

By default, stdout and stderr are always printed:

  $ dune build
  Hello, world!
  Something went wrong!

swallow tests
-------------

  $ dune clean
  $ dune build --action-stdout-on-success=swallow --action-stderr-on-success=swallow

must-be-empty tests
----------------------

In the two above tests, we ask Dune to enforce that the the stdout
(resp. stderr) of actions is empty via the must-be-empty setting.
Since the first rule has a non-empty stdout and the second has a
non-empty stderr, we observe that in each case the build fails
printing the output of the action that had a non-empty output.

  $ dune clean
  $ dune build --action-stdout-on-success=must-be-empty
  Something went wrong!
  File "dune", lines 1-3, characters 0-65:
  1 | (rule
  2 |  (alias default)
  3 |  (action (system "echo 'Hello, world!'")))
  Hello, world!
  [1]

  $ dune clean
  $ dune build --action-stderr-on-success=must-be-empty
  Hello, world!
  File "dune", lines 5-7, characters 0-77:
  5 | (rule
  6 |  (alias default)
  7 |  (action (system "echo 'Something went wrong!' >&2")))
  Something went wrong!
  [1]

Same but with output on both stdout and stderr:

  $ dune clean
  $ dune build @both-stdout-and-stderr-output \
  >    --action-stdout-on-success=must-be-empty \
  >    --action-stderr-on-success=must-be-empty
  File "dune", lines 9-11, characters 0-95:
   9 | (rule
  10 |  (alias both-stdout-and-stderr-output)
  11 |  (action (system "echo stdout; echo stderr >&2")))
  stdout
  stderr
  [1]


Incremental builds
------------------

Dune handles --action-stdxxx-on-success in such a way that if
changing the status of one of the two option changes what is printed
to the terminal, then the action is re-executed.

  $ dune clean
  $ dune build \
  >   --action-stdout-on-success=swallow \
  >   --action-stderr-on-success=swallow

For instance, if we previously swallowed stdout/stderr and stop doing
it, actions that printed something to stdout or stderr are
re-executed:

  $ dune build
  Hello, world!
  Something went wrong!

However, we currently re-execute too much. In particular, we
re-execute actions whose outcome is not affected by the change:

  $ cat > dune <<EOF
  > (rule
  >  (alias default)
  >  (action (system "echo a.stdout; echo a.stderr >&2")))
  > 
  > (rule
  >  (alias default)
  >  (action (system "echo b.stderr >&2")))
  > EOF

  $ dune clean
  $ dune build --action-stdout-on-success=swallow
  a.stderr
  b.stderr

You can observe in the below call that both actions are being
re-executed:

  $ dune build
  a.stdout
  a.stderr
  b.stderr

However, re-executing the second action was not necessary given that
its stdout was empty. Dune could have recorded the fact that the
second action had an empty stdout and so was unaffected by the status
of --action-stdout-on-success. Dune could also cache the
stdout/stderr of actions across builds and only re-print them rather
than re-execute actions entirely.

In case of errors
-----------------

In case of errors, we print everything no matter what.

  $ cat > dune <<EOF
  > (rule
  >  (alias default)
  >  (action (system "echo 'Hello, world!'; exit 1")))
  > EOF

  $ dune build
  File "dune", lines 1-3, characters 0-73:
  1 | (rule
  2 |  (alias default)
  3 |  (action (system "echo 'Hello, world!'; exit 1")))
  Hello, world!
  [1]

  $ dune clean
  $ dune build --action-stdout=swallow
  File "dune", lines 1-3, characters 0-73:
  1 | (rule
  2 |  (alias default)
  3 |  (action (system "echo 'Hello, world!'; exit 1")))
  Hello, world!
  [1]

  $ dune clean
  $ dune build --action-stdout=must-be-empty
  File "dune", lines 1-3, characters 0-73:
  1 | (rule
  2 |  (alias default)
  3 |  (action (system "echo 'Hello, world!'; exit 1")))
  Hello, world!
  [1]

With compound actions
---------------------

At the moment, the behavior is a bit odd. We swallow the stdout of the
first command but not the second:

  $ cat > dune <<EOF
  > (rule
  >  (alias default)
  >  (action
  >   (progn
  >    (system "echo 1")
  >    (system "echo 2; exit 1"))))
  > EOF

  $ dune build --action-stdout-on-success=swallow
  File "dune", lines 1-6, characters 0-93:
  1 | (rule
  2 |  (alias default)
  3 |  (action
  4 |   (progn
  5 |    (system "echo 1")
  6 |    (system "echo 2; exit 1"))))
  2
  [1]

For must-be-empty, if two programs print something without failing we
stop at the first program. That's not terrible, but it would seem
better if we stop at the end of the whole action.

  $ cat > dune <<EOF
  > (rule
  >  (alias default)
  >  (action
  >   (progn
  >    (system "echo 1")
  >    (system "echo 2"))))
  > EOF

  $ dune build --action-stdout-on-success=must-be-empty
  File "dune", lines 1-6, characters 0-85:
  1 | (rule
  2 |  (alias default)
  3 |  (action
  4 |   (progn
  5 |    (system "echo 1")
  6 |    (system "echo 2"))))
  1
  [1]

With builtin actions
--------------------

We currently never swallow the output of builtin actions such as
`echo`, which is odd:

  $ cat > dune <<EOF
  > (rule
  >  (alias default)
  >  (action (echo "Hello, world!\n")))
  > EOF

  $ dune build --action-stdout-on-success=swallow
  Hello, world!