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
download tarball
extract
build
run
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
Originally created by @tessus on GitHub (Nov 20, 2023).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/4087
### 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
<!-- How the server was installed: Docker image, OS package, built from source, etc. -->
* 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
<img width="614" alt="image" src="https://github.com/dani-garcia/vaultwarden/assets/223439/f9215302-6c65-476f-bd65-7d824274f6f3">
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.
<!-- gh-comment-id:1818534547 -->
@BlackDex commented on GitHub (Nov 20, 2023):
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.
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.
<!-- gh-comment-id:1818612307 -->
@tessus commented on GitHub (Nov 20, 2023):
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.
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 |
\--------------------------------------------------------------------/
<!-- gh-comment-id:1818632283 -->
@tessus commented on GitHub (Nov 20, 2023):
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 |
\--------------------------------------------------------------------/
```
<img width="683" alt="image" src="https://github.com/dani-garcia/vaultwarden/assets/223439/e00d8fc1-425d-4962-a267-e19bde53a621">
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?
<!-- gh-comment-id:1818643025 -->
@BlackDex commented on GitHub (Nov 20, 2023):
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?
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.
<!-- gh-comment-id:1818692385 -->
@tessus commented on GitHub (Nov 20, 2023):
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.
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.1latest 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.
<!-- gh-comment-id:1818767055 -->
@BlackDex commented on GitHub (Nov 20, 2023):
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.
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.
<!-- gh-comment-id:1818789458 -->
@tessus commented on GitHub (Nov 20, 2023):
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.
<!-- gh-comment-id:1818799277 -->
@dani-garcia commented on GitHub (Nov 20, 2023):
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?
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?
<!-- gh-comment-id:1818845332 -->
@tessus commented on GitHub (Nov 20, 2023):
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?
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?
<!-- gh-comment-id:1819130330 -->
@tessus commented on GitHub (Nov 20, 2023):
> 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?
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.
<!-- gh-comment-id:1819210707 -->
@tessus commented on GitHub (Nov 20, 2023):
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.
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?
<!-- gh-comment-id:1819529328 -->
@BlackDex commented on GitHub (Nov 20, 2023):
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`?
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.
<!-- gh-comment-id:1819875009 -->
@tessus commented on GitHub (Nov 20, 2023):
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`.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @tessus on GitHub (Nov 20, 2023).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/4087
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 --releaseGenerate Support Stringdoes not work either.Deployment environment
Nothing happens, when I click on
Generate Support String. This also seems to be a regression.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
https://vault.example.com/admin/diagnosticsExpected behaviour
Server Installedshould show the version.When clicking on
Generate Support String, the support string should be generated.Actual behaviour
Server Installedis empty.No support string is generated.
Troubleshooting data
@BlackDex commented on GitHub (Nov 20, 2023):
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_VERSIONduring the build. This will see that env variable and uses that as version number.@tessus commented on GitHub (Nov 20, 2023):
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_VERSIONat 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 commented on GitHub (Nov 20, 2023):
Hmm, there is something wrong even when building from git....
@BlackDex commented on GitHub (Nov 20, 2023):
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 commented on GitHub (Nov 20, 2023):
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 commented on GitHub (Nov 20, 2023):
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-48836501is the currenttestingtagged version, and is correct. And it is also exactly the same as the1.30.1latesttagged 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 commented on GitHub (Nov 20, 2023):
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 builddoes not seem to update all info. Which is weird, because the hash is correct, but the version is wrong. I have to do acargo cleanbefore the build and then all is good.Before
cargo clean:1.30.0-48836501After
cargo clean:1.30.1If 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-48836501at all, because the version is generated as follows: use tag, iff it exists. otherwise usetag-current_git_hashAnd at git hash
48836501a tag1.30.1exists.My build script either
git pull,git checkout <githash>and then the
cargo build. I never set any env vars or anything.@dani-garcia commented on GitHub (Nov 20, 2023):
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 commented on GitHub (Nov 20, 2023):
btw, how do I retrieve the version via the API?
@BlackDex commented on GitHub (Nov 20, 2023):
See https://github.com/dani-garcia/vaultwarden/blob/48836501bf348386d9bb1378fb56db33c19d3732/src/api/admin.rs#L610
@tessus commented on GitHub (Nov 20, 2023):
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 commented on GitHub (Nov 20, 2023):
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 setVW_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.I would suggest to point it to
.git/HEADShall I close this issue or do you want to keep it around for reference?
@BlackDex commented on GitHub (Nov 20, 2023):
Let's keep it open for the fix to adjust
build.rs@tessus commented on GitHub (Nov 20, 2023):
I just read up on
rerun-if-changed. By default, cargo should rebuildbuild.rsevery time something changes in the source tree. Which is the case when I do agit pulland 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-changedwill improve anything. Unless there is a bug in cargo.@BlackDex commented on GitHub (Nov 20, 2023):
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 commented on GitHub (Nov 20, 2023):
That's why I mentioned:
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.