spin/.gitignore

17 lines
238 B
Plaintext
Raw Permalink Normal View History

target
.husky
Add prototype for distributing Spin applications using OCI This commit adds experimental support for distributing Spin applications using OCI registries. Specifically, it uses the OCI Artifacts specification (https://github.com/opencontainers/artifacts) to package and distribute Spin applications. This PR implements `spin oci push`, `spin oci pull`, and `spin oci run` to interact with a supporting container registry - for example: ```bash $ spin oci push ghcr.io/<username>/my-spin-application:v1 INFO spin_publish::oci::client: Pushed "https://ghcr.io/v2/<username>/my-spin-application/manifests/sha256:9f4e7eebb27c0174fe6654ef5e0f908f1edc8f625324a9f49967ccde44a6516b" $ spin oci pull ghcr.io/<username>/my-spin-application:v1 INFO spin_publish::oci::client: Pulled ghcr.io/<username>/my-spin-application:v1@sha256:9f4e7eebb27c0174fe6654ef5e0f908f1edc8f625324a9f49967ccde44a6516b $ spin oci run ghcr.io/<username>/my-spin-application:v1 INFO spin_publish::oci::client: Pulled ghcr.io/<username>/my-spin-application:v1@sha256:9f4e7eebb27c0174fe6654ef5e0f908f1edc8f625324a9f49967ccde44a6516b ``` Following the SIP (https://github.com/fermyon/spin/pull/1033), this PR defines a new `config.mediaType` for a Spin application, `application/vnd.fermyon.spin.application.v1+config`, and two media types for the potential content that can be found in such an artifact: `application/vnd.wasm.content.layer.v1+wasm` for a Wasm module, and `application/vnd.wasm.content.layer.v1+data` for a static file. (Note that the media types *can* change in a future iteration of this experimental work if a community consensus on the media type used to represent Wasm is reached.) Following the SIP, this PR distributes the Spin lockfile for a given application as the OCI configuration object. This PR also introduces a global cache for layers and manifests pulled from the registry. This is a content addressable cache, and its use will be extended in the future for Wasm modules pulled from HTTP sources. Currently, `spin oci pull` (or `spin oci run`) will always make at least an initial request to the registry to fetch the manifest from the registry. After the manifest is fetched, already pulled layers will not be pulled again. In a future commit, the behavior of the initial manifest fetch regardless of its existence in the cache will be controllable by a flag. Signed-off-by: Radu Matei <radu.matei@fermyon.com>
2022-12-21 04:18:57 +08:00
# cache
node_modules
ignored-assets
main.wasm
.parcel-cache
.vscode/*.log
tests/**/Cargo.lock
crates/**/Cargo.lock
add key-value-sqlite host component This is intended to be the default key-value store for Spin. Eventually, we'll provide others based on different backends (e.g. Redis) which may be selected and configured as part of spin.toml, a runtime config file, or a CLI option. Since I was wondering what overhead the SQLite dependency would add to Spin, I did some informal comparisons. It increases the stripped Spin release binary size by about 3% and increases the clean release build time by about 1.5%. simplify `KeyValueSqlite::get` fix type name in comment remove unused error variant case from key-value.wit various key-value store updates - Allow the key-value host component dynamically dispatch to multiple implementations (e.g. allowing an app to use SQLite and Redis simultaneously) - Enable configuring the key-value implementations when creating the host component - Rename `namespace` to `store` - Use `tokio::task::block_in_place` when doing SQLite I/O fix grammar in comment key-value: only support the default (unnamed) store by default This also adds a `rust-key-value` example. add documentation to table.rs remove unnecessary package.metadata.component directive from example address review feedback - Add more detailed comment about default KV store config and future runtime config - Add `Store::default` to SDK rename `sqlite::Config` to `sqlite::DatabaseLocation` address clippy warnings and fix doc grammar use local app dir for default KV database For remote apps and local apps in a read-only database, fall back to an in-memory database. These defaults may be overridden using the `--key-value-file` option. sync implementation with SIP - change `error::runtime` to `error::io` - add `get-keys` function to interface - remove `--key-value-file` CLI option in favor of a runtime config CLI rename default store to "default" add `key_value_stores` key to component config This tells Spin which stores, if any, a component is allowed to access. move SQLite KV implementation into its own crate This makes the `key-value` crate entirely implementation-agnostic, allowing runtimes to plug in whatever they want, without pulling in an SQLite dependency which might not be relevant. use "origin" metadata from app to find spin.toml refactor key-value host component to avoid deep clones update rust-key-value example Signed-off-by: Joel Dice <joel.dice@fermyon.com>
2023-01-19 00:53:06 +08:00
examples/**/Cargo.lock
tests/testcases/*-generated
spin-plugin-update.lock
package-lock.json
add key-value-sqlite host component This is intended to be the default key-value store for Spin. Eventually, we'll provide others based on different backends (e.g. Redis) which may be selected and configured as part of spin.toml, a runtime config file, or a CLI option. Since I was wondering what overhead the SQLite dependency would add to Spin, I did some informal comparisons. It increases the stripped Spin release binary size by about 3% and increases the clean release build time by about 1.5%. simplify `KeyValueSqlite::get` fix type name in comment remove unused error variant case from key-value.wit various key-value store updates - Allow the key-value host component dynamically dispatch to multiple implementations (e.g. allowing an app to use SQLite and Redis simultaneously) - Enable configuring the key-value implementations when creating the host component - Rename `namespace` to `store` - Use `tokio::task::block_in_place` when doing SQLite I/O fix grammar in comment key-value: only support the default (unnamed) store by default This also adds a `rust-key-value` example. add documentation to table.rs remove unnecessary package.metadata.component directive from example address review feedback - Add more detailed comment about default KV store config and future runtime config - Add `Store::default` to SDK rename `sqlite::Config` to `sqlite::DatabaseLocation` address clippy warnings and fix doc grammar use local app dir for default KV database For remote apps and local apps in a read-only database, fall back to an in-memory database. These defaults may be overridden using the `--key-value-file` option. sync implementation with SIP - change `error::runtime` to `error::io` - add `get-keys` function to interface - remove `--key-value-file` CLI option in favor of a runtime config CLI rename default store to "default" add `key_value_stores` key to component config This tells Spin which stores, if any, a component is allowed to access. move SQLite KV implementation into its own crate This makes the `key-value` crate entirely implementation-agnostic, allowing runtimes to plug in whatever they want, without pulling in an SQLite dependency which might not be relevant. use "origin" metadata from app to find spin.toml refactor key-value host component to avoid deep clones update rust-key-value example Signed-off-by: Joel Dice <joel.dice@fermyon.com>
2023-01-19 00:53:06 +08:00
.spin
.DS_Store