Viceroy provides local testing for developers working with Compute@Edge.

Related tags

Testing Viceroy
Overview

Viceroy

Viceroy provides local testing for developers working with Compute@Edge. It allows you to run services written against the Compute@Edge APIs on your local development machine, and allows you to configure testing backends for your service to communicate with.

Viceroy is normally used through the Fastly CLI's fastly compute serve command, where it is fully integrated into Compute@Edge workflows. However, it is also a standalone open source tool with its own CLI and a Rust library that can be embedded into your own testing infrastructure.

Installation

Via the Fastly CLI

As mentioned above, most users of Compute@Edge should do local testing via the Fastly CLI, rather than working with Viceroy directly. Any CLI release of version 0.34 or above supports local testing, and the workflow is documented here.

As a standalone tool from crates.io

To install Viceroy as a standalone tool, you'll need to first install Rust if you haven't already. Then run cargo install viceroy, which will download and build the latest Viceroy release.

Usage as a standalone tool

NOTE: the Viceroy standalone CLI has a somewhat different interface from that of the Fastly CLI. Command-line options below describe the standalone Viceroy interface.

After installation, the viceroy command should be available on your path. The only required argument is the path to a compiled .wasm blob, which can be built by fastly compute build. The Fastly CLI should put the blob at bin/main.wasm. To test the service, you can run:

viceroy bin/main.wasm

This will start a local server (by default at: http://127.0.0.1:7878), which can be used to make requests to your Compute@Edge service locally. You can make requests by using curl, or you can send a simple GET request by visiting the URL in your web browser.

Working with Viceroy's source

Note that this repository uses Git submodules, so you will need to run

git submodule update --recursive --init

to pull down or update submodules.

Documentation

Since the Fastly CLI uses Viceroy under the hood, the two share documentation for everything other than CLI differences. You can find general documentation for local testing here, and documentation about configuring local testing here. Documentation for Viceroy's CLI can be found via --help.

Colophon

Viceroy

The viceroy is a butterfly whose color and pattern mimics that of the monarch butterfly but is smaller in size.

Comments
  • Immense build time

    Immense build time

    Hi, first of all, thanks for the great tooling. We use it as a library in our tests. In our POC, we have observed an enormous build time in the Github Actions. Not sure, if it is related to Rust in general or if we can optimize it further.

    opened by StarpTech 17
  • Missing build for Linux 386

    Missing build for Linux 386

    Originally reported by @epolish https://github.com/fastly/cli/issues/419.

    Summary:
    When using the Fastly CLI it reports an error when trying to download a version of Viceroy for the Linux OS and 386 Arch. This is because there is no such build in the Viceroy release.

    opened by Integralist 17
  • Request to have memory_pages (minimum page size) be configurable

    Request to have memory_pages (minimum page size) be configurable

    Thank you for building Viceroy, this is such a great project - I really really like that it is now possible to run Fastly code locally 🎉

    I've been working on porting https://polyfill.io (a Fastly sponsored project) to be fully in Compute@Edge using the JavaScript SDK.

    As of right now, due to the current lack of Edge Dictionary support in Viceroy (#11), I've inlined all the polyfills into the C@E code, this makes the bundled JavaScript file become 75.8 MB. After compiling the bundled JavaScript file into the Compute@Edge WASM file, it becomes 614 MB.

    When trying to run this WASM file using Viceroy, an error is thrown:

    Jul 31 20:33:53.927 ERROR memory index 0 has a minimum page size of 9469 which exceeds the limit of 2048

    Is the limit of 2048 a hard limit of the Fastly Compute@Edge platform? Would it be possible to have this limit raised of be configurable within Viceroy?

    Update: I cloned Viceroy and changed the minimum page size from 2,048 to 10,240, when running Viceroy with the wasm file it works and it used 620.6 MB of WebAssembly heap

    opened by JakeChampion 13
  • Add local dictionary support

    Add local dictionary support

    Resolves https://github.com/fastly/Viceroy/issues/11

    This reads a new section from the local_server part of fastly.toml named dictionaries.

    The local_server.dictionaries section is an array of tables with two fields: name, and file.

    The name field is a string which is used as the name of the dictionary and is used via the Dictionary.open method. This field uses the same validation rules asthe Fastly API (Name must start with alphabetical and contain only alphanumeric, underscore, and whitespace).

    The file field is a string which is a file-path pointing to a JSON file which contains all the dictionary items within an object.

    An example of a full local_server section of fastly.toml now looks like this:

    [local_server]
      [local_server.backends]
        [local_server.backends.dog]
          url = "http://localhost:7878/dog-mocks"
      [local_server.dictionaries]
        [local_server.dictionaries.a]
          file="./a.json"
          format = "json"
    

    Note for reviewers:

    I couldn't figure out how the tests are implements for the wiggle abi parts such as lib/src/wiggle_abi/dictionary_impl.rs. I assume they are implemented in an internal/private repo that Fastly has?


    • [X] Reading dictionaries from fasty.toml file
      • Note: I added the local dictionaries to the local_server section
    • [x] Construct Dictionary and DictionaryHandles
      • [x] Dictionaries have two fields: name, and file
      • [x] Validate name field with Fastly' validation rules (Name must start with alphabetical and contain only alphanumeric, underscore, and whitespace)
      • [x] Validate file file (perhaps by doing a file existence check and checking it is JSON which adheres to our schema)
    • [x] Implement Dictionary.open
    • [x] Implement Dictionary.get
    • [x] Tests
    • [ ] documentation
    opened by JakeChampion 12
  • Implement Geolocation mocking

    Implement Geolocation mocking

    This PR resolves #10 by adding support for mocked Geolocation responses. By default it will return the address of Fastly's HQ in San Francisco and users can override the response based on the requested IP address by modifying the fastly.toml file in the following manner:

    [local_server]
    	[local_server.geolocation]
                    format = "inline-toml"
                    [local_server.geolocation.addresses]
    		[local_server.geolocation.addresses."127.0.0.1"]
    			as_name = "Dummy, Inc."
    			city = "New York"
    			latitude = 1.23
    			longitude = 1.23
    

    or by providing it as an external resource:

    [local_server]
    	[local_server.geolocation]
                    format = "json"
    		file = "./test-geolocation-data.json"
    

    test-geolocation-data.json:

    {
        "127.0.0.1": {
            "as_name": "Fastly Test",
            "as_number": 12345,
            "area_code": 123,
            "city": "Test City",
            "conn_speed": "broadband",
            "conn_type": "wired",
            "continent": "NA",
            "country_code": "CA",
            "country_code3": "CAN",
            "country_name": "Canada",
            "latitude": 12.345,
            "longitude": 54.321,
            "metro_code": 0,
            "postal_code": "12345",
            "proxy_description": "?",
            "proxy_type": "?",
            "region": "CA-BC",
            "utc_offset": -700
        }
    }
    

    Current progress

    • [X] support for mocked GeoIP responses
    • [X] support for configuration through fastly.toml
    • [X] support for IPv6 lookups
    • [X] tests
    opened by bbutkovic 10
  • Support `--watch`ing and auto-reloading binary upon changes

    Support `--watch`ing and auto-reloading binary upon changes

    During development, it's extremely convenient to have the service automatically reload on change. This is a tracking issue for implementing "watching" functionality.


    Open Questions:

    • It might make sense to have it be the default behavior, perhaps with the ability to explicitly disable it?
    • Should Viceroy, or the Fastly CLI be responsible for watching files and reloading upon changes? How should the list of files to watch be specified, given that different languages must be supported? (cc: @Integralist)

    Originally reported by @tschneidereit; cc: @aturon, @peterbourgon.

    feature-ux 
    opened by cratelyn 10
  • Instrument and emit stats on program wall clock duration

    Instrument and emit stats on program wall clock duration

    Fastly's UI provides stats on the total wall clock of a Compute@Edge program running in production. Viceroy should emit information about the wall clock duration of a single instance execution, so that users can reason about the behavior of their program in production.

    • see also #77.
    • see also #78.
    feature-prod logging limits 
    opened by cratelyn 8
  • .config/fastly/viceroy: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found

    .config/fastly/viceroy: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found

    Version

    Fastly CLI version 1.5.0 (0d495f7)
    Built with go version go1.17.6 linux/amd64
    Viceroy version: viceroy 0.2.9
    
    

    What happened

    $ fastly compute serve --addr "127.0.0.1":7880 --skip-build
    Initializing...
    Fetching latest Viceroy release...
    Running local server...
    
    /home/cgutekunst/.config/fastly/viceroy: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /home/cgutekunst/.config/fastly/viceroy)
    
    ERROR: error during execution process:
    
    /home/cgutekunst/.config/fastly/viceroy: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /home/cgutekunst/.config/fastly/viceroy).
    
    If you believe this error is the result of a bug, please file an issue: https://github.com/fastly/cli/issues/new?labels=bug&template=bug_report.md
    

    System lsb:

    DISTRIB_ID=LinuxMint
    DISTRIB_RELEASE=19.3
    DISTRIB_CODENAME=tricia
    DISTRIB_DESCRIPTION="Linux Mint 19.3 Tricia"
    
    

    I'm guessing that the prebuilt (downloaded) version of Viceroy was built on Ubuntu 20; I'm on Mint 19.3, which is wrapper around Ubuntu 18.04 LTS.

    WORKAROUND

    Built viceroy from source and hard linked it from cargo/.bin to .config/fastly.

    opened by alameth 7
  • Implement Async IO Select Hostcalls

    Implement Async IO Select Hostcalls

    This commit adds the fastly_async_io hostcalls select and is_ready to Viceroy. Up to this point we only would do select for things like PendingRequest. Now we abstract over an AsyncItem which could be a PendingRequest, StreamingBody, or Body and you can call select over any of these async io operations. Most of this code is to accomodate these changes while maintaining the behavior of select for PendingRequest utilizing these new calls and creating the AsyncItem enum to hold all of these differing types in the same async_item map.

    We also add an integration test similar to the C@E platform's to make sure that we implement the behavior correctly. With this we can be confident that select works the way we intend it too! As a bonus side effect of these changes we also add async support for hosts in our testing code in Viceroy which gives us some more flexibility in what we can accomplish or use!

    opened by mgattozzi 6
  • Make environment variables available inside local server

    Make environment variables available inside local server

    In our test suite I have a few places I'd like to e.g. toggle some authentication logic based on environment variables.

    This currently seems impossible, as Viceroy only exposes the environment variables it has predefined such as FASTLY_HOSTNAME, but it is not possible to set your own env variables and have them be accessible inside fastly compute serve

    opened by GeeWee 6
  • auto_decompress_response_set has not yet been implemented in Viceroy

    auto_decompress_response_set has not yet been implemented in Viceroy

    Hello, we run into

     panicked at 'not implemented: auto_decompress_response_set has not yet been implemented in Viceroy', /home/starptech/.cargo/registry/src/github.com-1ecc6299db9ec823/viceroy-lib-0.2.8/src/wiggle_abi/req_impl.rs:476:9
    
         // Build client request
            let req = hyper::Request::builder()
                .method(Method::POST)
                .uri("http://example.com")
                .header("authorization", "bearer 123")
                .header("content-type", "application/json")
                .body(Body::from(serde_json::to_string(client_json_body).unwrap()))
                .unwrap();
    
            // Fire request
            let response = viceroy::handle_request(req, url).await.unwrap();
    

    when upgrading from "fastly: 0.8.0" to "fastly: 0.8.1"

    It will internally update

    [[package]]
    name = "fastly-shared"
    version = "0.8.1"
    source = "registry+https://github.com/rust-lang/crates.io-index"
    checksum = "a50fae8c678779e8dcd18e36f9982d09c706764e8976c542fd53193a62d83727"
    dependencies = [
     "bitflags",
     "http",
     "thiserror",
    ]
    
    [[package]]
    name = "fastly-sys"
    version = "0.8.1"
    source = "registry+https://github.com/rust-lang/crates.io-index"
    checksum = "afcf0f870a0c9ac8166b0797a9391e5df81b7b5cc13b53b4d305e0b1368801d4"
    dependencies = [
     "bitflags",
     "fastly-shared 0.8.1",
    ]
    

    It was introduced in https://github.com/fastly/Viceroy/commit/fee8165aa6396a348b946a31bc658acb291e8594

    Related: https://github.com/fastly/cli/issues/496

    opened by StarpTech 6
  • Bump tokio from 1.21.2 to 1.23.1 in /cli/tests/trap-test

    Bump tokio from 1.21.2 to 1.23.1 in /cli/tests/trap-test

    Bumps tokio from 1.21.2 to 1.23.1.

    Release notes

    Sourced from tokio's releases.

    Tokio v1.23.1

    This release forward ports changes from 1.18.4.

    Fixed

    • net: fix Windows named pipe server builder to maintain option when toggling pipe mode (#5336).

    #5336: tokio-rs/tokio#5336

    Tokio v1.23.0

    Fixed

    • net: fix Windows named pipe connect (#5208)
    • io: support vectored writes for ChildStdin (#5216)
    • io: fix async fn ready() false positive for OS-specific events (#5231)

    Changed

    • runtime: yield_now defers task until after driver poll (#5223)
    • runtime: reduce amount of codegen needed per spawned task (#5213)
    • windows: replace winapi dependency with windows-sys (#5204)

    #5208: tokio-rs/tokio#5208 #5216: tokio-rs/tokio#5216 #5213: tokio-rs/tokio#5213 #5204: tokio-rs/tokio#5204 #5223: tokio-rs/tokio#5223 #5231: tokio-rs/tokio#5231

    Tokio v1.22.0

    Added

    • runtime: add Handle::runtime_flavor (#5138)
    • sync: add Mutex::blocking_lock_owned (#5130)
    • sync: add Semaphore::MAX_PERMITS (#5144)
    • sync: add merge() to semaphore permits (#4948)
    • sync: add mpsc::WeakUnboundedSender (#5189)

    Added (unstable)

    • process: add Command::process_group (#5114)
    • runtime: export metrics about the blocking thread pool (#5161)
    • task: add task::id() and task::try_id() (#5171)

    Fixed

    • macros: don't take ownership of futures in macros (#5087)
    • runtime: fix Stacked Borrows violation in LocalOwnedTasks (#5099)
    • runtime: mitigate ABA with 32-bit queue indices when possible (#5042)
    • task: wake local tasks to the local queue when woken by the same thread (#5095)
    • time: panic in release mode when mark_pending called illegally (#5093)
    • runtime: fix typo in expect message (#5169)

    ... (truncated)

    Commits
    • 1a997ff chore: prepare Tokio v1.23.1 release
    • a8fe333 Merge branch 'tokio-1.20.x' into tokio-1.23.x
    • ba81945 chore: prepare Tokio 1.20.3 release
    • 763bdc9 ci: run WASI tasks using latest Rust
    • 9f98535 Merge remote-tracking branch 'origin/tokio-1.18.x' into fix-named-pipes-1.20
    • 9241c3e chore: prepare Tokio v1.18.4 release
    • 699573d net: fix named pipes server configuration builder
    • 3ce5a26 chore: prepare Tokio v1.23 release (#5270)
    • 644cb82 rt: fix *_closed false positives (#5231)
    • a1316cd io: impl std::io::BufRead on SyncIoBridge\<T> (#5265)
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

    You can disable automated security fix PRs for this repo from the Security Alerts page.

    dependencies 
    opened by dependabot[bot] 0
  • Bump tokio from 1.21.2 to 1.23.1

    Bump tokio from 1.21.2 to 1.23.1

    Bumps tokio from 1.21.2 to 1.23.1.

    Release notes

    Sourced from tokio's releases.

    Tokio v1.23.1

    This release forward ports changes from 1.18.4.

    Fixed

    • net: fix Windows named pipe server builder to maintain option when toggling pipe mode (#5336).

    #5336: tokio-rs/tokio#5336

    Tokio v1.23.0

    Fixed

    • net: fix Windows named pipe connect (#5208)
    • io: support vectored writes for ChildStdin (#5216)
    • io: fix async fn ready() false positive for OS-specific events (#5231)

    Changed

    • runtime: yield_now defers task until after driver poll (#5223)
    • runtime: reduce amount of codegen needed per spawned task (#5213)
    • windows: replace winapi dependency with windows-sys (#5204)

    #5208: tokio-rs/tokio#5208 #5216: tokio-rs/tokio#5216 #5213: tokio-rs/tokio#5213 #5204: tokio-rs/tokio#5204 #5223: tokio-rs/tokio#5223 #5231: tokio-rs/tokio#5231

    Tokio v1.22.0

    Added

    • runtime: add Handle::runtime_flavor (#5138)
    • sync: add Mutex::blocking_lock_owned (#5130)
    • sync: add Semaphore::MAX_PERMITS (#5144)
    • sync: add merge() to semaphore permits (#4948)
    • sync: add mpsc::WeakUnboundedSender (#5189)

    Added (unstable)

    • process: add Command::process_group (#5114)
    • runtime: export metrics about the blocking thread pool (#5161)
    • task: add task::id() and task::try_id() (#5171)

    Fixed

    • macros: don't take ownership of futures in macros (#5087)
    • runtime: fix Stacked Borrows violation in LocalOwnedTasks (#5099)
    • runtime: mitigate ABA with 32-bit queue indices when possible (#5042)
    • task: wake local tasks to the local queue when woken by the same thread (#5095)
    • time: panic in release mode when mark_pending called illegally (#5093)
    • runtime: fix typo in expect message (#5169)

    ... (truncated)

    Commits
    • 1a997ff chore: prepare Tokio v1.23.1 release
    • a8fe333 Merge branch 'tokio-1.20.x' into tokio-1.23.x
    • ba81945 chore: prepare Tokio 1.20.3 release
    • 763bdc9 ci: run WASI tasks using latest Rust
    • 9f98535 Merge remote-tracking branch 'origin/tokio-1.18.x' into fix-named-pipes-1.20
    • 9241c3e chore: prepare Tokio v1.18.4 release
    • 699573d net: fix named pipes server configuration builder
    • 3ce5a26 chore: prepare Tokio v1.23 release (#5270)
    • 644cb82 rt: fix *_closed false positives (#5231)
    • a1316cd io: impl std::io::BufRead on SyncIoBridge\<T> (#5265)
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

    You can disable automated security fix PRs for this repo from the Security Alerts page.

    dependencies 
    opened by dependabot[bot] 0
  • 🧪 Add a test runner mode that is compatible with `cargo test`

    🧪 Add a test runner mode that is compatible with `cargo test`

    This is still a work in progress, but getting it up for some initial review on the general shape here. The goal is to allow developers of C@E services to use Viceroy to run unit tests that rely on things provided by Fastly's SDKs. This is based off of a proof-of-concept that @acfoltzer put together a few months ago.

    how to use it

    As a Rust developer, the only thing you need to do to use this is put the following in your project's .cargo/config:

    [build]
    target = "wasm32-wasi"
    
    [target.wasm32-wasi]
    runner = "{PATH_TO_VICEROY_BINARY} -C fastly.toml --test"
    

    Then you can write tests that use the fastly crate a là:

    #[test]
    fn test_using_client_request() {
        let client_req = fastly::Request::from_client();
        assert_eq!(client_req.get_method(), Method::GET);
        assert_eq!(client_req.get_path(), "/");
    }
    
    #[test]
    fn test_using_bodies() {
        let mut body1 = fastly::Body::new();
        body1.write_str("hello, ");
        let mut body2 = fastly::Body::new();
        body2.write_str("Viceroy!");
        body1.append(body2);
        let appended_str = body1.into_string();
        assert_eq!(appended_str, "hello, Viceroy!");
    }
    
    #[test]
    fn test_a_handler_with_fastly_types() {
        let req = fastly::Request::get("http://example.com/Viceroy");
        let resp = some_handler(req).expect("request succeeds");
        assert_eq!(resp.get_content_type(), Some(TEXT_PLAIN_UTF_8));
        assert_eq!(resp.into_body_str(), "hello, /Viceroy!");
    }
    

    And run them with cargo test:

     % cargo test
       Compiling unit-tests-test v0.1.0 (/Users/rsinclair/src/fastly/test-runner-testing)
        Finished test [unoptimized + debuginfo] target(s) in 0.51s
         Running unittests src/main.rs (target/wasm32-wasi/debug/deps/unit_tests_test-11534a005cc5f600.wasm)
    Using Viceroy to run tests...
    running 3 tests
    test tests::test_a_handler_with_fastly_types ... ok
    test tests::test_using_bodies ... ok
    test tests::test_using_client_request ... ok
    
    test result: ok. 3 passed; 0 failed; 0 ignored
    

    how it works

    When you run cargo test, cargo produces a .wasm binary that contains all of your tests. By default, running this binary's _start function will execute all of your tests sequentially. Unfortunately when it runs into a test failure, it will panic and stop execution, preventing the rest of your tests from running. Fortunately, the binary produced by cargo test accepts arguments that allow us to control its execution in a more manageable way. To do that, this does the following:

    1. Execute the binary with the --list argument. This will return a list of all the tests in the binary.
    2. Execute the binary again with --list --ignored as arguments. This returns a list of just the ignored tests so we know which tests to ignore.
    3. Set up a Session with placeholders for request, remote IP, and response channel that we can pass into the binary.
    4. For each test in our list, execute the binary with the arguments --exact {test_name}. This will run only that test.
    5. Record the resulting stdout and stderr.
    6. Print out the test results in a format similar to cargo test's output

    things that might be nice to have

    • This doesn't allow the user to pass any additional arguments to cargo test (eg. cargo test specific_test_name or cargo test -- --no-capture).
    • It's entirely sequential right now, but the test execution could be done in parallel
    • a solution more generalizable to other language SDKs (related to the below)

    things i'm still unsure about

    • Do we want to support calls to backends in tests?
    • How much of the environment in Fastly.toml should be set up for this execution mode?
    • This is currently tied to being used in a very specific way by cargo test. Originally from chatting with @acfoltzer I had hoped to make this a more general execution mode that would simply set up the required state and naively run the provided binary's _start function. Unfortunately, querying the binary for the list of tests and running them one-by-one restricts this to only working with binaries produced by cargo test (or binaries with a very similar interface). I'm interested if anyone has ideas on how to get around that.
    • If we go this route and decide to continue adding support for things like additional arguments, configurable number of threads, etc, we run into a problem where we are pretty much re-implementing large swaths of the default cargo test runner. As a small example, this already tries to mimic the output of cargo test. This seems unideal and I'm not sure what to do about that.
    opened by itsrainy 1
  • Secret Store

    Secret Store

    This introduces types and hostcalls for the Secret Store, and implements them in Viceroy, along with configuration to instantiate them.

    In Compute@Edge, a Secret Store is an encrypted, read-only key-value store for sensitive data. In Viceroy, however, it is a simple unencrypted in-memory map defined in the fastly.toml file in a manner similar to Object Stores.

    At a high level, a Wasm application using the APIs would:

    1. Open a secret store by name
    2. Get a secret from the store by name
    3. Decrypt the secret by calling its plaintext method.

    In Viceroy, Secret Stores are configured in the same way Object Stores are:

    [local_server]
      [local_server.secret_store]
        store_one = [{key = "first", data = "This is some secret data"}, {key = "second", path = "/path/to/secret.json"}]
    
        [[local_server.secret_store.store_two]]
          key = "first"
          data = "This is also some secret data"
    
        [[local_server.secret_store.store_two]]
          key = "second"
          path = "/path/to/other/secret.json"
    

    This PR is based off of #203 because it requires the 0.9.0-pre1 Rust SDK.

    opened by joeshaw 3
  • Update to wasmtime 3.0 and enable wasi-nn calls

    Update to wasmtime 3.0 and enable wasi-nn calls

    The main purpose of this PR was to support wasi-nn calls inside Viceroy. As the necessary changes weren't available until the wasmtime 3.0 release, I also made the updates to to make it compatible with the broader changes in that specific release.

    The two big changes that came in were changes to the pattern for PoolingAllocationConfig and how error/traps are handled. There was also one minor change in that it looks like the linker is no longer under the tokio namespace.

    opened by geekbeast 2
  • Possible streaming body divergence on Windows

    Possible streaming body divergence on Windows

    In https://github.com/fastly/Viceroy/pull/188/, we found that Windows behaves differently than Unix-based platforms with respect to streaming bodies. In particular, the test tries to carefully construct a situation where we expect backpressure on a streaming body, and on Windows that backpressure seems to be cleared without either server or client side taking explicit action.

    It's not clear whether this behavior difference stems from the client or the server side; in both cases we are using Hyper.

    opened by aturon 0
Releases(v0.3.2)
Owner
Fastly
Fastly
ArchTest is a rule based architecture testing tool for rust

ArchTest is a rule based architecture testing tool. It applies static analyses on the specified rust project to extract use relationships.

Tom Dymel 7 Sep 26, 2021
Rnp - A simple cloud-friendly tool for testing network reachability.

Rnp - A simple cloud-friendly tool for testing network reachability. Release Status Crates.io Github release Nuget packages NOTE: This project is in e

Riff 50 Dec 13, 2022
Automated property based testing for Rust (with shrinking).

quickcheck QuickCheck is a way to do property based testing using randomly generated input. This crate comes with the ability to randomly generate and

Andrew Gallant 2k Jan 2, 2023
Hypothesis-like property testing for Rust

Proptest Introduction Proptest is a property testing framework (i.e., the QuickCheck family) inspired by the Hypothesis framework for Python. It allow

Jason Lingle 1.1k Jan 1, 2023
Simple assertion library for unit testing in python with a fluent API

Simple assertions library for unit testing in Python with a nice fluent API. Supports both Python 2 and 3.

snakedye 19 Sep 10, 2022
Simple goldenfile testing in Rust.

?? Rust Goldenfile Simple goldenfile testing in Rust. Goldenfile tests generate one or more output files as they run. At the end of the test, the gene

Calder Coalson 24 Nov 26, 2022
Declarative Testing Framework

Demonstrate allows tests to be written without as a much repetitive code within the demonstrate! macro, which will generate the corresponding full tests.

Austin Baugh 41 Aug 17, 2022
Cucumber testing framework for Rust. Fully native, no external test runners or dependencies.

An implementation of the Cucumber testing framework for Rust. Fully native, no external test runners or dependencies.

Brendan Molloy 394 Jan 1, 2023
🧵 Generate self-describing strings of a given length to help aid software testing

rust-counter-strings Counter strings generator written in rust to help aid software testing What is a counterstring? "A counterstring is a graduated s

Thomas Chaplin 23 Jun 24, 2022
Loom is a concurrency permutation testing tool for Rust.

Loom is a testing tool for concurrent Rust code

Tokio 1.4k Jan 9, 2023
Drill is an HTTP load testing application written in Rust inspired by Ansible syntax

Drill is an HTTP load testing application written in Rust inspired by Ansible syntax

Ferran Basora 1.5k Jan 1, 2023
assay - A super powered testing macro for Rust

assay - A super powered testing macro for Rust as·say /ˈaˌsā,aˈsā/ noun - the testing of a metal or ore to determine its ingredients and quality. Rust

Michael Gattozzi 105 Dec 4, 2022
🔥 Unit testing framework for Subgraph development on The Graph protocol. ⚙️

?? Welcome to Matchstick - a unit testing framework for The Graph protocol. Try out your mapping logic in a sandboxed environment and ensure your hand

null 157 Dec 20, 2022
This is a tiny (but delightful!) utility library for exhaustive testing.

Exhaustigen This is a tiny (but delightful!) utility library for exhaustive testing. It is based (directly) on the idea and code in the following blog

Graydon Hoare 34 Dec 14, 2022
Rust testing library

K9 - Rust Testing Library Snapshot testing + better assertions Available test macros snapshot assert_equal assert_greater_than assert_greater_than_or_

Aaron Abramov 269 Dec 10, 2022
Testing Framework for Rust

Polish Polish is Test-Driven Development done right Getting Started Installing the Package The crates.io package is kept up-to-date with all the major

Fadi Hanna Al-Kass 49 Dec 18, 2022
Rustress - stress testing library in Rust. For fun

rustress Simple network stress testing library. To get familiar with Rust Planned features (Subject to change) Multithreaded client/server Throughput

Hakan Sönmez 7 Sep 22, 2022
A series of utility macros for outputting testing results.

test-results A series of utility macros for outputting testing results. Getting Started Simply add the test-results crate to your project's Cargo.toml

EYHN 1 Jan 27, 2022
hb is an endpoint focused HTTP load testing / benchmark tool.

hb hb is an endpoint focused HTTP load testing / benchmark tool. Description The goal of hb is to provide a simple, robust tool to apply load against

Mark Pritchard 2 Aug 23, 2022