add version and git commit at compile time

[jessfraz]

fix #203

[jessfraz]

this is part one in a series to get debs and rpms build 😇

[wking]

This will likely fix #203.

[jessfraz]

Ah nice I will make this get the latest tag instead :)

[jessfraz]

@LK4D4 looking at your comment from the issue linked i am going to propose the following:

• no VERSION file
• the version is either (a tag, if we have the repo checked out and are on a sha that is tagged)
• otherwise the version is the most recent tag from the sha we are on, with the postfix (-dev)

then we will never need a version file again, and we can do this all in the greatest language ever, bash

cc @crosbymichael

[wking]

You can get unfailable removal with rm -f runc. No need for the true fallback.

[laijs]

I think the intention of the author is that " if the file runc is non-existed, it shouldn't fail".

if so, I prefer to

test ! -e runc || rm runc

[wking]

On Mon, Sep 07, 2015 at 07:56:45PM -0700, Lai Jiangshan wrote:

• rm runc
• rm runc || true

I think the intention of the author is that " if the file runc is
non-existed, it shouldn't fail".

rm(1) has:

   -f, --force
          ignore nonexistent files and arguments, never prompt

so there's no need for anything fancier than ‘rm -f runc’.

[jessfraz]

i will update this tomorrow, you all can chill ;)

On Mon, Sep 7, 2015 at 8:24 PM, W. Trevor King notifications@github.com
wrote:

In Makefile
#244 (comment):

@@ -26,7 +35,7 @@ install:
cp runc /usr/local/bin/runc

clean:

• rm runc
• rm runc || true

On Mon, Sep 07, 2015 at 07:56:45PM -0700, Lai Jiangshan wrote: > - rm runc

• rm runc || true I think the intention of the author is that " if the
  file runc is non-existed, it shouldn't fail".
  rm(1) has:
  … <#14faafbb7d161b07_>
  -f, --force ignore nonexistent files and arguments, never prompt so
  there's no need for anything fancier than ‘rm -f runc’.

—
Reply to this email directly or view it on GitHub
https://github.com/opencontainers/runc/pull/244/files#r38888021.

[tianon]

@jfrazelle then how do we build without .git?

[jessfraz]

@tianon wdyt about hitting github.com instead then?

[tianon]

That'd be alright (not stellar but workable), but how do we know which version on GitHub corresponds to the source we have locally on disk from a source tarball?

[jessfraz]

ugh ya thats true, idk... maybe not having a VERSION file is not the best way I just know in #203 that was the suggestion :/

[tianon]

Alternatively, we could publish our own source tarballs with a generated VERSION file in them, but that's even more work at release time than it's worth IMO.

[jessfraz]

im so confused... what should we do haha

[crosbymichael]

@tianon why u gotta be so confusing? ;)

So what's the plan here?

[tianon]

Ok, let me be a bit more verbose then. 😄

I see a few options here.

1. no version tracking anywhere but in tags
   • easy to maintain
   • not great for debugging user issues (which version are you running?)
2. current version tracked in a file (with my personal recommendation being version.go so there's no compiler trickery required)
   • somewhat annoying to maintain (since it has to be manually bumped either before or after a release)
   • great for debugging and user visibility (ie, runc --version spits out something useful)
3. 1 (version only tracked in tags), but we also then publish official "source tarballs" for distros to consume which include a VERSION file or similar
   • annoying for releases (which means we'll likely tend to release less often)

This PR most closely aligns with 1 as-is, which is fine, but will definitely need some way for distros to specify the version number since they won't build with .git available (and thus any invocations of git during the build process will fail outright), and we'll want to reach out to any of them that have packages already and let them know that they need to inject the package version during the build.

I'd put my personal vote on 2 (because it's the most balanced option), but I won't be responsible for maintaining the file so IMO my vote doesn't carry a lot of weight in this case. 😄

[mikebrow]

@jfrazelle you might want to look at my alternative in #404.. pulling the version from opencontainers/specs/version.go this might be what @tianon was talking about? Cheers.

[wking]

On Tue, Nov 17, 2015 at 10:13:21AM -0800, Mike Brown wrote:

@jfrazelle you might want to look at my alternative in
#404.. pulling the version from opencontainers/specs/version.go

Binding the runC version to the spec version seems like it would make
it hard to do patch-releases, etc., when fixing implementation bugs.
I think the best solution a hybrid of @tianon's 1:

• Development version tracking only in tags (like this PR)
• Makefile rules for creating a version.go (similar to this PR, but
  write version.go instead of using CTIMEVAR), but having that
  version.go be .gitignored.
• A release script that includes version.go for publishing release
  tarballs that can be used without Git.

But like @tianon, I'm not going to be maintaining the releases, so my
vote doesn't carry a lot of weight either ;).

[mikebrow]

Two versions, one for the oci container code/spec and one for the runc binary? Which check goes in the config.json the one for the spec or the one for the runc binary? Hmm....

[wking]

On Tue, Nov 17, 2015 at 11:09:56AM -0800, Mike Brown wrote:

Two versions, one for the oci container code/spec and one for the
runc binary? Which check goes in the config.json the one for the
spec or the one for the runc binary? Hmm....

The one for the spec goes in config.json. For example, if runC
implements v1.0.0 of the spec, that might be v1.0.0 of runC (or maybe
it will be v2.3.0 of runC, it doesn't really matter). Then you
discover and patch a bug in runC, and you'd want to release runC
v1.0.1 (or v2.3.1). But it was a runC bug, so the spec version won't
change, and bundle authors don't have to do anything (runtime callers
will want to install the new runC version). Having decoupled versions
also allows a single runC binary to support multiple spec versions.
For example, a runC binary that supports v1.5.0 of the spec will also
support previous releases in the spec's v1.x series (because the spec
is semantically versioned 1).

[mikebrow]

Fair enough...

[marcosnils]

+1 on having decoupled versions. Pretty much like how docker handles the client/versioning API