sanity validation for `cmd` installation hook commands

[mrkz]

As per the YAML installer syntax refers, there's a cmd item available for the Installation Hooks part where one can place commands to be run at certain points of the image creation.

However, it's a bit troublesome to have commands that might be:

• typos
• inexistent on image-builder host (e.g: xz command missing)

I suggest that there's a simple sanity validation of such commands being available prior to the image creation, so the image build fails earlier in the process instead of at the post-image processing part.

Something as simple as:

• command does not start with / or ${yamlDir} assume it's $PATH referred and look it exists.
• command starts with ${yamlDir} and it's clearly a file, the verify such file exists (and it's executable?).

would suit my needs of fail early and not to wait longer for image creation due to missing script or even typos on commands :disappointed:

post-install: [
   {cmd: "${yamlDir}/installer-post.hs ${chrootDir}"}
]

post-image: [
   {cmd: "zx -q -T0 --stdout ${imageFile} > ${imageFile}.xz"}
]

On the example above, clearly, misstyping zx when referring to xz and another typo on the file type hs -> sh

simply by checking file exists would be enough :smiley:

[mdhorn]

@mrkz I don't think we can safely sanity check these commands, sorry. First, the command could be executed in a chroot; we have way to predict what might be in the chroot. Second, the command can be anything bash syntax allows, so how does one sanity check that?

[mdhorn]

Besides the previous comments, the build process itself could be creating the commands that would be run for the post-install or post-image hooks.

I understand it is challenging to get a failure late in the flow, but I don't see any obvious checks we can add that be useful and not prevent some desired usage models.

If you have specific examples that would apply the general case, please reopen and note what specifically could be done.