Environment variables

There’s a grammar mistake in SNAP_COMMON:

“Unlike SNAP_DATA this directory does is not backed up”

1 Like

Fixed - thank you for letting us know!

1 Like

It’s pretty cool to be able to list these environment variables, but how can we edit them? I want to pass a specific JAVA_HOME to gradle, but I have a hard time finding any information about this in the documentation…

Thanks for asking this question. I’ll try to make this information easier to find, but you should be able to pass a specific JAVA_HOME using build-environment within the part, eg:

    plugin: gradle
    [...]
    build-environment:
      - JAVA_HOME: /usr/lib/jvm/java-11-openjdk-amd64

This behaviour is briefly discussed here:

Another useful tip is to search GitHub for projects trying to do the same thing: https://github.com/search?q=filename%3Asnapcraft.yaml+%22plugin%3A+gradle%22+%22JAVA_HOME%22&type=Code

1 Like

@degville With snapd 2.57 a new variable has been introduced on ubuntu core systems.

SNAP_SAVE_DATA

Points to a snap-specific location on the ubuntu-save partition where the snap is allowed to store persistent files (like certificates or configuration files) which will survive a factory reset. The variable is only exposed on Ubuntu Core systems, and was introduced with snapd 2.57

2 Likes

Thanks Philip! I’ve updated the doc to include your definition.

2 Likes

I would like to improve the description of this environment variable as per Where to store config files but I can’t figure out the proper words, please help fix it.

This directory is suitable to store potentially backward-incompatible data as the data is backed up and restored across snap refresh and snap revert operations so the users can restore the application to its previous state even if the data breaks its newly released revisions.

What do you think about this?

I believe this part is incorrect as snapd only guarantees that if data incompatibility issues occur you can rollback to the previous working unmodified data and software(to the extent that the previous data hasn’t dropped by the rotation logic).

When a snap is refreshed the SNAP_USER_DATA of the previous snap revision gets duplicated to the new revision, not cleared.

That’s true! What about this?

The “This makes sure the older version of your application doesn’t use newer, backwards-incompatible, data.” part seems to be ambiguous IMO, how about the following instead:

1 Like

Today, https://github.com/snapcore/snapd/pull/12565 was merged, which adds two new environment variables:

SNAP_UID: the UID number of the user running this snap instance
SNAP_EUID: the Effective UID of the user running this snap instance

Please, add it to the documentation.

Thanks so much for letting us know. I’ve added these, and reformatted this page slightly to hopefully make it easier to navigate.

1 Like

This should specify that they exist only since 2.59.1 and have a corresponding “assumes” as well snap-uid-envvars

Thank you! I’ve added this to the above doc.

I think it could be useful if the parts of this doc regarding data storage would be in a dedicated documentation (maybe linked here). Newcomers to snapcraft might not understand where they can and cannot store data on with their snap. I believe a doc similar to the android one would help.

Thanks - and that’s a good idea. In particular, I’ve been having discussions about SNAP_USER_COMMON and snapshots - what’s stored against a specific revision. So, we do need to revisit this, and splitting out data storage makes sense.

1 Like

Under SNAP_USER_COMMON, one reads:

“Directory for user data that is common across revisions of a snap.”

Unlike SNAP_DATA, …"

Why are you contrasting SNAP_USER_COMMON with SNAP_DATA? As opposed to, perhaps, SNAP_USER_DATA?

You’re absolutely right - thanks for the suggestion.

It’d be nice to have a SNAP_BASE variable with the name of the base snap used.

The LXD team maintains 3 tracks (4.0, 5.0 and latest) and each of those depend on a different base snap (core2x). Since we have scripts needing to know which base is used, having that variable would make it easier to backport changes between those tracks.

Our current approach is to dynamically look that up like that:

# Detect base name
SNAP_BASE="$(sed -n '/^name:/ s/^name:\s*\(core[0-9]\{2\}\)/\1/p' /meta/snap.yaml)"

But that’s not ideal.