From: Olivier Dion via <gwl-devel@gnu.org>
To: Ricardo Wurmus <rekado@elephly.net>
Cc: gwl-devel@gnu.org
Subject: Re: [PATCH] tests/examples: Add running of workflow examples
Date: Fri, 29 Apr 2022 17:05:50 -0400 [thread overview]
Message-ID: <87sfpva9ch.fsf@laura> (raw)
In-Reply-To: <87sfpvzkmj.fsf@elephly.net>
On Fri, 29 Apr 2022, Ricardo Wurmus <rekado@elephly.net> wrote:
> Hi Olivier,
>
> thanks for the patch!
>
>> End to end testing of pre-defined scenarios are a good way to check for
>> regression.
>>
>> Here we introduce testing of some examples available in the documentation. That
>> way, we're sure that new users should be able to run them without problems.
>>
>> Each scenario is a different test and is run in a different temporary
>> directory which get destroyed if the scenario succeeded.
>
> It’s a good idea to run the examples. However, this requires a fully
> functional Guix installation (which we don’t have when building with
> Guix, for example), so we should not include them in “make check” but
> add a separate target for these tests. An alternative may be to do what
> Guix does for system tests, but I’d be okay with just having a separate
> target that is run manually before releases or in CI.
>
>> +(define-syntax-rule (with-directory-excursion dir body body* ...)
>> + (let ((old-dir (getcwd)))
>> + (dynamic-wind
>> + (lambda () (chdir dir))
>> + (lambda () body body* ...)
>> + (lambda () (chdir old-dir)))))
>> +
>> +(with-directory-excursion
>> + (string-append top-srcdir "/doc/examples")
>> +
>> + (define (process-success? status)
>> + (= 0 (or (status:exit-val status)
>> + (status:term-sig status))))
>
> Use ZERO? here.
I learn everyday with you. I did not know about it ^^.
>> + (define scenarios
>> + (list "extended-example-workflow.w"))
>
> Should these better be discovered automatically via SCANDIR?
Well some example are not full workflow. Only processes. So I think that
yes, if we set a common prefix for full workflow:
(scandir "." (cut string-prefix "exemple-workflow" <>))
However, it's nice -- even more true when debugging -- to be able to
cherry-pick the tests. This is easier with the list above by commenting
tests that are passing.
>> + (for-each (lambda (example)
>> + (test-assert example
>> + (let* ((tmp-dir (mkdtemp
>> + (format #f "gwl-example-~a.XXXXXX" example)))
>> + (abs-example (canonicalize-path example))
>> + (success?
>> + (with-directory-excursion tmp-dir
>> + (process-success?
>> + (system
>> + (format #f "guix workflow run -fc ~a -l all"
>> + abs-example))))))
>
> Please don’t use SYSTEM. How about
>
> (system* "guix" "workflow" "run" "--force" "--container"
> "--log-events=all" (canonicalize-path example))
Yes I like it better too thanks.
>> + (if success?
>> + (system* "rm" "-rf" tmp-dir)
>
> Why shell out to RM when we have DELETE-FILE and its recursive friend in
> Guix? I’d also rather move clean-up work to a DYNAMIC-UNWIND handler.
I hesitated to include Guix's module in test. If you're okay with it, I
will use the helpers available in Guix. I concur that the cleanup
should be in dynamic-unwind.
>> + (format (error-output-port)
>> + "Example directory: ~a\n" tmp-dir))
>
> Nitpick: ~% instead of \n.
Is there a reason why? I don't mind I just never really understood why
scheme has this special format rule for newline.
>> + success?)))
>> + scenarios))
>
> This FOR-EACH loop combines test definition with test running, which
> seems wrong to me. Maybe SRFI-64 is not the best fit for tests that
> only care about whether a shell command was run successfully. Perhaps
> we should do as Guix does and just have a shell script to run these
> tests.
What do you find wrong about it? We could re-write it as:
(define (run-example path)
...)
(test-assert (run-example "extended-workflow.w"))
(test-assert (run-example "..."))
if you like it better. However, we lose the power of SCANDIR mentioned
above.
Let me know, I will send a v2 with your above recommendations and answers
to my questions.
--
Olivier Dion
oldiob.dev
next prev parent reply other threads:[~2022-04-29 21:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-29 17:55 [PATCH] tests/examples: Add running of workflow examples Olivier Dion
2022-04-29 20:32 ` Ricardo Wurmus
2022-04-29 21:05 ` Olivier Dion via [this message]
2022-05-07 6:46 ` Ricardo Wurmus
2022-05-07 16:47 ` [PATCH v2] " Olivier Dion
2022-06-03 9:06 ` Ricardo Wurmus
2022-06-03 13:11 ` Olivier Dion via
2022-06-03 15:46 ` Ricardo Wurmus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sfpva9ch.fsf@laura \
--to=gwl-devel@gnu.org \
--cc=olivier.dion@polymtl.ca \
--cc=rekado@elephly.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.