🐢 Now we’re going into the real deep work. The only failure was the Codecov patch in Xvc. Let’s see what needs to be done.
🐇 It looks, from the coverage page, that our additions to HStore don’t have any tests. We can add some unit tests to new joins, maybe.
🐢 I don’t find unit tests particularly useful, but let’s use GitHub Copilot to add tests for us.
🐇 Added a unit test and a doc test for full_join, and I think doc tests have more value. They provide documentation, and we can readily see how to use a function from its docs. Better to increase coverage with doc tests.
🐢 There are points that I should learn while writing doc tests. The imports must use the full path, not crate::. The tested struct also doesn’t have implicit imports.
🐇 The ceremony of adding keys and values is a bit too much. It may be worthwhile to add insert for any Into<XvcEntity>.
🐢 It will certainly save time if we don’t have to type .into() for each key :)
🐇 Pushed to test again. Should we have some means to test coverage locally?
🐢 I don’t think we need to consider coverage locally. It’s not worth our time.
🐇 Now while waiting for tests to be completed, what can we do?
gh -R iesahin/xvc run list
completed failure v0.6.13 Rust-CI v0.6.13 pull_request 12543831360 3m54s 2024-12-30T08:15:06Z
...
🐢 I don’t think it took too much time. Let’s view the results:
gh -R iesahin/xvc run view 12543831360
...
X Run Current Dev Tests
...
To see what failed, try:
View this run on GitHub: https://github.com/iesahin/xvc/actions/runs/12543831360
🐢 The current dev tests fail for some reason. Let’s run these locally.
🐇 We’re missing llvm-tools-preview locally. How do we install this?
🐢 The command is:
rustup component add llvm-tools-preview
info: component 'llvm-tools' for target 'aarch64-apple-darwin' is up to date
🐇 It’s already installed. We need to set the environment variables.
🐢 Instead, we can just turn off dev tests for the time being. We don’t need them. Our local tests pass.
🐇 Yeah, ok, we don’t need to solve each and every bit of these issues.
gh -R iesahin/xvc run list
… 🐇 Ok. Let’s take a look at the run again.
gh -R iesahin/xvc run list
completed failure v0.6.13 Rust-CI v0.6.13 pull_request 12544020064 3m39s 2024-12-30T08:33:25Z
gh -R iesahin/xvc run view 12544020064
...
X Test and Coverage
...
gh run view 12544020064 --log-failed
...
Test and Coverage (stable) Test and Coverage 2024-12-30T08:36:58.8911690Z Error: ProcessError { stdout: "", stderr: " % Total % Received % Xferd Average Speed Time Time Time Current\n Dload Upload Total Spent Left Speed\n\r 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0\r 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0\ncurl: (7) Failed to connect to e1.xvc.dev port 80 after 160 ms: Couldn't connect to server\n" }
...
🐢 We need to start nginx on the server. We forgot it yesterday.
🐇 Ah, yeah. After adding that dufs installation. Ok.
🐢 We also need to add a reverse proxy to dufs somehow, but this is for later.
🐇 For the use case, I don’t think it’s necessary. We can just adjust the port to a non-standard one if we need to use 443 for another thing, but let’s take a look at the tests again.
🐢 Let’s add another doc test. This time to XvcStore.
cargo test -p xvc-ecs --doc
...
test result: ok. 8 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out; finished in 2.87s
🐇 Sent the files again. Waiting for tests to finish.
🐢 Let’s check the keymaps file in the meantime.
🐇 I tried to read some documentation but didn’t see an error. Maybe we should just set it to non-lazy and avoid allowing remaps.
🐢 We already spent too much time with this.
🐇 Yes, let’s take a look at the tests again.
gh -R iesahin/xvc run list
completed success v0.6.13 Rust-CI v0.6.13 pull_request 12544291068 8m10s 2024-12-30T09:00:42Z
...
🐢 Oh, yeah, the merge is ready.
🐇 Patch coverage is still behind the target, though.
🐢 Yeah, but let’s release this one and make the next better covered. Also, I’m not sure if the doc tests had any effect on coverage.
🐇 If we look at the coverage page again, we can see if the doc tests had any effect.
🐢 It seems codecov.io doesn’t consider coverage for doc tests. This is a bit weird, but let’s not spend more time on this.
🐇 Sure, let’s merge.
🐢 I think we forgot to bump the version in Cargo.toml. We’ll have to do that in main.
🐇 Oh, yeah. Let’s bump it and tag as well.
🐢 Now, we can wait for all files to be produced. What will we do next?
🐇 We can just release the Python version as well. It shouldn’t need any changes.
🐢 Umm, right. Maybe we can add a few tests as well.
🐇 Let’s bump the version first and see.
🐢 Bumped versions in Cargo.toml and ran maturin develop.
🐇 It seems ready now.
🐢 The main fails, though. The “Publish Crates” action looks for libsqlite3. Let’s take a look at it.
gh -R iesahin/xvc run list
completed failure Release v0.6.13 Publish Crates v0.6.13 push 12544753359 6m1s 2024-12-30T09:41:56Z
🐢 The issue is that the VM doesn’t have libsqlite3-dev. Let’s add it.
🐇 We need to start the job manually again. Let’s not tag this time.
🐢 Some of the packages were already published. Now they break. crates.io says they’re already published. Maybe we can check if a package is already published.
🐇 Let’s check if we can make cargo publish more forgiving.
🐢 There doesn’t seem to be an option. Let’s search “how to skip published packages in the workspace to avoid errors with cargo publish”.
🐇 Claude is bullshitting again. Let’s try a manual approach: how to skip already published packages.
🐢 It may be easier to just add a check if the package is published. How do we get the info?
🐇 Or we can just go on to the next package if the package is already available.
🐢 Let’s do this manually this time.