Page MenuHomePhabricator

[web] Check backup client wasm integrity buildkite
AbandonedPublic

Authored by michal on Feb 20 2024, 2:40 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Dec 20, 12:32 AM
Unknown Object (File)
Tue, Dec 17, 5:59 PM
Unknown Object (File)
Mon, Dec 16, 2:37 PM
Unknown Object (File)
Mon, Dec 16, 2:37 PM
Unknown Object (File)
Mon, Dec 16, 2:37 PM
Unknown Object (File)
Mon, Dec 16, 2:37 PM
Unknown Object (File)
Mon, Dec 16, 2:37 PM
Unknown Object (File)
Mon, Dec 16, 2:37 PM
Subscribers

Details

Reviewers
kamil
atul
Summary

ENG-6873 : Add a buildkite job for checking integrity of backup client wasm file

Similarly to comm_query_executor we want a buildkite job to build the wasm file from source and make sure that it's the same. In this diff I'm modifiying the existing pipeline to also check for the backup client.

Test Plan

Check that the CI passes.

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

michal held this revision as a draft.

Check if CI will fail if wasm file is not updated, but the code is changed

Check if my changes broke the pipeline

Update the new emscripten pipeline

michal published this revision for review.Feb 23 2024, 10:10 AM

Passing two command flags seems weird, can we do like yarn build-db-wasm && yarn build-db-wasm?

Switch to one command. Check that CI fails if wasm wasn't updated.

Switch to two command, as I had problems with doing both builds in one command.

Check that CI passes if wasm is current.

Try cleaning before building

atul requested changes to this revision.Feb 26 2024, 1:58 PM

Looks like the Emscripten workflow is failing? Sending back to your queue, feel free to re-request review if I'm missing something

This revision now requires changes to proceed.Feb 26 2024, 1:58 PM
.buildkite/emscripten.yml
5 ↗(On Diff #37611)

We should avoid committing commented-out code

Oh sorry, I forgot this was in review, sorry for the confusion. I'm having issues with generated WASM reproducibility on CI so this diff isn't ready yet and I'm still testing.

It's good practice to "Plan Changes" to take diffs off of your reviewers' queues if they're not ready for review

Sorry, I keep forgetting that for this diff, when testing CI I have to plan changes after every new revision.

Canceling this in favour of just adding another build step to cleaninstall. See discussions in ENG-6873