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?
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:-
echo $(git describe --tags)
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
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.
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).
Neither is required if you use