Snapcraft version scripts

doc
41

Did you look at what mkversion.sh does? I mean the whole thing, not just the git command it runs. What was your impression?

We went through the thinking process of making it both look good and be useful, so it’s a good starting point as mentioned above.

42

Yes I have, went into https://github.com/snapcore/snapd/blob/master/mkversion.sh saw the fallback logic and on the same branch above produces something like 3f5c735f+gitdirty. It omits the tags though which I find rather important to keep.

43

@sergiusens Sorry, I’m still having a hard time parsing your feedback or intention. Let me turn this around and tell you what we have and why. This is what I get when running mkversion.sh in the snapd repository:

% ./mkversion.sh 
*** Setting version to '2.23.1+git134.g27f30d5' from git.

So, in order:

  • 2.23.1 is the most recent tag in this tree
  • +git means we’re taking source from a repository rather than a release
  • 134 means how far we are from the tagged version… much better for humans than the next
  • g27f30d5 is the exact revision used, and can probably be omitted in this context as it’s long and ugly
  • dirty is also omitted because it’s ugly and helps little (snap may have changes later anyway)
44

Ok, I think we are on the same page it’s just that if I run that on the snapcraft tree on a clean master I get something like this:

./mkversion.sh 
*** Setting version to '3f5c735f' from git.

And it seems to be due to git describe missing --tags to match the way we are tagging. That said, I will start using annotated tags from now on.

So I agree with the objective :wink: Thanks for approaching this the other way around.

1 Like
45

Here’s the PR that implements version: git support:

https://github.com/snapcore/snapcraft/pull/1260

The tests should be rather informative on how the mechanics work.

46

This only covers the case where the snapcraft.yaml is in the git repo whose version you care about, right?

47

Right, more PRs will follow with the other stuff; please see if my edit of the original post (converted to wiki) still satisfies your needs.

48

Ah yes, that looks great (I follow the forum in mailing list mode, so I wasn’t aware of the edits). Thanks!

49

Version override support through version-script is here.
https://github.com/snapcore/snapcraft/pull/1267

50

Did this feature get documented? It seems to be released in snapcraft 2.29 but I can’t find anything in the snapcraft.io documentation.

51

The current implementation is a little problematic and confusing. In my understanding version-script supersedes the existing and mandatory version field but when I use the environment variable SNAPCRAFT_PROJECT_VERSION in a plugin, its value refers to the previously superseded field, version.

Think of a case where dump plugin downloads a zip file from a dynamic URL based on the version number. Currently this results in a practically static URL because SNAPCRAFT_PROJECT_VERSION always refers to the hard-coded value of version field.

I have a packaging example here that elaborates the issue I am talking above.

A simple solution in my opinion would be to to call version-script block at the very start and export its returned value as SNAPCRAFT_PROJECT_VERSION.

52

The reason is, version-script was created to set a version in the metadata from information set from built sources, you are trying to use it the other way around, this won’t be possible with this implementation, ever.

It may find its way when the pre and post work taking into account the setting of metadata through setters takes place (Scripting and setting metadata in snapcraft), that work should start to be surfaced around January.

53

Hi @sergiusens. I don’t think this behaviour has been documented on the main site yet, and does seem to be slightly broken as per https://bugs.launchpad.net/snapcraft/+bug/1769519 . Would it be possible to patch the behaviour to deal with invalid characters such as underscores in git tags?

1 Like