en Copyright 2015 Java http://172.16.0.5:8080/history/wasmtime-44.0.1/.github/actions/#133a0ef4 Debugging: add the debug-main world. (#12756)* Debugging: add the debug-main world.This PR "draws the rest of the owl" for the debug-mainworld (bytecodealliance/rfcs#45). This includes a WIT world that hostsdebug components that have access to "host debug powers" via adebugging API, and the ability to load such a debug-component and giveit control of the main program as a debuggee when using `wasmtimerun`.The WIT is namespaced to `bytecodealliance:wasmtime` and is slightlyaspirational in places: for example, the host does not yet implementinjection of early return values or exception-throws. I intend to fillout a series of TODO issues once this all lands to track followup("post-MVP") work.This PR does not include any debug components. I separately have agdbstub component, with which I tested and co-developed this host-sideimplementation. My plan is to land it in a followup PR as a componentthat will be embedded in/shipped with the Wasmtime CLI and availableunder an easy-to-use CLI option. Once we have that gdbstub component,we can also implement end-to-end integration tests that boot up LLDBand run through an expected interaction. (Separately, thoseintegration tests will require a release of wasi-sdk to ship an LLDBbinary that we can use.) As such, there are no real tests in this PR:interesting behaviors only really occur with a full end-to-end flow.The integration with the CLI is a little awkward (we internally buildanother `wasmtime run` command that invokes the debug component, andtie it together with the debuggee via a special `invoke_debugger` API;this seemed less bad than reworking all of the WASI setup to be morereusable). Happy to take more ideas here.* Review feedback.* Review feedback.* Review feedback: update vendor-wit.sh.* Review feedback: -Ddebugger-arg= -> -Darg=.* Review feedback.* Review feedback.* Review feedback: factor host.rs into several submodules.* Review feedback: rename Debugger to Debuggee on host side.* Review feedback: split inherit_stdin_stdout, and add corresponding options for the debug component.* Review feedback.* Review feedback.* Add simple debug-component tests.* Add wasm32-wasip2 target in a few places in CI* Cargo vets for wstd dependency.* Add wasm32-wasip2 in more places* fix debug-component test dependence on componentization byte offsets* Review feedback.* Fix cancel-safety of EventFuture.* Fix: Interrupted events should only occur after interrupt(), not on every epoch yield.* Review feedback.* Review feedback: strip down WASI imports in debugger world.* fold debugger test component back into wasip1 + adapter test artifact compilation flow List of files: /wasmtime-44.0.1/.github/actions/install-rust/action.yml Fri, 13 Mar 2026 18:00:00 +0000 Chris Fallin <chris@cfallin.org> http://172.16.0.5:8080/history/wasmtime-44.0.1/.github/actions/#232fd3cf Update to wasi-sdk-30 in CI (#12495)Testing it out and keeping it up-to-dateprtest:full List of files: /wasmtime-44.0.1/.github/actions/install-plugins-prerequisites/action.yml Wed, 04 Feb 2026 16:00:00 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/.github/actions/#7cca98e5 Update some github actions versions (#12762)CI is warning us about these, so try updating. List of files: /wasmtime-44.0.1/.github/actions/install-cargo-vet/action.yml Wed, 11 Mar 2026 19:00:00 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/.github/actions/#b9436666 Update nightly in CI (#9501)* Update nightly in CIThis commit updates nightly again in CI after failing to do so in #9496.This fixes an issue in our release CI where CMake was misconfigured whencross-compiling and creating `aarch64-pc-windows-msvc` artifacts.prtest:full* Try installing ninja* Also install Ninja on Linux List of files: /wasmtime-44.0.1/.github/actions/install-ninja/action.yml Thu, 24 Oct 2024 18:00:00 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/.github/actions/#83c80480 wasi-adapter: Implement provider crate that embeds the adapter binaries [v2] (#8874)* Add wasi adapter provider template which is materialised in CI* Add rustfmt component to adapter CI* Draft an extra publish step for the adapter provider* Check adapter provider in a separate step with adapter artifacts* Use artifact downloads in the publish action as well* Record results from adapter provider step as well* Refactor to use composite actions* Add missing shell property* Fix spelling mistake* Try using the env context List of files: /wasmtime-44.0.1/.github/actions/fetch-run-id/action.yml Mon, 08 Jul 2024 18:00:00 +0000 Juniper Tyree <50025784+juntyr@users.noreply.github.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/.github/actions/#10f27197 Migrate from Azure Pipelines to Github Actions (#474)This commit migrates wasmtime's CI infrastructure from Azure Pipelines to Github Actions. Using Github Actions has a few benefits over other offerings: * Being natively integrated with Github means that there's no degree of user account configuration or access control management, it's all inherent via already existing Github permissions. * Github Actions gives 20 parallel builders instead of Azure's 10 by default, which is a nice boost to have! Overall I've found Github Actions to feel a bit cleaner than Azure Pipelines as well. Subjectively I've found the configuration to be more readable and more pleasant to work with, although they're both just as "powerful" I think. Additionally Github Actions has been pretty solid in my own personal testing for a number of other projects. The main trickiness with wasmtime's CI is the rolling `dev` release of the master branch as well as binary releases for tags. Github Actions doesn't have quite as much built in functionality as Azure Pipelines, but Github Actions does have a nice feature where you can define the code for an action locally rather than only using built-in actions. This migration adds three local actions with some associated JS code to run the action (currently it looks like it basically requires JS) * An `install-rust` action papers over the gotchas about installing Rust, allowing Rust installation to be a one-liner in the configuration. * A `binary-compatible-builds` action allows easily configuring the wheels and the binaries to be "more binary compatible" and handles things like compilation flags on OSX and Windows while handling the `centos:6` container on Linux. * The `github-release` action is the logic using the `@actions/github` JS package to orchestrate the custom way we manage rolling releases, ensuring that a new release is made for the master branch under `dev` (deleting the previous tag/release ahead of time) and then also manages tagged releases by uploading them there. I'm hoping that most of the inline actions here will largely go away. For example `install-rust` should be simply `rustup update $toolchain` once various environment issues are fixed on Github Actions runner images. Additionally `github-release` will ideally migrate to something like https://github.com/actions/create-release or similar once it has enough functionality. I'm also hoping that the maintenance in the meantime of these actions is pretty low-cost, but if it becomes an issue we can look into other solutions! List of files: /wasmtime-44.0.1/.github/actions/install-rust/README.md Wed, 06 Nov 2019 01:00:00 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/.github/actions/#566669ee Refactor installation of C API and features supported (#8642)* Refactor installation of C API and features supportedThis commit overhauls and refactors the management of the building ofthe C API. Instead of this being script-based it's now done entirelythrough CMake and CMake is the primary focus for building the C API. Forexample building the C API release artifacts is now done through CMakeinstead of through a shell script's `cargo build` and manually movingartifacts.The benefits that this brings are:* The C API now properly hides symbols in its header files that weren't enabled at build time. This is done through a new build-time generated `conf.h` templated on a `conf.h.in` file in the source tree.* The C API's project now supports enabling/disabling Cargo features to have finer-grained support over what's included (plus auto-management of the header file).* Building the C API and managing it is now exclusively done through CMake. For example invoking `doxygen` now lives in CMake, installation lives there, etc.The `CMakeLists.txt` file for the C API is overhauled in the process ofdoing this. The build now primarily matches on the Rust target beingbuilt rather than the host target. Additionally installation will nowinstall both the static and shared libraries instead of just one.Additionally during this refactoring various bits and pieces ofAndroid-specific code were all removed. Management of the C toolchainfeels best left in scope of the caller (e.g. configuring `CC_*` env varsand such) rather than here.prtest:full* Don't use `option` for optional strings* Invert release build checkAlso adjust some indentation* Fix more indentation* Remove no-longer-used variable* Reduce duplication in feature macro List of files: /wasmtime-44.0.1/.github/actions/android-ndk/action.yml Mon, 20 May 2024 15:00:00 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/.github/actions/#819391b9 Update more github actions (#12775)Missed in the prior update... List of files: /wasmtime-44.0.1/.github/actions/build-adapter-provider/action.yml Fri, 13 Mar 2026 17:00:00 +0000 Alex Crichton <alex@alexcrichton.com>