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
<[email protected] <mailto:[email protected]>>
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
--
Snapcraft mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/snapcraft
