Release pipeline broken

[Mossaka]

1. Release of containerd-shim-wasm failed at cargo publish step: https://github.com/containerd/runwasi/actions/runs/6237777084
2. Release of wasmtime shim succeeded. It's failure on cargo publish is expected: https://github.com/containerd/runwasi/actions/runs/6237783420
3. Release of wasmer and wasmedge shims failed at integration tests on Ubuntu 20.04.: https://github.com/containerd/runwasi/actions/runs/6237788078, https://github.com/containerd/runwasi/actions/runs/6237793051

[jprendes]

The wasmer and wasmedge integration tests failures are a known issue.
The reason is that the release pipeline is invoking cargo test directly.
There are two options:

1. Parse the crate name, and use make test-{wasmtime,wasmedge,wasmer}
2. Copy what the makefile is doing, and use cargo test ... -- --test-threads=1

Option 2 would be simpler than doing string parsing on crate name, but means maintaining the test runner in both places.

It might also be worth noting that when we do docker buildx bake ... in the release pipeline, that is building all the binaries for all shims, instead of running only for the target shim. NVM, I missed the CRATE env-var

It's also a bit odd that we are building the shim in that step, after we succesfully built the shim with cargo build a few steps earlier.

[jprendes]

The first point is really weird, can we re-run that workflow?

[Mossaka]

Going to re-release the crates

[Mossaka]

Noticed that wasmtime release does not upload the shim binaries.

https://github.com/containerd/runwasi/releases/tag/containerd-shim-wasmtime%2Fv0.2.0

The Create release step in the release action outputs

No files to upload

See https://github.com/containerd/runwasi/actions/runs/6237783420/job/16932591959#step:6:19

[jprendes]

since we now generate gnu and musl build, I believe the name of the tar files have changed

[Mossaka]

containerd-shim-wasm failed again on cargo publish step

https://github.com/containerd/runwasi/actions/runs/6260852252/job/16999820595

[0xE282B0]

Is libseccomp missing?

[jprendes]

I think you are spot on @0xE282B0
youki-dev/youki#1454

I believe this is introduced by enabling seccomp unconditionally, which was not the case before.
Maybe that was a bad idea? That would break building the shims in containerd-wasm-shims that use cross, since libseccomp doesn't have a vendor feature.

[Mossaka]

Ah this reminds me that I've done something similar to the containerd-wasm-shims repo where the libseccomp feature was not turned on for linking with musl libc. Perhaps we could do something similar in this repo after PR #236 that added Alpine build.

Btw, is alpine build using musl or glibc? I am getting a feeling that it's using musl and that's the cause of the issues with our release pipeline.

Ref: https://github.com/deislabs/containerd-wasm-shims/blob/main/containerd-shim-spin-v1/Cargo.toml#L15C80-L15C120

[jprendes]

For runwasi, the simple solution would be to install libseccomp in the runner :-)

[jprendes]

Alpine uses musl, the release pipeline builds both, gnu and musl binaries.

[Mossaka]

This should be fixed now