Setting release version in snapcraft build

[Sergio Schvezov]

Readding the list


El 01/09/16 a las 14:27, Casey Marshall escribió:
> On Thu, Sep 1, 2016 at 12:15 PM, Sergio Schvezov 
> <sergio.schvezov at canonical.com <mailto:sergio.schvezov at canonical.com>> 
> wrote:
>
>     El 01/09/16 a las 14:05, Casey Marshall escribió:
>>     When automating the build process for snaps, I'd like to be able
>>     to provide the release version as an argument to snapcraft, which
>>     could then be used as a variable in the snapcraft.yaml.
>>
>>     For example, say I'd like to release "foo" version "1.2.3". I'd
>>     then like to build the snap with version: 1.2.3, and use the git
>>     tag "v1.2.3" in its source. For example:
>>
>>     name: foo
>>     version: ${release-version}
>>     ...
>>     parts:
>>       foo:
>>         source: git at ...
>>     source-tag: v${release-version}
>
>     In 2.16 we are introducing a variable to set this one, it comes
>     from the `version` defined above.
>
>
> That certainly helps, thanks for this!
>
>
>>
>>     The alternatives at the moment seem to be:
>>
>>     1. Parse the version out of snapcraft.yaml, using that as the
>>     authoritative release version string. Workable for new projects,
>>     but a tough sell for existing projects with an established
>>     release process.
>>
>>     2. Generate the snapcraft.yaml from a template (jinja, for
>>     example), which works but is kind of awkward.
>>
>>     So, how about a ${release-version} variable in snapcraft.yaml,
>>     which you could set on the snapcraft command-line with a
>>     --release-version flag? This would be darn useful for Jenkins CI
>>     scripts that build snaps.
>
>     What would the version be set to during CI? The version from a
>     snappy point of view is just a friendly name, the architecture
>     only cares about revisions.
>
>
> Well, I'm thinking of the case where CI knows the release version up 
> front, and wants to set that on the snap it's building.
>
> For example, let's say I've added a snapcraft.yaml to my source tree. 
> I manage my releases by tagging them with a version tag, and then I 
> run a Jenkins job with the release version as a parameter.
>
> This release version is used to check out the source tree at that 
> release version tag, build, run tests, and then build the snap. 
> Jenkins knows the release version it's building, and should be able to 
> set the version in the snap. If I can't, I either have to try to the 
> snapcraft.yaml contents in sync with my release tags, or modify the 
> snapcraft.yaml contents at build time.
>
> So instead, I'd want my Jenkins job to be able to set the version on 
> the command line, something like `snapcraft --version 
> ${RELEASE_VERSION}`. This avoids fragile repetition of release 
> versions (among the tag & snap), or the need for 
> generating/substituting snapcraft.yaml contents in the job.

I think it would be good to behave like dch does and have a `snapcraft 
set-version <version>` command instead.

I let this sit for a bit and see what others think.

In this scenario you'd do

     snapcraft set-version <version>
     snapcraft
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20160901/6adb8e72/attachment.html>