starred/vaultwarden

Fork 0

mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-04-25 17:25:57 +03:00

[GH-ISSUE #4226] Testing version differ from latest commit in diagnostic admin panel #1826

New issue

Closed

opened 2026-03-03 02:12:33 +03:00 by kerem · 6 comments

kerem commented

2026-03-03 02:12:33 +03:00

Owner

Originally created by @danielphan2003 on GitHub (Jan 5, 2024).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/4226

Originally assigned to: @BlackDex on GitHub.

Subject of the issue

The diagnostic page is showing an update from latest commit (github.com/dani-garcia/vaultwarden@ae3a153bdb), but this commit doesn't actually cause the CI to build a new testing image that I could update to.

I think the diagnostic panel is checking the latest git commit, instead of the latest CI build that is available.

Deployment environment

Vaultwarden version: v1.30.1-2c369937
Web-vault version: v2023.12.0
OS/Arch: linux/x86_64
Running within Docker: false (Base: Not applicable)

Steps to reproduce

Use the testing build.

Expected behaviour

Diagnostic page should show there is no update available.

Actual behaviour

There seems to be an update as indicated on the page, but there is actually none.

Troubleshooting data

Originally created by @danielphan2003 on GitHub (Jan 5, 2024). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/4226 Originally assigned to: @BlackDex on GitHub. ### Subject of the issue The diagnostic page is showing an update from `latest` commit (https://github.com/dani-garcia/vaultwarden/commit/ae3a153bdb062414402ec94901fabb1105838674), but this commit doesn't actually cause the CI to build a new testing image that I could update to. I think the diagnostic panel is checking the latest git commit, instead of the latest CI build that is available. ### Deployment environment * Vaultwarden version: v1.30.1-2c369937 * Web-vault version: v2023.12.0 * OS/Arch: linux/x86_64 * Running within Docker: false (Base: Not applicable) ### Steps to reproduce Use the testing build. ### Expected behaviour Diagnostic page should show there is no update available. ### Actual behaviour There seems to be an update as indicated on the page, but there is actually none. ### Troubleshooting data ![Actual behaviour](https://github.com/dani-garcia/vaultwarden/assets/34669737/632ad31d-96ed-4b37-a568-9791ed869775) ![An image comparing the commit between deployment environment version versus the latest commit](https://github.com/dani-garcia/vaultwarden/assets/34669737/6d29e1b9-d526-463a-891f-1386f7b4b340)

kerem

2026-03-03 02:12:33 +03:00

closed this issue
added the
enhancement

low priority
labels

kerem commented

2026-03-03 02:12:34 +03:00

Author

Owner

@stefan0xC commented on GitHub (Jan 6, 2024):

I think the diagnostic panel is checking the latest git commit, instead of the latest CI build that is available.

That is indeed what is done:
github.com/dani-garcia/vaultwarden@ae3a153bdb/src/api/admin.rs (L620-L624)

The question to me would be if we should fix this (which would probably not be trivial) or if this discrepancy is an acceptable shortcoming we can dismiss because it's not that big of an issue which will occasionally come up if the latest commit did not trigger a release
github.com/dani-garcia/vaultwarden@ae3a153bdb/.github/workflows/release.yml (L5-L16)

Personally I think it's not worth the effort (but I have not looked into the GitHub API if there's an easy way to check for the commit of just the latest completed Release workflow).

@stefan0xC commented on GitHub (Jan 6, 2024): > I think the diagnostic panel is checking the latest git commit, instead of the latest CI build that is available. That is indeed what is done: https://github.com/dani-garcia/vaultwarden/blob/ae3a153bdb062414402ec94901fabb1105838674/src/api/admin.rs#L620-L624 The question to me would be if we should fix this (which would probably not be trivial) or if this discrepancy is an acceptable shortcoming we can dismiss because it's not that big of an issue which will occasionally come up if the latest commit did not trigger a release https://github.com/dani-garcia/vaultwarden/blob/ae3a153bdb062414402ec94901fabb1105838674/.github/workflows/release.yml#L5-L16 Personally I think it's not worth the effort (but I have not looked into the [GitHub API](https://docs.github.com/en/rest/actions?apiVersion=2022-11-28) if there's an easy way to check for the commit of just the latest completed Release workflow).

kerem commented

2026-03-03 02:12:34 +03:00

Author

Owner

@BlackDex commented on GitHub (Feb 2, 2024):

I did some checking. And it isn't possible to extract the last build version via an API call.
Also tried to check the packages if i could use that, but that is also not an option.

Only option i can think of is by using the artifacts maybe.
We could add an extra artifact with every release workflow like a file called testing or something.
That is easy to filter since the API even has a ?name=testing option. We can then use that response to get the latest build hash.

That might be an option.
I Was planning on doing some (larger) updates on the admin interface.
Ill see if i can take this into account to make it more robust.
And, to be on the safe side, i will use the current way as a fallback probably, in case the artifacts are not there anymore for some reason

@BlackDex commented on GitHub (Feb 2, 2024): I did some checking. And it isn't possible to extract the last build version via an API call. Also tried to check the packages if i could use that, but that is also not an option. Only option i can think of is by using the artifacts maybe. We could add an extra artifact with every release workflow like a file called testing or something. That is easy to filter since the API even has a `?name=testing` option. We can then use that response to get the latest build hash. That might be an option. I Was planning on doing some (larger) updates on the admin interface. Ill see if i can take this into account to make it more robust. And, to be on the safe side, i will use the current way as a fallback probably, in case the artifacts are not there anymore for some reason

kerem commented

2026-03-03 02:12:34 +03:00

Author

Owner

@dani-garcia commented on GitHub (Feb 2, 2024):

Could we just rebuild the images all the time, even if the changes are only to the readme? I can't imagine those kinds of non-source code changes happen very often anyway, so it's not like we're saving a lot of build time.

@dani-garcia commented on GitHub (Feb 2, 2024): Could we just rebuild the images all the time, even if the changes are only to the readme? I can't imagine those kinds of non-source code changes happen very often anyway, so it's not like we're saving a lot of build time.

kerem commented

2026-03-03 02:12:34 +03:00

Author

Owner

@BlackDex commented on GitHub (Feb 2, 2024):

We could i think. That is an option also.

Currently it only triggers on:

  - ".github/workflows/release.yml"
  - "src/**"
  - "migrations/**"
  - "docker/**"
  - "Cargo.*"
  - "build.rs"
  - "diesel.toml"
  - "rust-toolchain.toml"

But, if someone updates the resources or tools directory for example, it will also build.
That does, indeed, not happen that often. And might not be a big issue.

One added benefit would be that the image will be updated without any actual change to the code, but maybe with some base images updates hehe.

@BlackDex commented on GitHub (Feb 2, 2024): We could i think. That is an option also. Currently it only triggers on: ``` - ".github/workflows/release.yml" - "src/**" - "migrations/**" - "docker/**" - "Cargo.*" - "build.rs" - "diesel.toml" - "rust-toolchain.toml" ``` But, if someone updates the resources or tools directory for example, it will also build. That does, indeed, not happen that often. And might not be a big issue. One added benefit would be that the image will be updated without any actual change to the code, but maybe with some base images updates hehe.

kerem commented

2026-03-03 02:12:34 +03:00

Author

Owner

@BlackDex commented on GitHub (Feb 2, 2024):

Ill fix that right away. That is very easy to do :)

@BlackDex commented on GitHub (Feb 2, 2024): Ill fix that right away. That is very easy to do :)

kerem commented

2026-03-03 02:12:34 +03:00

Author

Owner

@BlackDex commented on GitHub (Feb 2, 2024):