canonical
Error messages when running scriplets make debugging failures difficult
Bug Description
When a part in some snap's snapcraft.yaml includes a scriplet, error messages surrounding failures of that scriplet are "incorrect" in that they do not correspond to problems within the YAML file itself, but instead in some ancillary file which (I presume) snapcraft is creating and then executing during the parts lifecycle event. This means that debugging any given scriplet failure is never deterministically difficult; instead, the difficulty of determining what failed, where it failed, and why it failed can range from 'trivial' (the context surrounding the error easily disambiguates the failure) to 'impossible' (the error message is a nonsequitor, the surrounding context isn't why it failed but instead some earlier part which failed, etc.).
In short: instead of debugging the scriplet in my snapcraft.yaml which is, for all intents and purposes, a shell script, I have to debug the transformation of my scriplet into some nonobvious, unavailable-by-default, created-by-snapcraft script.
To Reproduce
Reproducing the issue is straightforward. The YAML posted below will produce an error of the relevant kind.
To replicate my environment:
snap refresh --channel=7.x/stable snapcraft
snapcraft --use-lxd
Environment
Some variant of Ubuntu 23.04 with snapcraft from 7.x/stable, revision 9542. Build the example snap with snapcraft --use-lxd.
snapcraft.yaml
name: my-snap-name # you probably want to 'snapcraft register <name>'
base: core22 # the base snap is the execution environment for this snap
version: '0.1' # just for humans, typically '1.2+git' or '1.3.2'
summary: Single-line elevator pitch for your amazing snap # 79 char long summary
description: |
This is my-snap's description. You have a paragraph or two to tell the
most important story about your snap. Keep it under 100 words though,
we live in tweetspace and your description wants to look good in the snap
store.
grade: devel # must be 'stable' to release into candidate/stable channels
confinement: devmode # use 'strict' once you have the right plugs and slots
parts:
my-part:
# See 'snapcraft plugins'
plugin: nil
override-build: |
cat >> test.sh << EOF
#!/bin/sh -eux
foo=bar
bar=$baz
EOF
Relevant log output
Starting Snapcraft 7.5.2
Logging execution to '/home/dilyn/.local/state/snapcraft/log/snapcraft-20230921-105432.570321.log'
Running on amd64 for amd64
Cleaning build provider
Cleaned build provider
Starting Snapcraft 7.5.2
Logging execution to '/home/dilyn/.local/state/snapcraft/log/snapcraft-20230921-105434.907064.log'
Running on amd64 for amd64
Launching instance...
Checking for instance 'snapcraft-my-snap-name-on-amd64-for-amd64-2193722' in project 'snapcraft' in remote 'local'
Instance 'snapcraft-my-snap-name-on-amd64-for-amd64-2193722' does not exist.
Checking for base instance 'base-instance-snapcraft-buildd-base-v10--2d55678e0339df02cd48' in project 'snapcraft' in remote 'local'
Creating instance from base instance 'base-instance-snapcraft-buildd-base-v10--2d55678e0339df02cd48'
Starting instance.
Starting Snapcraft 7.5.2
Logging execution to '/tmp/snapcraft.log'
Running on amd64 for amd64
Initializing parts lifecycle
Executing parts lifecycle...
Executing parts lifecycle: pull my-part
Executing action
Executed: pull my-part
Executing parts lifecycle: build my-part
Executing action
:: + cat
:: /bin/bash: line 41: baz: unbound variable
'override-build' in part 'my-part' failed with code 1.
Review the scriptlet and make sure it's correct.
Failed to execute pack in instance.
Full execution log: '/home/dilyn/.local/state/snapcraft/log/snapcraft-20230921-105434.907064.log'
Additional context
Ideally, the error message will at least indicate which line of the YAML is causing the failure. I have no idea how tricky this reverse-engineering would be in practice.
An alternative would be to increase the visibility on build failures to the host machine. Perhaps by including the transformed scriplet which is being executed in the build environment for that part in the generated log file?
