<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Readding the list<br>
</p>
<br>
<div class="moz-cite-prefix">El 01/09/16 a las 14:27, Casey Marshall
escribió:<br>
</div>
<blockquote
cite="mid:CAC=ruh1QsC6psGwyCsJb8_9cZ0XGcdRcaF+eGijcor7JeOSn-w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Thu, Sep 1, 2016 at 12:15 PM,
Sergio Schvezov <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:sergio.schvezov@canonical.com"
target="_blank">sergio.schvezov@canonical.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> El 01/09/16 a las
14:05, Casey Marshall escribió:<span class=""><br>
<blockquote type="cite">
<div dir="ltr">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.
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div><font face="monospace, monospace">name: foo</font></div>
<div><font face="monospace, monospace">version:
${release-version}</font></div>
<div><span style="font-family:monospace,monospace">...</span><br>
</div>
<div><span style="font-family:monospace,monospace">parts:</span><br>
</div>
<div><font face="monospace, monospace"> foo:</font></div>
<div><font face="monospace, monospace"> source:
git@...</font></div>
<div><font face="monospace, monospace">
source-tag: v${release-version}</font></div>
</div>
</blockquote>
<br>
</span><font face="monospace, monospace">In 2.16 we are
introducing a variable to set this one, it comes from
the `version` defined above.<br>
</font></div>
</blockquote>
<div><br>
</div>
<div>That certainly helps, thanks for this!</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><font
face="monospace, monospace"> <br>
</font><span class="">
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>The alternatives at the moment seem to be:</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>2. Generate the snapcraft.yaml from a
template (jinja, for example), which works but
is kind of awkward.</div>
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<br>
</span> 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.<br>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</div>
</blockquote>
<br>
I think it would be good to behave like dch does and have a
`snapcraft set-version <version>` command instead.<br>
<br>
I let this sit for a bit and see what others think.<br>
<br>
In this scenario you'd do<br>
<br>
snapcraft set-version <version><br>
snapcraft<br>
</body>
</html>