Files
shorebird-updater/patch
Eric Seidel 226df7d08d test: Make our rust tests use per-thread config rather than global static (#14)
* Make our rust tests use per-thread config rather than global static

This lets our unit tests run in parallel.  I also moved our "integration"
tests back to be unit tests for now.

This also exposes a network mocking abstraction.

I've added an incomplete test of applying a full patch.  Still
needs some work to complete.

* Finish making the patch success test work

* Changed our test config to use println instead of info/error, etc. so that tests show output on failure (there might be a better way?)
Unfortunately macro_use (which is the way we were causing error!, info! etc to appear everywhere with only one global import before, only works on crates not on std, so I had to be explicit with my imports per-file.
* Add a function to build a fake zip file, because that's what the updater currently expects.  Better would be for us to move to a AssetManager system I suspect, then the updater would ask the asset manager for the libapp.so and we'd return it instead of having to go through writing out a zip file.
* Added a string_patch.rs tool and shared code between that and the patch tool.  This made it possible/easy for me to generate the necessary binary patches as well as needed hashes to pretend to be the patch server.
* Added one simple test of the patch tool core logic.

In total we're now above 80% coverage of our rust code after this.

* remove stray comment
2023-04-26 13:07:19 -05:00
..

patch command line tool

This is the tool used by the shorebird command line to compute the patch file for uploading to the server.

This currently uses the rust bidiff crate to compute the patch file. and could just use the bic command line tool included in that crate. However we're explicitly writing our own command line to allow us to change the underlying compression without affecting the shorebird command line callers.

Usage

patch <old> <new> <patch>

Generating test expectations

The string_patch target can be used to generate test expectations for testing the updater. It takes two strings as arguments and prints the necessary variables you will need in your test to stdout.

% cargo run --bin=string_patch "foo" "bar"
Base: foo
New: bar
Patch: [40, 181, 47, 253, 0, 128, 113, 0, 0, 223, 177, 0, 0, 0, 16, 0, 0, 0, 3, 98, 97, 114, 0]
Hash (new): fcde2b2edba56bf408601fb721fe9b5c338d10ee429ea04fae5511b68fbf8fb9

Which will translate into:

let base = "foo";
let new = "bar";
let patch: Vec<u8> = vec![40, 181, 47, 253, 0, 128, 113, 0, 0, 223, 177, 0, 0, 0, 16, 0, 0, 0, 3, 98, 97, 114, 0];
let hash = "fcde2b2edba56bf408601fb721fe9b5c338d10ee429ea04fae5511b68fbf8fb9";