Building from the releases tab fails due to lack of repository information (vergen fails to find repository)

[chramb]

Summary

Hello, I'd like to report an issue that comes up when attempting to build netavark from source shared in the releases page.

Because the source code in the archives don't contain git files, vergen fails to find the repository-related information and halts the build.

Steps to reproduce

1. download one of the Source code archives from the Releases Page
2. Extract the archive
3. run make or cargo build

Error message

[...]
   Compiling git2 v0.13.25
   Compiling netavark v1.0.1 (/netavark-1.0.1)
error: failed to run custom build command for `netavark v1.0.1 (/netavark-1.0.1)`

Caused by:
  process didn't exit successfully: `/netavark-1.0.1/targets/release/build/netavark-bd067803e9a8b9d8/build-script-build` (exit status: 1)
  --- stderr
  Error: could not find repository from '/netavark-1.0.1'; class=Repository (6); code=NotFound (-3)
warning: build failed, waiting for other jobs to finish...
error: build failed
make: *** [Makefile:47: build] Error 101

Temporary solution

by removing "git" from list of vergen features in Cargo.toml and manually setting VERGEN_GIT_SHA environment variable I was able to build it successfully.

$ sed -i  's/, "git"//' Cargo.toml
$ env VERGEN_GIT_SHA="" make

Result

$./bin/netavark version
{
  "version": "1.0.1",
  "commit": "",
  "build_time": "2022-02-25T20:50:50.689314389+00:00",
  "target": "x86_64-alpine-linux-musl"
}

[mheon]

@baude @Luap99 PTAL

[baude]

@chramb we are new to packaging up rust projects. do you have advice here or perhaps could submit a PR?

[cgwalters]

I wouldn't say there's a single standard on this. This is a highly complex topic. In most other projects I've seen, there's a best effort made to use git checkout if available, but otherwise fall back to nothing, i.e. don't just fail the build if not from git.

In practice, most systems that build from tarballs are dpkg/rpm, which today have their own concept of versions and source metadata. IOW, people creating debs/rpms and the like are highly likely to use e.g rpm -q netavark and not netavark --version.

Now, I am also personally strongly of the opinion that debs/rpms using tarballs by default is just a legacy holdover, and the opinionated default should actually be to build from git checkouts. But...that's a whole other battle.

I think the most robust thing is to inject a version stamp file into the source tarball, and use that.

Now, when cargo is at the toplevel of the build, it automatically injects useful environment variables but that doesn't work when cargo isn't in control over the build (AFAIK).

[flouthoc]

I think the inbuilt vendor dir in git tree is the easiest way out there for this problem, but perhaps if we can ship a vendor dir in external tar and cargo does not objects on it then it would also work. But need to confirm if we could ship vendor outside of this git repo so other distros could use it.

[Luap99]

IMO the only thing we have to do, is to make it not fail and show an empty commit string in the version output.
This is how it works in podman so we should match that.

[chramb]

@baude unfortunatelly I don't know much more than simple Hello World in rust.

I came across this issue while packaging Netavark for Gentoo. So far I solved it by disabling the git feature and manually setting the VERGEN_GIT_SHA variable which produces the same outcome as building inside the git repo.

I think the most correct solution would be to somehow make git feature not fail or dynamically enable it inside Makefile, if something like that is even possible.

If not, replacing that variable by something like SHA=$(git log --pretty=format:'%H' -n 1 2> /dev/null || echo '') and using that environment variable would possibly also work however that doesn't look like the best solution. So fixing it in rust somewhere with vergen would be best but unfortunately I have no idea how to do it.

[Luap99]

PR #254 should fix this, I will make the same change for aardvark.