Set snap version dynamically according to Gemfile version

snapcraft
1

Hi, I noticed that the Travis snap package is out of date, likely because they need to bump the version manually.

They already bump the version manually on their Gemfile (it’s a Ruby app). I would like to write a patch so that snapcraft can read the version number from such Gemfile instead of having a fixed value.

So I was thinking to edit the snapcraft file like this:

name: travis
version: nil
summary: Travis CI client
description: CLI and Ruby client library for Travis CI

grade: stable

confinement: strict

apps:
  travis:
    command: travis
    plugs: [network, home, removable-media]

parts:
  travis:
    plugin: ruby
    build-packages: [wget]
    override-build: |
      snapcraftctl build
      GEM_VERSION=`ruby -e 'require "rubygems"' -e 'puts Gem::Specification::load("travis.gemspec").version'`
      snapcraftctl set-version $GEM_VERSION
      GEM_VERSION=v$GEM_VERSION
      wget  "https://github.com/travis-ci/travis.rb/archive/$GEM_VERSION.tar.gz"
      mv $GEM_VERSION.tar.gz $SNAPCRAFT_PART_SRC
      gem build travis.gemspec
      gem install travis-*.gem --env-shebang
    prime: ['-lib/ruby/gems/*/gems/ffi-*/ext/ffi_c/libffi-*/include/ffitarget.h']
    stage-packages: [git]

Questions:

  1. Instead of override pull can I set the source dynamically? Like
source: https://github.com/travis-ci/travis.rb/archive/`$GEM_VERSION`.tar.gz
2

Update

I managed to make it work, however, the version remains nil. Do you know why? I’m thinking it’s because I’m setting it in the build stage, but I’m not sure. Also, I cannot set it in the pull stage as ruby is not yet installed at that time. Some help?

Edit

I needed to remove version and set adopt-info: travis, where travis is the name of the part that sets such info

Pull request pending

3

There is currently no support for variables like that in the source field.

1 Like
4

Too bad, it would make thigs much more easier, but I imagine it would also make the parsing much more complicated :confused:

A possible idea, to eventually consider if such variable replacing mechanism was also useful in other scenarios, is to use a template mechanism. So you parse the template first, which replaces the variables, and you produce the yaml, to be parsed from snapcraft. Actually, I think it could work even today, without modifications, using something like Jinja to parse the template and then using running snapcraft on the produced yaml :slight_smile: Just thinking aloud :wink: