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

snap
1

Hello there,

our snap build fails recently https://travis-ci.org/ubuntu/yaru/builds/454222505#L2378

@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: https://github.com/ubuntu/yaru/blob/master/build-helpers/gtk-common-themes-parts.yaml )

How can we disable that feature for us?

Best regards,
Frederik

1 Like
2

In https://github.com/ubuntu/yaru/blob/master/build-helpers/prepare-build-snap#L46 you curl -o snap/snapcraft.yaml "https://gitlab.gnome.org/Community/Ubuntu/gtk-common-themes/raw/master/snap/snapcraft.yaml" and build it.

https://gitlab.gnome.org/Community/Ubuntu/gtk-common-themes/raw/master/snap/snapcraft.yaml 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. https://gitlab.gnome.org/Community/Ubuntu/gtk-common-themes/blame/master/snap/snapcraft.yaml recently.

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

3 Likes
3

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

4

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
5

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

6

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.

7

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

https://github.com/ubuntu/yaru/issues/953

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
8

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