Supported snap hooks

What’s the precise context in which a hook is run? I’d like a post-refresh hook run git-ubuntu.self-test (self-test is defined in snapcraft.yaml as an app) to verify that the new snap will work correctly. self-test already has a carefully defined environment that matches the main git-ubuntu app’s environment precisely. How can I ensure that when I invoke this from the post-refresh hook, the context is identical? Do I need to manually set the environment from inside the hook to the same as that defined in snapcraft.yaml against self-test? Or is there a better way?

Yes

Unfortunately not, what can make this slightly better is that if you don’t use the environment keyword for your self-test app, and do all setup except for running the app itself inside a script, you can then specify that script as a command-chain which can be shared between the app and the post-refresh hook with yaml like this:

hooks:
  post-refresh:
    command-chain:
      - setup-self-test-env.sh
apps:
  self-test:
    command: do-the-test.sh
    command-chain:
      - setup-self-test-env.sh

then in your post-refresh hook you just call do-the-test.sh directly. Alternatively, you could make the post-refresh file itself a symlink to do-the-test.sh if you don’t need to do anything else in the post-refresh hook

1 Like

One thing I do not see documented is when to these hooks run relative to others and if the run before or after interfaces are connected

1 Like

also before or after services are started for i.e. first boot of an ubuntu core system with the snap seeded or just for initial installation

Hi @sergiusens

do you have information about this? We ran into some trouble during first boot on this.
We have a required snap that runs an install hook. Is this hook executed before or after the auto-connected interfaces?

Particularly we want to create a folder structure for a content-interface before any snap can write to this location. Both snaps are required snaps during image build. Currently we have this logic in the install hook of the slot snap.

Can we use an install hook to prompt the user for things like username and password in order to log into a service? If not, what approach do you suggest? :blush:

I would suggest merging the mentioned page with this. So much information is accumulating about snaps, and every time I find very difficult to find what I need :confused: I really like snaps, but as the complexity is growing, the documentation is becoming overwhelming :frowning_face:

This page seems to be missing any mention of the “check-health” hook.

This is because the feature isn’t yet fully implemented (see Health Checks). While some parts do work, such as using snapctl set-health and the health status appearing in the output from snap info, I don’t think the store yet has the functionality to process any health status. This is why we’ve held off documenting this fully and the hook specifically.

The explanation of install-device hook versus prepare-device hook seems confusing. install-device hook is described as supported only in UC20 gadget snaps, while prepare-device claims only in gadget snaps (not just UC20? is that deliberate?).

In addition, even though both hooks are defined in the gadget snap, for install-device, you’re referred to the “Installation process” page, while for prepare-device, you’re sent to “The gadget snap” page. This seems unnecessarily scattered; why are these two apparently related hooks not explained in the same place?

How do I access previous state of the snap from post-refresh hook? $SNAP will give me the current state but I want to access the state before the refresh and compare a file between the 2 states.

Another glaring omission is any mention of command-chain usage (which is supported) for hooks. It probably belongs on this page, unless it makes more sense to add to the main snapcraft yaml referrence page.

There is apparently a “check-health” hook that I only now just noticed. https://github.com/snapcore/snapd/blob/master/snap/hooktypes.go#L38

@degville this doc mentions that configure hooks that exit non-zero prevent an install of the respective snap (or cause a rollback) this is actually true for all hooks involved in any interface autoconnection too, not only for configure or default-config … could we have a paragraph or note on this ?

Thanks for letting me know, and yes of course. I’ll make sure one is added (and reply here when it’s done).

Update 6th July 2023: I just added the auto-interface rollback details. Thanks for the suggestion!

If the main purpose of the default-configure hook is to get access to the default config info in the gadget snap, should it not be run again if the gadget snap is updated? After all, updating the gadget snap could change that config info.

This section https://snapcraft.io/docs/supported-snap-hooks#heading--the-configure-hook claims that the configure hook is called under three circumstances, but I’m fairly sure it’s also called via the appropriate snapd REST API call, no? Can you confirm that?

You mean the equivalent API call for, eg., refresh? I’m certain this is the case, yes. If this is what you mean, I’ll tweak the text to make it clearer.

Yup, this: Snapd REST API

Should this indicate that the configure hook is run before services start?

The following mentions that both starting services and the configure hook run after the install hook, so the absence of anything explicit in the configure hook is suggestive that there is no guarantee whether configure or services run first.