when building from tarball, no version number

[tessus]

Subject of the issue

When I build vw from the tarball, e.g. https://github.com/dani-garcia/vaultwarden/archive/refs/tags/1.30.1.tar.gz, no version is shown in the diagnostics admin page.

build command: cargo build --features sqlite,mysql,postgresql --release

Generate Support String does not work either.

Deployment environment

Nothing happens, when I click on Generate Support String. This also seems to be a regression.

• vaultwarden version: 1.30.1

• Install method: built from source

• Clients used: admin page

• Reverse proxy and version: irrelevant (but it's Apache/2.4.58)

• MySQL/MariaDB or PostgreSQL irrelevant (but it's MySQL 8.0.35)

• Other relevant details:

Steps to reproduce

1. download tarball
2. extract
3. build
4. run
5. go to https://vault.example.com/admin/diagnostics

Expected behaviour

Server Installed should show the version.
When clicking on Generate Support String, the support string should be generated.

Actual behaviour

Server Installed is empty.
No support string is generated.

Troubleshooting data

[BlackDex]

All is based upon the git repo metadata locally.
If that is not available it doesn't set this.

All tools, CI/CD, podman and docker bake script use the same git commands to extract this information.

If you fully build your self without any git metadata, i suggest to set VW_VERSION during the build. This will see that env variable and uses that as version number.

[tessus]

I can certainly do that. It's just that I haven't changed anything on my side.

I wrote a script that either builds from the tarball or the git repo at hash XXXXX. And until not too long ago, a version number was shown without having to set VW_VERSION at build time.

But I'll try to set VW_VERSION. But does this have anything to do with the generate support string? Anyway, I'll try and report back.

[tessus]

Hmm, there is something wrong even when building from git....

/--------------------------------------------------------------------\
|                        Starting Vaultwarden                        |
|                      Version 1.30.0-48836501                       |
|--------------------------------------------------------------------|
| This is an *unofficial* Bitwarden implementation, DO NOT use the   |
| official channels to report bugs/features, regardless of client.   |
| Send usage/configuration questions or feature requests to:         |
|   https://github.com/dani-garcia/vaultwarden/discussions or        |
|   https://vaultwarden.discourse.group/                             |
| Report suspected bugs/issues in the software itself at:            |
|   https://github.com/dani-garcia/vaultwarden/issues/new            |
\--------------------------------------------------------------------/

[BlackDex]

Can you see if an older version tarball still works? And if so provide which works and which doesn't?
Could be Github changed something?

[tessus]

I can try later today, but as mentioned in my previous comment, there is even an issue when building from git.
I usually build from git and thus this is more important and I will try to narrow that down.

[BlackDex]

Then i would still like to know at which point this failed, since nothing has changed in regards to this between 1.30.0 and 1.30.1.
Also, 1.30.0-48836501 is the current testing tagged version, and is correct. And it is also exactly the same as the 1.30.1 latest tagged version.

It would help if you can share the script/tooling you use to download/build this. Since all tooling i checked seems to work just fine. I even tested a git clone --depth=1, and that works fine too.

[tessus]

I was able to narrow down the incorrect version info when building from git.

So... If I built version 1.30.0 (at git main at that point) and then do a git pull to retrieve the latest version (at the time of this writing 1.30.1), cargo build does not seem to update all info. Which is weird, because the hash is correct, but the version is wrong. I have to do a cargo clean before the build and then all is good.
Before cargo clean: 1.30.0-48836501
After cargo clean: 1.30.1

If there is a tag, no git hash is shown in the version output.

So I am not entirely sure how it comes to 1.30.0-48836501 at all, because the version is generated as follows: use tag, iff it exists. otherwise use tag-current_git_hash
And at git hash 48836501 a tag 1.30.1 exists.

My build script either

• downloads the tarball
• does a git pull, git checkout <githash>

and then the cargo build. I never set any env vars or anything.

[dani-garcia]

We might need to invalidate the build script output by using https://doc.rust-lang.org/cargo/reference/build-scripts.html#rerun-if-changed and pointing it to some files in the .git directory?

[tessus]

btw, how do I retrieve the version via the API?

[BlackDex]

See

vaultwarden/src/api/admin.rs

Line 610 in 4883650

match get_json_api::<GitRelease>("https://api.github.com/repos/dani-garcia/vaultwarden/releases/latest")

[tessus]

no, I mean from the binary (vaultwarden server). isn't there a config endpoint or version? I can't finf it though?

./vaulwarden -v works but I want to see what is returned by the admin page. and this is done via an API, is it not?

[tessus]

Then i would still like to know at which point this failed

I tried 1.29.0, but also ran into the same issue. So I am not sure when that worked. Or I changed something in my build process, which I however do not recall. I certainly never set VW_VERSION. Still a mystery to me, but I am not going to waste any more time on this.

My solution is to only build from git moving forward. In case I will ever have to use the tarball, I'll remember to set VW_VERSION.

We might need to invalidate the build script output and pointing it to some files in the .git directory

I would suggest to point it to .git/HEAD

Shall I close this issue or do you want to keep it around for reference?

[BlackDex]

Let's keep it open for the fix to adjust build.rs

[tessus]

I just read up on rerun-if-changed. By default, cargo should rebuild build.rs every time something changes in the source tree. Which is the case when I do a git pull and the source tree changes from release A to release B.
So either there is a bug in cargo or the documentation is wrong.

But according to the documentation using rerun-if-changed will only restrict the recompilation to the change of a file or dir.

Thus I doubt that setting rerun-if-changed will improve anything. Unless there is a bug in cargo.

[BlackDex]

Well, there wasn't a change between the latest testing and stable release. Just a tag was created, maybe that is what is the issue here? Did you do a pull with --tags?

[tessus]

That's why I mentioned:

If I built version 1.30.0 (at git main at that point) and then do a git pull to retrieve the latest version (at the time of this writing 1.30.1)

There were 4 commits between those 2 versions. Definitely changes to the source tree.

But yea, your idea makes sense, but unfortunately I wasn't at HEAD.