On Thu, Sep 1, 2016 at 7:40 PM, Sergio Schvezov
<sergio.schve...@canonical.com> wrote:
> 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.schve...@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@...
>> 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
That would work for me too. Is there a bug report I can subscribe to
to follow progress/implementation?
--
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/snapcraft
