devlog 9

๐Ÿข Today Iโ€™m planning to add cross compilation to Xvc 0.6.13 branch to add more support.

๐Ÿ‡ It looks you first need to turn off this ghost text from blink output. It makes writing insufferable.

๐Ÿข Yep, letโ€™s do that first.

๐Ÿ‡ Now, letโ€™s restart nvim.

๐Ÿข Why doesnโ€™t blink.cmp make emojis I use to have more priority, I donโ€™t know. Maybe we can just have #tor and #rab for us.

๐Ÿ‡ I think in time it will learn that emojis I defined in the snippets file have more priority but letโ€™s skip this for now. What do we need to do to add cross compilation?

๐Ÿข Maybe we can just make compilation time a bit longer. It shows a menu almost instantly. I want it to wait for a few more milliseconds.

๐Ÿ‡ Ok, letโ€™s take a look at the config.

๐Ÿข Configuration file doesnโ€™t have a key for this. Letโ€™s search: blink.cmp

๐Ÿ‡ I think the culprit is the typo resistance, it makes better options to be pushed below: https://cmp.saghen.dev/configuration/reference#fuzzy

๐Ÿข Letโ€™s turn that off.

๐Ÿ‡ There is an error in the configuration file. I donโ€™t know why does it fail.

๐Ÿข I added emojis to espanso and checked the error message. The configuration I copied from their docs is broken it seem. The messages is:

...share/nvim/lazy/blink.cmp/lua/blink/cmp/config/utils.lua:14: fuzzy.max_items: unexpected field found in configuration

Iโ€™ll just delete that line.

๐Ÿ‡ It still doesnโ€™t prioritize snippets but we can take a look at this later. Espanso is a better tool in this regard it looks.

๐Ÿข Yep. Letโ€™s take a look at the cross compilation support for Rust.

๐Ÿ‡ The well known option is cross.rs: https://github.com/cross-rs/cross

๐Ÿข We can start from this. The installation is from the git repository.

$ cargo install cross --git https://github.com/cross-rs/cross
    Updating git repository `https://github.com/cross-rs/cross`
    Updating git submodule `https://github.com/cross-rs/cross-toolchains.git`
  Installing cross v0.2.5 (https://github.com/cross-rs/cross#4090beca)
...
   Installed package `cross v0.2.5 (https://github.com/cross-rs/cross#4090beca)` (executables `cross`, `cross-util`)

๐Ÿ‡ Now we have cross and cross-util commands. Cross compilation requires podman on Linux and Docker on MacOs. Do we have docker?

๐Ÿข It looks, no, we donโ€™t have docker. Maybe we can just make a remote setup for this using podman or Github actions. Yesterday I saw a crate for that. I remember I saved it somewhere but could not find it. Searching again in this case looks easier. This tells something about my archival and retrieval issues.

๐Ÿ‡ Sometime later, you can add some vector search capabilities to your archive maybe. Semantic search.

๐Ÿข Yep, sometime later. Sometime.

๐Ÿ‡ Now letโ€™s search for adding rust cross compilation to github actions

๐Ÿข I found the link to the action: https://github.com/marketplace/actions/build-rust-projects-with-cross

Letโ€™s take a look at the example:

jobs:
  release:
    name: Release - ${{ matrix.platform.os-name }}
    strategy:
      matrix:
        platform:
          - os-name: FreeBSD-x86_64
            runs-on: ubuntu-20.04
            target: x86_64-unknown-freebsd
            skip_tests: true

          - os-name: Linux-x86_64
            runs-on: ubuntu-20.04
            target: x86_64-unknown-linux-musl

          - os-name: Linux-aarch64
            runs-on: ubuntu-20.04
            target: aarch64-unknown-linux-musl

          - os-name: Linux-riscv64
            runs-on: ubuntu-20.04
            target: riscv64gc-unknown-linux-gnu

          - os-name: Windows-x86_64
            runs-on: windows-latest
            target: x86_64-pc-windows-msvc

          - os-name: macOS-x86_64
            runs-on: macOS-latest
            target: x86_64-apple-darwin

          # more targets here ...

    runs-on: ${{ matrix.platform.runs-on }}
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Build binary
        uses: houseabsolute/actions-rust-cross@v0
        with:
           command: ${{ matrix.platform.command }}
          target: ${{ matrix.platform.target }}
          args: "--locked --release"
          strip: true
      - name: Publish artifacts and release
        uses: houseabsolute/actions-rust-release@v0
        with:
          executable-name: ubi
          target: ${{ matrix.platform.target }}

๐Ÿ‡ We can just convert the current configuration to this and see if it works.

๐Ÿข Letโ€™s do that, yep. I created a file .github/workflows/release.yml and will make it

๐Ÿ‡ Letโ€™s check the results with gh

$ gh -R iesahin/xvc run list
completed	failure	v0.6.13	Release	v0.6.13	pull_request	12525070531	34s	2024-12-28T08:17:28Z

๐Ÿข It says the release is completed.

$ gh -R iesahin/xvc run view 12525070531

X v0.6.13 Release iesahin/xvc#263 ยท 12525070531
Triggered via pull_request about 3 minutes ago

JOBS
X Release - FreeBSD-x86_64 in 12s (ID 34936257653)
  โœ“ Set up job
  โœ“ Checkout
  X Build binary
  - Publish artifacts and release
  โœ“ Post Build binary
  โœ“ Post Checkout
  โœ“ Complete job
X Release - Linux-x86_64 in 18s (ID 34936257860)
X Release - Linux-aarch64 in 16s (ID 34936257985)
X Release - Linux-riscv64 in 18s (ID 34936258091)
X Release - Windows-x86_64 in 23s (ID 34936258210)
X Release - macOS-x86_64 in 14s (ID 34936258298)
  โœ“ Set up job
  โœ“ Checkout
  X Build binary
  - Publish artifacts and release
  โœ“ Post Build binary
  โœ“ Post Checkout
  โœ“ Complete job

ANNOTATIONS
X Unable to process file command 'output' successfully.
Release - FreeBSD-x86_64: .github#662

X Value cannot be null. (Parameter 'name')
Release - FreeBSD-x86_64: .github#663

X The job was canceled because "FreeBSD-x86_64_ubuntu-20_" failed.
Release - Linux-x86_64: .github#1

X The job was canceled because "FreeBSD-x86_64_ubuntu-20_" failed.
Release - Linux-aarch64: .github#1

X The job was canceled because "FreeBSD-x86_64_ubuntu-20_" failed.
Release - Linux-riscv64: .github#1

X The job was canceled because "FreeBSD-x86_64_ubuntu-20_" failed.
Release - Windows-x86_64: .github#1

X The job was canceled because "FreeBSD-x86_64_ubuntu-20_" failed.
Release - macOS-x86_64: .github#1


To see what failed, try: gh run view 12525070531 --log-failed
View this run on GitHub: https://github.com/iesahin/xvc/actions/runs/12525070531

Now take a look at the failure:

$ gh -R iesahin/xvc run view 12525070531 --log-failed

๐Ÿ‡ Change the order and see what happens. Maybe we should first succeed in non-cross compilation.

$ gh -R iesahin/xvc run list
completed	failure	v0.6.13	Release	v0.6.13	pull_request	12525178664	35s	2024-12-28T08:34:18Z
...
$ gh -R iesahin/xvc run view   12525178664 --log-failed
...

๐Ÿข Itโ€™s the same error. The usage example is actually much more sophisticated.

๐Ÿ‡ The issue is that we ask for command from the matrix, but the matrix doesnโ€™t define a command. Today itโ€™s the second time the example in the docs fails. Added command for each of the platforms. We can also add separate features this way to make platform specific features work.

๐Ÿข Agreed. Letโ€™s take a look at it once more

$ gh -R iesahin/xvc run list | rg Release | head -n 1
completed	failure	v0.6.13	Release	v0.6.13	pull_request	12525253982	41s	2024-12-28T08:46:23Z

$ gh -R iesahin/xvc run view 12525253982 --log-failed
...
Release - macOS-x86_64	Build binary	2024-12-28T08:46:44.8464010Z error: the lock file /Users/runner/work/xvc/xvc/Cargo.lock needs to be updated but --locked was passed to prevent this
Release - macOS-x86_64	Build binary	2024-12-28T08:46:44.8464810Z If you want to try to generate the lock file without accessing the network, remove the --locked flag and use --offline instead.

๐Ÿ‡ Ah, now this is another error. Letโ€™s remove --locked flag and retry.

$ gh -R iesahin/xvc run list | rg Release | head -n 1
completed	failure	v0.6.13	Release	v0.6.13	pull_request	12525289176	1m8s	2024-12-28T08:53:23Z

$ gh -R iesahin/xvc run view 12525289176 --log-failed
...

๐Ÿข We finally started to have good news. Now weโ€™re getting OpenSSL errors. We need feature flags for these platforms or tell where OpenSSL is. Letโ€™s add bundled-openssl to failed ones. We also need bundled-sqlite to Windows binaries.

gh -R iesahin/xvc run list | rg Release | head -n 1
completed	failure	v0.6.13	Release	v0.6.13	pull_request	12525354179	3m9s	2024-12-28T09:04:55Z

gh -R iesahin/xvc run view 12525354179 --log-failed

๐Ÿ‡ It looks the Changes.md file is missing and it cannot upload the binaries as a release because of this. Set the changes file to CHANGELOG.md.

๐Ÿข Itโ€™s weird to fail because of this. I think we need to report these errors and possibly send a PR to merge. The file must be optional.

gh -R iesahin/xvc run list | rg Release | head -n 1
in_progress		v0.6.13	Release	v0.6.13	pull_request	12525449368	1m38s	2024-12-28T09:18:40Z

gh -R iesahin/xvc run view 12525449368 
...
X Release - Linux-riscv64 in 2m53s (ID 34937017298)
  โœ“ Set up job
  โœ“ Checkout
  X Build binary
  - Publish artifacts and release
  โœ“ Post Build binary
  โœ“ Post Checkout
  โœ“ Complete job
...
โœ“ Release - macOS-x86_64 in 2m39s (ID 34937017695)
โœ“ Release - macOS-aarch64 in 2m42s (ID 34937017787)
..
ARTIFACTS
xvc-macOS-x86_64.tar.gz
xvc-macOS-arm64.tar.gz

To see what failed, try: gh run view 12525449368 --log-failed
View this run on GitHub: https://github.com/iesahin/xvc/actions/runs/12525449368

๐Ÿข It looks Linux-riscv64 has OpenSSL compilation errors. I think we can skip this platform for the time being. The goal was to add aarch64 for MacOS and it seems to have succeed.

gh -R iesahin/xvc run list | rg Release | head -n 1
completed	failure	v0.6.13	Release	v0.6.13	pull_request	12525504079	3m24s	2024-12-28T09:26:43Z


gh -R iesahin/xvc run view 12525504079	
...
X Release - Linux-x86_64 in 2m57s (ID 34937116988)
  โœ“ Set up job
  โœ“ Checkout
  X Build binary
  - Publish artifacts and release
  โœ“ Post Build binary
  โœ“ Post Checkout
  โœ“ Complete job
...

ARTIFACTS
xvc-macOS-arm64.tar.gz
xvc-macOS-x86_64.tar.gz

To see what failed, try: gh run view 12525504079 --log-failed
View this run on GitHub: https://github.com/iesahin/xvc/actions/runs/12525504079

gh -R iesahin/xvc run view 12525504079	--log-failed
...
Release - Linux-x86_64	Build binary	2024-12-28T09:29:16.0702889Z    Compiling reflink v0.1.3
Release - Linux-x86_64	Build binary	2024-12-28T09:29:16.2262518Z error[E0308]: mismatched types
Release - Linux-x86_64	Build binary	2024-12-28T09:29:16.2264659Z     --> /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/reflink-0.1.3/src/sys/unix.rs:21:39
Release - Linux-x86_64	Build binary	2024-12-28T09:29:16.2417505Z      |
Release - Linux-x86_64	Build binary	2024-12-28T09:29:16.2419091Z 21   |         libc::ioctl(dest.as_raw_fd(), IOCTL_FICLONE, src.as_raw_fd())
Release - Linux-x86_64	Build binary	2024-12-28T09:29:16.2420577Z      |         -----------                   ^^^^^^^^^^^^^ expected `i32`, found `u64`
Release - Linux-x86_64	Build binary	2024-12-28T09:29:16.2422015Z      |         |
Release - Linux-x86_64	Build binary	2024-12-28T09:29:16.2423040Z      |         arguments to this function are incorrect
Release - Linux-x86_64	Build binary	2024-12-28T09:29:16.2423906Z      |
Release - Linux-x86_64	Build binary	2024-12-28T09:29:16.2424575Z note: function defined here
Release - Linux-x86_64	Build binary	2024-12-28T09:29:16.2426053Z     --> /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/libc-0.2.169/src/unix/linux_like/linux/mod.rs:6753:12
Release - Linux-x86_64	Build binary	2024-12-28T09:29:16.2427425Z      |
Release - Linux-x86_64	Build binary	2024-12-28T09:29:16.2428425Z 6753 |     pub fn ioctl(fd: c_int, request: Ioctl, ...) -> c_int;
Release - Linux-x86_64	Build binary	2024-12-28T09:29:16.2429583Z      |            ^^^^^
Release - Linux-x86_64	Build binary	2024-12-28T09:29:16.2430748Z help: you can convert a `u64` to an `i32` and panic if the converted value doesn't fit
Release - Linux-x86_64	Build binary	2024-12-28T09:29:16.2431850Z      |
Release - Linux-x86_64	Build binary	2024-12-28T09:29:16.2433357Z 21   |         libc::ioctl(dest.as_raw_fd(), IOCTL_FICLONE.try_into().unwrap(), src.as_raw_fd())
Release - Linux-x86_64	Build binary	2024-12-28T09:29:16.2434954Z      |                                                    ++++++++++++++++++++
Release - Linux-x86_64	Build binary	2024-12-28T09:29:16.2435460Z 
Release - Linux-x86_64	Build binary	2024-12-28T09:29:16.2455008Z For more information about this error, try `rustc --explain E0308`.
Release - Linux-x86_64	Build binary	2024-12-28T09:29:16.2513354Z error: could not compile `reflink` (lib) due to 1 previous error
Release - Linux-x86_64	Build binary	2024-12-28T09:29:16.2514550Z warning: build failed, waiting for other jobs to finish...
Release - Linux-x86_64	Build binary	2024-12-28T09:29:44.6096299Z ##[error]Process completed with exit code 101.

๐Ÿข It looks Linux-x86_64 doesnโ€™t support reflinks. Maybe we can make reflinks an optional feature and add it to macOS and Windows targets specifically.

๐Ÿ‡ Removed reflink from default features. This is a breaking change but fortunately we donโ€™t have that many users that will be affected from this.

Letโ€™s check the results one more.

gh -R iesahin/xvc run list | rg Release | head -n 1
completed	failure	v0.6.13	Release	v0.6.13	pull_request	12525597866	3m39s	2024-12-28T09:42:44Z

gh -R iesahin/xvc run view 12525597866
...
X Release - NetBSD-x86_64 in 3m13s (ID 34937298706)
  โœ“ Set up job
  โœ“ Checkout
  X Build binary
  - Publish artifacts and release
  โœ“ Post Build binary
  โœ“ Post Checkout
  โœ“ Complete job
...
View this run on GitHub: https://github.com/iesahin/xvc/actions/runs/12525597866

๐Ÿข Now turn NetBSD target off as well.

๐Ÿ‡ FreeBSD and Linux-x86_64 targets are also building. Letโ€™s take a look why aarch linux targets fail.

gh -R iesahin/xvc run list | rg Release | head -n 1
completed	failure	v0.6.13	Release	v0.6.13	pull_request	12525643284	4m46s	2024-12-28T09:52:04Z

gh -R iesahin/xvc run view 12525643284
โœ“ Release - FreeBSD-x86_64 in 4m14s (ID 34937389302)
โœ“ Release - Linux-x86_64 in 4m26s (ID 34937389370)
X Release - Linux-aarch64 in 4m38s (ID 34937389440)
X Release - Linux-aarch64 in 4m22s (ID 34937389491)
X Release - Windows-x86_64 in 4m24s (ID 34937389538)
X Release - Windows-aarch64 in 4m24s (ID 34937389585)
โœ“ Release - macOS-x86_64 in 2m36s (ID 34937389633)
โœ“ Release - macOS-aarch64 in 2m35s (ID 34937389669)
...
gh -R iesahin/xvc run view 12525643284 --log-failed
...

๐Ÿ‡ It looks those targets donโ€™t have libsqlite3 installed. Letโ€™s add bundled-sqlite to these targets as well.

gh -R iesahin/xvc run list | rg Release | head -n 1
completed	failure	v0.6.13	Release	v0.6.13	pull_request	12525734325	4m11s	2024-12-28T10:07:36Z

gh -R iesahin/xvc run view 12525734325 --log-failed

๐Ÿข Adding Android as a target didnโ€™t work. Letโ€™s remove this. It looks it requires more work.

๐Ÿ‡ I think weโ€™ll eventually move to Xvc to distribute binaries. We can build Android binary on Termux and link it in the releases page or push it as a release artifact.

๐Ÿข I need to learn more about Github releases. If we can add artifacts, binaries to the release, maybe we can do some of this work locally.

๐Ÿ‡ We can start by looking at gh commands capabilities.

๐Ÿข It looks itโ€™s possible to upload assets to releases. Letโ€™s check how that works.

gh release upload --help
Upload asset files to a GitHub Release.

To define a display label for an asset, append text starting with `#` after the
file name.


USAGE
  gh release upload <tag> <files>... [flags]

FLAGS
  --clobber   Overwrite existing assets of the same name

INHERITED FLAGS
      --help                     Show help for command
  -R, --repo [HOST/]OWNER/REPO   Select another repository using the [HOST/]OWNER/REPO format

LEARN MORE
  Use `gh <command> <subcommand> --help` for more information about a command.
  Read the manual at https://cli.github.com/manual
  Learn about exit codes using `gh help exit-codes`

๐Ÿ‡ So basically we can just upload files to tags. We can list releases and work with them like any other.

gh -R iesahin/xvc release list
v0.6.13-alpha.3	Latest	v0.6.13-alpha.3	2024-12-25T13:34:46Z
v0.6.13-alpha.2		v0.6.13-alpha.2	2024-12-13T19:05:11Z
v0.6.13-alpha.1		v0.6.13-alpha.1	2024-12-13T18:53:55Z
v0.6.13-alpha.0		v0.6.13-alpha.0	2024-11-30T18:36:49Z
v0.6.12		v0.6.12	2024-11-30T17:58:55Z
v0.6.11		v0.6.11	2024-09-11T10:52:50Z
v0.6.10		v0.6.10	2024-08-04T15:49:05Z
v0.6.9		v0.6.9	2024-07-29T12:20:07Z
v0.6.8		v0.6.8	2024-07-15T13:53:52Z
v0.6.7		v0.6.7	2024-03-19T19:10:26Z
v0.6.6		v0.6.6	2024-03-08T13:23:58Z
v0.6.5		v0.6.5	2024-01-09T10:03:13Z
v0.6.5-beta.0		v0.6.5-beta.0	2024-01-01T14:03:12Z
v0.6.4		v0.6.4	2023-12-05T10:13:49Z
v0.6.4-alpha.0		v0.6.4-alpha.0	2023-12-02T09:57:33Z
v0.6.3		v0.6.3	2023-11-02T17:57:45Z
v0.6.2		v0.6.2	2023-10-13T18:01:09Z
v0.6.1		v0.6.1	2023-10-05T21:14:32Z
v0.6.0		v0.6.0	2023-08-28T09:46:57Z
v0.5.1		v0.5.1	2023-01-28T21:35:20Z
v0.5.0		v0.5.0	2023-01-23T08:29:19Z
v0.4.2		v0.4.2	2023-01-17T09:52:55Z
v0.4.2-alpha.8		v0.4.2-alpha.8	2022-12-09T18:43:03Z
v0.4.2-alpha.7		v0.4.2-alpha.7	2022-12-09T18:49:17Z
v0.4.2-alpha.6		v0.4.2-alpha.6	2022-12-09T18:08:51Z
v0.4.2-alpha.5		v0.4.2-alpha.5	2022-12-09T09:14:06Z
v0.4.2-alpha.0		v0.4.2-alpha.0	2022-11-27T15:20:17Z
v0.4.1-alpha.0		v0.4.1-alpha.0	2022-11-26T08:07:23Z
v0.4.0		v0.4.0	2022-11-26T07:28:56Z
v0.3.4		v0.3.4	2022-11-20T08:43:55Z

and we can delete releases.

for r in v0.4.2-alpha.8 v0.4.2-alpha.7 v0.4.2-alpha.6 v0.4.2-alpha.5 v0.4.2-alpha.0 v0.4.1-alpha.0 ; do ; gh -R iesahin/xvc release delete "${r}" ; done

๐Ÿข Now, letโ€™s list them again

gh -R iesahin/xvc release list
v0.6.13-alpha.3	Latest	v0.6.13-alpha.3	2024-12-25T13:34:46Z
v0.6.13-alpha.2		v0.6.13-alpha.2	2024-12-13T19:05:11Z
v0.6.13-alpha.1		v0.6.13-alpha.1	2024-12-13T18:53:55Z
v0.6.13-alpha.0		v0.6.13-alpha.0	2024-11-30T18:36:49Z
v0.6.12		v0.6.12	2024-11-30T17:58:55Z
v0.6.11		v0.6.11	2024-09-11T10:52:50Z
v0.6.10		v0.6.10	2024-08-04T15:49:05Z
v0.6.9		v0.6.9	2024-07-29T12:20:07Z
v0.6.8		v0.6.8	2024-07-15T13:53:52Z
v0.6.7		v0.6.7	2024-03-19T19:10:26Z
v0.6.6		v0.6.6	2024-03-08T13:23:58Z
v0.6.5		v0.6.5	2024-01-09T10:03:13Z
v0.6.5-beta.0		v0.6.5-beta.0	2024-01-01T14:03:12Z
v0.6.4		v0.6.4	2023-12-05T10:13:49Z
v0.6.4-alpha.0		v0.6.4-alpha.0	2023-12-02T09:57:33Z
v0.6.3		v0.6.3	2023-11-02T17:57:45Z
v0.6.2		v0.6.2	2023-10-13T18:01:09Z
v0.6.1		v0.6.1	2023-10-05T21:14:32Z
v0.6.0		v0.6.0	2023-08-28T09:46:57Z
v0.5.1		v0.5.1	2023-01-28T21:35:20Z
v0.5.0		v0.5.0	2023-01-23T08:29:19Z
v0.4.2		v0.4.2	2023-01-17T09:52:55Z
v0.4.0		v0.4.0	2022-11-26T07:28:56Z
v0.3.4		v0.3.4	2022-11-20T08:43:55Z
v0.3.3		v0.3.3	2022-11-08T08:50:31Z
v0.3.2		v0.3.2	2022-10-26T15:23:57Z
v0.3.1		v0.3.1	2022-10-18T09:51:17Z

๐Ÿ‡ The latest one has failed again.

$ gh -R iesahin/xvc run list | rg Release | head -n 1
completed	failure	v0.6.13	Release	v0.6.13	pull_request	12533365613	5m13s	2024-12-29T07:03:43Z

$ gh -R iesahin/xvc run view 12533365613

X v0.6.13 Release iesahin/xvc#263 ยท 12533365613
...
ANNOTATIONS
X Failed to CreateArtifact: Received non-retryable error: Failed request: (409) Conflict: an artifact with this name already exists on the workflow run
Release - Linux-aarch64: .github#96
...

๐Ÿข It looks we are coming to an end to this session. On which occasions will we create a release?

๐Ÿ‡ I think itโ€™s better to release non-alpha tags only.

๐Ÿข Then the rule in the release is release will be something like

on:
  workflow_dispatch:
  push:
    tags:
      - "v*.*.*"
      - "!v.*.*-alpha.*"

๐Ÿ‡ And now we have this result:

$ gh -R iesahin/xvc run list | rg Release | head -n 1
completed	success	v0.6.13	Release	v0.6.13	pull_request	12533498361	8m58s	2024-12-29T07:24:15Z

$ gh -R iesahin/xvc run view 12533498361

โœ“ v0.6.13 Release iesahin/xvc#263 ยท 12533498361
Triggered via pull_request about 21 minutes ago

JOBS
โœ“ Release - FreeBSD-x86_64 in 4m14s (ID 34953236573)
โœ“ Release - Linux-x86_64 in 4m3s (ID 34953236678)
โœ“ Release - Linux-aarch64 in 4m50s (ID 34953236735)
โœ“ Release - Windows-x86_64 in 8m47s (ID 34953236800)
โœ“ Release - Windows-aarch64 in 6m42s (ID 34953236848)
โœ“ Release - macOS-x86_64 in 2m37s (ID 34953236910)
โœ“ Release - macOS-aarch64 in 2m36s (ID 34953236965)

ARTIFACTS
xvc-macOS-arm64.tar.gz
xvc-macOS-x86_64.tar.gz
xvc-Linux-musl-x86_64.tar.gz
xvc-FreeBSD-x86_64.tar.gz
xvc-Linux-musl-arm64.tar.gz
xvc-Windows-msvc-arm64.zip
xvc-Windows-msvc-x86_64.zip

For more information about a job, try: gh run view --job=<job-id>
View this run on GitHub: https://github.com/iesahin/xvc/actions/runs/12533498361

๐Ÿข Ah, cool, letโ€™s check the release list

gh -R iesahin/xvc release list
v0.6.13-alpha.3	Latest	v0.6.13-alpha.3	2024-12-25T13:34:46Z
v0.6.13-alpha.2		v0.6.13-alpha.2	2024-12-13T19:05:11Z
v0.6.13-alpha.1		v0.6.13-alpha.1	2024-12-13T18:53:55Z
v0.6.13-alpha.0		v0.6.13-alpha.0	2024-11-30T18:36:49Z
...

๐Ÿ‡ Why there is no latest release?

๐Ÿข We must tag it first.

๐Ÿ‡ Ah, cool, letโ€™s tag then.

๐Ÿข Pushed changes and tagged with v.0.6.13-alpha.5

๐Ÿ‡ I think itโ€™s possible to make a release today.

๐Ÿข It looks so, yes.

๐Ÿ‡ We can merge the PR and tag it. Then everything should work.

๐Ÿข We need some cleanup though. In the YAML files.

๐Ÿ‡ We can leave it to the next release I think.

gh -R iesahin/xvc run list
in_progress		v0.6.13	Rust-CI	v0.6.13	pull_request	12533690474	9m18s	2024-12-29T08:02:29Z
completed	failure	Rust-CI	Rust-CI	v0.6.13-alpha.5	push	12533689102	6m9s	2024-12-29T08:02:19Z
completed	success	Release	Release	v0.6.13-alpha.5	push	12533689099	9m11s	2024-12-29T08:02:19Z
...

๐Ÿข Now we have another failure in the usual CI. Letโ€™s take a look at it.

<..> After downloading the logs and unzipping and checking

๐Ÿ‡ The issue seems to be in the doc tests, with

2024-12-29T08:14:40.7389990Z Testing docs/ref-xvc-file-copy.md:165 ... failed
...
---- expected: stdout
++++ actual:   stdout
| XC             [..] c85f3e81          data7.txt
| FC          19 [..] c85f3e81 c85f3e81 data6.txt
| SS        [..] [..] c85f3e81          data3.txt
| FC          19 [..] c85f3e81 c85f3e81 data2.txt
| XC             [..] c85f3e81          data.txt
| FH          19 [..] c85f3e81 c85f3e81 another-set/data3.txt
| FH          19 [..] c85f3e81 c85f3e81 another-set/data2.txt
| FH          19 [..] c85f3e81 c85f3e81 another-set/data.txt
| 
- Total #: 8 Workspace Size:         276 Cached Size:          19
+ Total #: 8 Workspace Size:         278 Cached Size:          19
| 

๐Ÿข These tests are brittle but they provide valuable information. Letโ€™s fix it and push again.

๐Ÿ‡ Did so. We can also remove some of the watches that produces so much logs.

๐Ÿข Iโ€™m a bit ambivalent about them. I was thinking that we could these watches when debugging but later experience showed that we need more granular watches when debugging and almost never use these in other times. Letโ€™s remove some of these as well.

๐Ÿ‡ We can output more in certain commands but the tracing output doesnโ€™t help much in the usual runs and if Xvc gets popular that we cannot cope with the bug reports, then we can put more watches anyway.

๐Ÿข Another option is to produce no code for watches for the release but that wonโ€™t change anything for our debug cycles.

๐Ÿ‡ I think this one is a fair trial. We can always put back watches when debugging.

๐Ÿข Watches can also produce usual output, instead of tracing. We wonโ€™t forget to remove them this way.

๐Ÿ‡ Ah, yep, thatโ€™s a good option too.

๐Ÿข We can have a trace! macro similar to the current one and we can use it for user consumption. Then we can also have a watch macro that sends output to the stderr.

๐Ÿ‡ Good idea. Letโ€™s do this in the next release.

๐Ÿข Letโ€™s take a look at the tests before pushing this cleanup

gh -R iesahin/xvc run list
completed	success	v0.6.13	Rust-CI	v0.6.13	pull_request	12533993607	13m49s	2024-12-29T08:47:50Z
...

๐Ÿ‡ CI succeeded and the release didnโ€™t run. Letโ€™s do some more cleanup.

gh -R iesahin/xvc run list
in_progress		v0.6.13	Rust-CI	v0.6.13	pull_request	12534416152	43s	2024-12-29T09:57:02Z
...

/blink.cmp/ /gh release/ /gh run/ /xvc/ /reflinks/ /cross compilation/ /Rust/