Setting custom envrionment variable based on architecture

Is there a way to set a custom environment variable within snapcraft yaml that my plugins could use based on the CPU architect ?

I want this url to be dynamic based on an environment variable that I set.

As of Snapcraft v2.36 you can use the SNAPCRAFT_ARCH_TRIPLET environment variable.

Let me rephrase my use case. I want the simplest way to format this url: https://download.sublimetext.com/sublime_text_3_build_3143_x64.tar.bz2

I am currently replacing 3143 which is the “build number” using the version field (env: SNAPCRAFT_PROJECT_VERSION). I also want to replace that x64 based on the CPU arch (x64 vs x32). What options do I have ?

You have to wait for these to complete:

What exactly is:
SNAPCRAFT_ARCH_TRIPLET

I’ve googled it and the only result that comes up is your post to this forum?

As of v2.36, Snapcraft exports the $SNAPCRAFT_ARCH_TRIPLET into the environment when creating snaps. For example:

name: my-snap-name # you probably want to 'snapcraft register <name>'
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
    build: echo "I'm running on $SNAPCRAFT_ARCH_TRIPLET"

Building that results in:

$ snapcraft build
Preparing to pull my-part 
Pulling my-part 
Preparing to build my-part 
Building my-part 
I'm running on x86_64-linux-gnu

This can be used in your YAML or in plugins as appropriate. Note that it is not usable at runtime, however (i.e. when the snap is installed and running).

1 Like

For the record this is how I solved the problem.
Note ‘tomcat-launch’ was the original launcher (providered by a third party plugin), so my new launcher effectively chains the original tomcat-launcher.
The plugin essentially writes out the new laucher which does the check for which architecture the app is running on and sets the appropriate environment vars.

apps:
  pi-gation:
  command: pi-gation-launch
  daemon: simple
  plugs: [network, network-bind]

pi-gation-launch:
  plugin: dump
  install: |
    cat <<EOF > $SNAPCRAFT_PART_INSTALL/pi-gation-launch
    #!/bin/sh
    ARCH=`uname -m`
    if [ "$SNAP_ARCH" = "arm64" ] || [ "$SNAP_ARCH" = "armhf" ]; then
        # no action require.
    else 
        # Run the simulator as we are not on RPi hardware
        export PI4J_PLATFORM="Simulated"
        export SimulatedPlatform="RaspberryPi GPIO Provider"
    fi
    ./tomcat-launch
    EOF
    chmod +x $SNAPCRAFT_PART_INSTALL/pi-gation-launch

Ah, so you need it at runtime. Yeah, using $SNAP_ARCH in some way is perfect.