How we disable to automatically look for the version number in our Yaru-snap build?

Hello there,

our snap build fails recently

@didrocks thinks, that the build fails because of a new snap feature to determine the version number automatically.
We don’t want to change the version number of gtk-common-themes when building a Yaru PR or master (probably something to add in the snapcraft.yaml we inject: )

How can we disable that feature for us?

Best regards,

1 Like

In you curl -o snap/snapcraft.yaml "" and build it. contains the following:-

version: git
version-script: |
  echo $(git describe --tags)

The version: git assumes the yaml is in-tree, which it isn’t if you’re just curling the yaml and building.

So it’s working as designed. Gitlab says @kenvandine changed that. recently.

So either clone the entire repo and build, or request that @kenvandine do the version detection differently ( via adopt-info perhaps).


Hi @popey, thank you for the reply.
My understanding is that this version-script part only prints debug information, so I guess we can simply remove it from the generated yaml

No. It doesn’t “just print”. It’s called in order to print the git tag, which becomes the version number stamped on the snap. However, it’s a bit odd to have both version: git and version-script in the same snap. Typically you have one or the other.

1 Like

If I recall correctly, version is required even with version-script.

In the case of gtk-common-themes we don’t want to get the version based on a part. We really want it based on the git repository of gtk-common-themes. I’ve just pushed a fix that will give you a valid version even if git describe fails. This should satisfy the Yaru CI builds as well as gtk-common-themes snap builds.

This is the kind of thing I was concerned about when I filed this bug report:

The way Yaru’s CI is trying to build gtk-common-themes essentially uses a frankenstein combination of two snapcraft.yaml files. One half comes from the gtk-common-themes repository and is gated by that project’s CI, and the other half is a patch in the Yaru repository.

My preferred solution is to have Yaru’s CI stop trying to build gtk-common-themes, and instead trigger that project’s CI to perform a rebuild. We just need to get the pieces in place to make this possible (in particular, having the gitlab CI build against a non-default branch of Yaru).

1 Like

Neither is required if you use adopt-info :smiley: