Solved: Wondering about building from GitHub using semantic versioning

I have a maven project that builds via GitHub action, and it uses semantic versioning to uniquely identify the build output. It is provided as generic zip and tgz files as well as native installers for Debian, Windows and MacOS.

Now I want to add snap building, too. It seems here I need to hand over control to snapcraft.io which listens to changes in my GitHub repository and builds on it’s own. But how do I ensure the correct semantic versioning is being used? After all I use gitversion to automatically calculate the version, and it ripples through my GitHub actions workflow via environment variables.

How can this version number be communicated to the snapcraft build?

Can you use the build-environment keyword in the part definition to inject the version using an environment variable?

You can build on Github directly (for AMD64 architectures) with the build and publish actions.

If you’re talking about the snaps own metadata (the version: field) then you can set it programatically like so:

  1. Set the adopt-info: field to point to the part-name that is responsible for setting the version, e.g:

adopt-info: my-part

  1. In my-part, add custom logic that runs craftctl, e.g a practical example from one of my own snaps:
override-build:
  craftctl default
  minor_version=$(git describe --tags --abbrev=0 | grep -Eo "[0-9]*-[0-9]*-[0-9]*" | cut -d "-" -f 2)
  patch_version=$(git describe --tags --abbrev=0 | grep -Eo "[0-9]*-[0-9]*-[0-9]*" | cut -d "-" -f 3)
  if [ $(( 10#$minor_version % 2 )) -eq 0 ] && [ $(( 10#$patch_version % 2 )) -eq 0 ]
      then
        craftctl set grade=stable
        craftctl set version="$(git describe --tags --abbrev=0)"
      else
        craftctl set grade=devel
        craftctl set version="$(git rev-parse --short HEAD).$(date -u +%d-%m-%y)"
  fi

Where it the version will be either the tag responding to the git commit, or it’s hash + current date if there isn’t one for the exact commit you’re building.

craftctl works for Core22 snaps but previous releases use a slightly different format that you might need to look around on the forums for examples for (iirc, snapcraftctl)

They are marvellous. It did not take too many attempts to build and publish the snap from GitHub.

This seems a bit more complex - at least I do not fully understand. But since the build on the GitHub side works now I am no longer worried.

Thank you for your help! :slight_smile: