[bug#40993] cuirass: Add build products download support.

[Ludovic Courtès]

Hello!

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

> Here's a patch adding support for build products downloading in
> Cuirass. It is inspired by a similar mechanism in Hydra.

Neat!

> Attached a screenshot of what I obtained with the following
> specification:
>
> (define hello-master
>   '((#:name . "guix-master")
>     (#:load-path-inputs . ())
>     (#:package-path-inputs . ())
>     (#:proc-input . "guix")
>     (#:proc-file . "build-aux/cuirass/gnu-system.scm")
>     (#:proc . cuirass-jobs)
>     (#:proc-args (subset . "all"))
>     (#:inputs . (((#:name . "guix")
>                   (#:url . "https://gitlab.com/mothacehe/guix";)
>                   (#:load-path . ".")
>                   (#:branch . "master")
>                   (#:no-compile? . #t))))
>     (#:build-outputs . (((#:job . "iso9660-image*")
>                          (#:type . "iso")
>                          (#:output . "out")
>                          (#:path . ""))))))

For the record, in Hydra, build products would be found if there’s a
special ‘nix-support/hydra-build-products’ file in the output.  The
advantage is that it’s more flexible, but the downside is that you’d
have to adjust your derivations specifically for that.

>>From dbb78929d7c8aa3b9007660795f55232ab47dbfb Mon Sep 17 00:00:00 2001
> From: Mathieu Othacehe <m.othacehe@gmail.com>
> Date: Fri, 1 May 2020 10:32:18 +0200
> Subject: [PATCH] Add support for build products downloading.
>
> * src/sql/upgrade-7.sql: New file.
> * Makefile.am: Add it.
> * src/cuirass/base.scm (create-build-outputs): New procedure,
> (build-packages): call it,
> (process-spec): add the new spec argument and pass it to create-build-outputs.
> * src/cuirass/database.scm (db-add-build-product, db-get-build-product-path,
> db-get-build-products): New exported procedures.
> * src/cuirass/http.scm (respond-static-file): Move file sending to ...
> (respond-file): ... this new procedure,
> (url-handler): add a new "download/<id>" route, serving the requested file
> with the new respond-file procedure. Also gather build products and pass them
> to "build-details" for "build/<id>/details" route.
> * src/cuirass/templates.scm (build-details): Honor the new "products" argument
> to display all the build products associated to the given build.
> * src/schema.sql (BuildProducts): New table,
> (Specifications)[build_outputs]: new field.
> * tests/database.scm: Add empty build-outputs spec.
> * tests/http.scm: Ditto.
> * examples/guix-jobs.scm: Ditto.
> * examples/hello-git.scm: Ditto.
> * examples/hello-singleton.scm: Ditto.
> * examples/hello-subset.scm: Ditto.
> * examples/random.scm: Ditto.
> * doc/cuirass.texi (overview): Document it.

[...]

> +  (map (lambda (spec)
> +         (let* ((build (find-build (assq-ref spec #:job)))
> +                (product (find-product build spec)))
> +           (when (and product (file-exists? product))
> +             (db-add-build-product `((#:build . ,(assq-ref build #:id))
> +                                     (#:type . (assq-ref spec #:type))
> +                                     (#:file-size . ,(file-size product))
> +                                     ;; TODO: Implement it.
> +                                     (#:sha256-hash . "")
> +                                     (#:path . ,product))))))
> +       product-specs))

Use ‘for-each’ if it’s for effects, as seems to be the case.

Regarding #:sha256-hash: there’s a somewhat standard format to represent
hashes and their algorithms as strings, but I forgot the name.  Like,
you’d write “sha256-” followed by a base64 string, something like that.

Perhaps it’d be wiser to use it rather than hard-code sha256?

Also, we don’t really have tests for the web UI, I don’t know how much
work it’d be to add tests.

Apart from that, I have little to say, other than the fact that it’s
really cool.  :-)

Thank you!

Ludo’.