Vscodium: always showing update information on 1.35

[CuriousFu]

i upgraded it then issue occurs showning on the picture :

[stripedpajamas]

What OS are you on?

[CuriousFu]

windows x64

[tpatsiouras]

Win 10 64bit, also and although I downloaded latest release from here, update says that there's newer version... Downloads the same file...

[stripedpajamas]

Ok, so something must have gotten messed up when the sha sums were calculated for the Windows artifacts.

User x64:

{
 "url": "https://github.com/VSCodium/vscodium/releases/download/1.35.0/VSCodiumUserSetup-x64-1.35.0.exe",
 "name": "1.35.0",
 "version": "553cfb2c2205db5f15f3ee8395bbd5cf066d357d",
 "productVersion": "1.35.0",
 "hash": "2e89f5be95e0b55f312e48f499e3950cb0e576d0",
 "timestamp": "1559865184335",
 "sha256hash": "3c2038bf54c083ab2da884eabc2c579fc8b46721ea0c10ca783e7ecbda102ae4"
 }

$ shasum -a 256 VSCodiumUserSetup-x64-1.35.0.exe
4e51347f7ba64e7e5640a66109cb52d6bed470b527bd4fb371fb625957a41470  VSCodiumUserSetup-x64-1.35.0.exe
$ shasum -a 1 VSCodiumUserSetup-x64-1.35.0.exe
16f7e38907a332610434e6af0e87729079a54899  VSCodiumUserSetup-x64-1.35.0.exe



md5-28eb4cd7903d27cad897121fbf8f0ff8



{
 "url": "https://github.com/VSCodium/vscodium/releases/download/1.35.0/VSCodium-win32-x64-1.35.0.zip",
 "name": "1.35.0",
 "version": "553cfb2c2205db5f15f3ee8395bbd5cf066d357d",
 "productVersion": "1.35.0",
 "hash": "b73ee289c2212127ac474ca3666a6258b89f1ad8",
 "timestamp": "1559865184694",
 "sha256hash": "a4496c5a02fa4badbb1f9c778169d1d9b8dedebc16fec6ab68fb59ee55620a45"
 }



md5-ac5e7a3f628eb5b04bfe8460758de3f7



$ shasum -a 256 VSCodium-win32-x64-1.35.0.zip
43b19b89d9bd0e5d0092f6ec6091dc152edd09e9558338b67ef57c42cb08b260  VSCodium-win32-x64-1.35.0.zip
$ shasum -a 1 VSCodium-win32-x64-1.35.0.zip
06a348bd9325904adc884c1a063bbd0478473554  VSCodium-win32-x64-1.35.0.zip

Interestingly the 32-bit artifacts have the proper shasums. I will root-cause this when I have some time, but for now I will update the version json files to have the correct sums and this issue should be resolved.

[stripedpajamas]

Actually it looks from the build logs that this was a sad race condition. We have it set to git pull right before pushing it's updated version JSON at the end of the build process. Somehow another build (Linux, Mac, or Windows 32-bit) pushed its own version JSON at that exact moment and the Windows 64-bit build's push was rejected. I will see if we can add some retry logic into the git push step.

I now think the most transparent mitigation step would be to remove the existing Windows 64-bit assets and trigger the Windows build.

[tpatsiouras]

Downloaded today's build of 1.35 (build time 07:58), updated in folder and started...
Check for update, shows again this version... Just thought to report it back...

[CuriousFu]

Ok，i will try it tonight，thanks a lot.😊

[stripedpajamas]

Can you both try updating? I have confirmed that all the hashes are valid.

Also pushed up an integrity checker that will report the validity of the hashes for all the different types of os/archs, to hopefully make debugging this in the future easier (https://github.com/VSCodium/versions/pull/1)

[tpatsiouras]

Hi
It's happening the same... Opened yesterday's build (2019-06011T04:56:38:833Z)
Checked for download... 1 file... Downloaded... Exact same file/version...
Overwrite files... Opened... Checked for download... 1 file...

[linsui]

The same on 1.35.1

[stripedpajamas]

Alright -- will have some free time today or tomorrow to spin up a Windows machine and figure out what's going on. Sorry for the annoying experience everyone 😣

[stripedpajamas]

Good news! I have figured out the root cause of this. Or at least close to the root cause.

The version files are correct. The Windows binaries unfortunately have a small bug in them. During build, vscode writes the commit hash of the version it's building into the product.json file. This commit hash is considered the 'version' and used when checking for updates. Different commit hash from the update server means it should download the update.

The commit hash that gets written into product.json is supposed to be the commit in the vscode repo that corresponds to the tag we're building. So in the case of 1.35.1, that commit hash is c7d83e57cd18f18026a8162d042843bda1bcf21f -- https://github.com/microsoft/vscode/commit/c7d83e57cd18f18026a8162d042843bda1bcf21f

The problem: for some reason I've yet to figure out, the Windows builds have baked-in a commit hash from the VSCodium repo instead of the vscode repo. In this case db1afbd17a1c66db7ac8cf62a03d7b4db3aca70b -- https://github.com/VSCodium/vscodium/commit/db1afbd17a1c66db7ac8cf62a03d7b4db3aca70b (the last commit at time of build).

Mitigation: instead of fixing the root cause and rebuilding the Windows binaries at the moment (replacing the binaries has been troublesome for downstream dependents #192), I updated the Windows version files (https://github.com/VSCodium/versions/commit/4b6ac7db7fe529b3d62d1126d5bb8474928d4531) to stop the update loop.

I'll dig in to why the Windows builds (and not the others) is picking up the wrong repo's commit hash during build.

[stripedpajamas]

More good news -- I've found the root cause.

The version (commit hash) is pulled from the environment variable BUILD_SOURCEVERSION. If that variable is undefined, it will use git itself to get the commit hash. That env var is not defined in the Linux and Mac builds, so the build process gets the commit hash manually (and correctly).

But in Azure Pipelines, where the Windows build happens, the BUILD_SOURCEVERSION variable _is_ defined -- see the docs here. Thankfully, it looks like the predefined variables can be overwritten, so I will get a PR together that sets the variable properly (the fix will take affect when the next version of vscode comes out).

[linsui]

It seems that this problem still exists on 1.36.0 .

[tpatsiouras]

Yes, I confirm... I downloaded this morning v1.36 and right now, after
seeing this message, opened vscodium, checked for new version, downloaded
the proposed update, checked and it's the one I downloaded in the morning...

Theodore
Φιλικά
Θεόδωρος Πατσιούρας
[email protected]