Enable WASM-compat and monitor it in the CI (#142)
* fix: Use `target_pointer_size` conditional compilation
There are some parts of the code where is needed to de/serialze
`usize`s. These, have sizes that vary depending on the target
achitecture the code is compiled for.
Hence, this adapts the de/serialization to the specific pointer size for
which the crate is being compiled to.
* change: Support WASM-compatibility and polish Cargo.toml
In order to support Wasm-compat and to simplify and improve `Cargo.toml`
readability, the follwing changes have been made:
- All the deps that can use `parallel` feature, do so. As `rayon`
supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported
- `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears
to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions
- By default, the crate uses `"ark-circom/default"` which selects the
`wasmer/sys` feature such that it knows where wasmer is
suposed to be run`.
- Added a `wasm` feature which forces `ark-circom/wasm` to be used
instead. Which internally selects the `wasmer/js` backend to be used
such that in-browser execution is possible.
- Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such
that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets,
this is not the case as they're automatically supported.
For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support
* feat: Support WASM-compatibility tests in CI
Add support for both testing the build of `sonobe/folding-schemes` for
WASM-targets and also, it's build as a dependency for a WASM-crate.
This includes a build job for the three main supported rust-WASM targets
and the same but for a thrid crate creted on-the-fly which uses
`sonobe/folding-schemes` as a dependency.
* chore: Add README docs about WASM-compat & feats
* ci: don't run WASM-compat job if PR is draft
* chore: depend on `arnaucube/circom-compat` fork.
Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we
can already switch to it as we were depending before.
* chore: minimal build/test instructions
* fix: CI typos
* fix: Update CI to use correct feature sets
* fix: `ark-grumpkin` versioning issues
As mentioned in
https://github.com/privacy-scaling-explorations/sonobe/issues/146
there's a big issue that involves some dependencies of the crate.
As a temporary fix, this forces the workspace to rely on a
"non-existing" version of `ark-grumpkin` which is immediately patched at
workspace-level for a custom version that @arnaucube owns with some
cherry-picked commits.
While this allows the CI to pass and crate to build, a better solution
is needed.
* fix: Clippy CI avoiding --all-targets
* fix: use `wasm` feat only with folding-schemes 4 months ago Enable WASM-compat and monitor it in the CI (#142)
* fix: Use `target_pointer_size` conditional compilation
There are some parts of the code where is needed to de/serialze
`usize`s. These, have sizes that vary depending on the target
achitecture the code is compiled for.
Hence, this adapts the de/serialization to the specific pointer size for
which the crate is being compiled to.
* change: Support WASM-compatibility and polish Cargo.toml
In order to support Wasm-compat and to simplify and improve `Cargo.toml`
readability, the follwing changes have been made:
- All the deps that can use `parallel` feature, do so. As `rayon`
supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported
- `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears
to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions
- By default, the crate uses `"ark-circom/default"` which selects the
`wasmer/sys` feature such that it knows where wasmer is
suposed to be run`.
- Added a `wasm` feature which forces `ark-circom/wasm` to be used
instead. Which internally selects the `wasmer/js` backend to be used
such that in-browser execution is possible.
- Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such
that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets,
this is not the case as they're automatically supported.
For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support
* feat: Support WASM-compatibility tests in CI
Add support for both testing the build of `sonobe/folding-schemes` for
WASM-targets and also, it's build as a dependency for a WASM-crate.
This includes a build job for the three main supported rust-WASM targets
and the same but for a thrid crate creted on-the-fly which uses
`sonobe/folding-schemes` as a dependency.
* chore: Add README docs about WASM-compat & feats
* ci: don't run WASM-compat job if PR is draft
* chore: depend on `arnaucube/circom-compat` fork.
Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we
can already switch to it as we were depending before.
* chore: minimal build/test instructions
* fix: CI typos
* fix: Update CI to use correct feature sets
* fix: `ark-grumpkin` versioning issues
As mentioned in
https://github.com/privacy-scaling-explorations/sonobe/issues/146
there's a big issue that involves some dependencies of the crate.
As a temporary fix, this forces the workspace to rely on a
"non-existing" version of `ark-grumpkin` which is immediately patched at
workspace-level for a custom version that @arnaucube owns with some
cherry-picked commits.
While this allows the CI to pass and crate to build, a better solution
is needed.
* fix: Clippy CI avoiding --all-targets
* fix: use `wasm` feat only with folding-schemes 4 months ago Enable WASM-compat and monitor it in the CI (#142)
* fix: Use `target_pointer_size` conditional compilation
There are some parts of the code where is needed to de/serialze
`usize`s. These, have sizes that vary depending on the target
achitecture the code is compiled for.
Hence, this adapts the de/serialization to the specific pointer size for
which the crate is being compiled to.
* change: Support WASM-compatibility and polish Cargo.toml
In order to support Wasm-compat and to simplify and improve `Cargo.toml`
readability, the follwing changes have been made:
- All the deps that can use `parallel` feature, do so. As `rayon`
supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported
- `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears
to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions
- By default, the crate uses `"ark-circom/default"` which selects the
`wasmer/sys` feature such that it knows where wasmer is
suposed to be run`.
- Added a `wasm` feature which forces `ark-circom/wasm` to be used
instead. Which internally selects the `wasmer/js` backend to be used
such that in-browser execution is possible.
- Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such
that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets,
this is not the case as they're automatically supported.
For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support
* feat: Support WASM-compatibility tests in CI
Add support for both testing the build of `sonobe/folding-schemes` for
WASM-targets and also, it's build as a dependency for a WASM-crate.
This includes a build job for the three main supported rust-WASM targets
and the same but for a thrid crate creted on-the-fly which uses
`sonobe/folding-schemes` as a dependency.
* chore: Add README docs about WASM-compat & feats
* ci: don't run WASM-compat job if PR is draft
* chore: depend on `arnaucube/circom-compat` fork.
Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we
can already switch to it as we were depending before.
* chore: minimal build/test instructions
* fix: CI typos
* fix: Update CI to use correct feature sets
* fix: `ark-grumpkin` versioning issues
As mentioned in
https://github.com/privacy-scaling-explorations/sonobe/issues/146
there's a big issue that involves some dependencies of the crate.
As a temporary fix, this forces the workspace to rely on a
"non-existing" version of `ark-grumpkin` which is immediately patched at
workspace-level for a custom version that @arnaucube owns with some
cherry-picked commits.
While this allows the CI to pass and crate to build, a better solution
is needed.
* fix: Clippy CI avoiding --all-targets
* fix: use `wasm` feat only with folding-schemes 4 months ago Enable WASM-compat and monitor it in the CI (#142)
* fix: Use `target_pointer_size` conditional compilation
There are some parts of the code where is needed to de/serialze
`usize`s. These, have sizes that vary depending on the target
achitecture the code is compiled for.
Hence, this adapts the de/serialization to the specific pointer size for
which the crate is being compiled to.
* change: Support WASM-compatibility and polish Cargo.toml
In order to support Wasm-compat and to simplify and improve `Cargo.toml`
readability, the follwing changes have been made:
- All the deps that can use `parallel` feature, do so. As `rayon`
supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported
- `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears
to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions
- By default, the crate uses `"ark-circom/default"` which selects the
`wasmer/sys` feature such that it knows where wasmer is
suposed to be run`.
- Added a `wasm` feature which forces `ark-circom/wasm` to be used
instead. Which internally selects the `wasmer/js` backend to be used
such that in-browser execution is possible.
- Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such
that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets,
this is not the case as they're automatically supported.
For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support
* feat: Support WASM-compatibility tests in CI
Add support for both testing the build of `sonobe/folding-schemes` for
WASM-targets and also, it's build as a dependency for a WASM-crate.
This includes a build job for the three main supported rust-WASM targets
and the same but for a thrid crate creted on-the-fly which uses
`sonobe/folding-schemes` as a dependency.
* chore: Add README docs about WASM-compat & feats
* ci: don't run WASM-compat job if PR is draft
* chore: depend on `arnaucube/circom-compat` fork.
Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we
can already switch to it as we were depending before.
* chore: minimal build/test instructions
* fix: CI typos
* fix: Update CI to use correct feature sets
* fix: `ark-grumpkin` versioning issues
As mentioned in
https://github.com/privacy-scaling-explorations/sonobe/issues/146
there's a big issue that involves some dependencies of the crate.
As a temporary fix, this forces the workspace to rely on a
"non-existing" version of `ark-grumpkin` which is immediately patched at
workspace-level for a custom version that @arnaucube owns with some
cherry-picked commits.
While this allows the CI to pass and crate to build, a better solution
is needed.
* fix: Clippy CI avoiding --all-targets
* fix: use `wasm` feat only with folding-schemes 4 months ago Add solidity groth16, kzg10 and final decider verifiers in a dedicated workspace (#70)
* change: Refactor structure into workspace
* chore: Add empty readme
* change: Transform repo into workspace
* add: Create folding-verifier-solidity crate
* add: Include askama.toml for `sol` extension escaper
* add: Jordi's old Groth16 verifier .sol template and adapt it
* tmp: create simple template struct to test
* Update FoldingSchemes trait, fit Nova+CycleFold
- update lib.rs's `FoldingScheme` trait interface
- fit Nova+CycleFold into the `FoldingScheme` trait
- refactor `src/nova/*`
* chore: add serialization assets for testing
Now we include an `assets` folder with a serialized proof & vk for tests
* Add `examples` dir, with Nova's `FoldingScheme` example
* polishing
* expose poseidon_test_config outside tests
* change: Refactor structure into workspace
* chore: Add empty readme
* change: Transform repo into workspace
* add: Create folding-verifier-solidity crate
* add: Include askama.toml for `sol` extension escaper
* add: Jordi's old Groth16 verifier .sol template and adapt it
* tmp: create simple template struct to test
* feat: templating kzg working
* chore: add emv and revm
* feat: start evm file
* chore: add ark-poly-commit
* chore: move `commitment` to `folding-schemes`
* chore: update `.gitignore` to ignore generated contracts
* chore: update template with bn254 lib on it (avoids import), update for loop to account for whitespaces
* refactor: update template with no lib
* feat: add evm deploy code, compile and create kzg verifier
* chore: update `Cargo.toml` to have `folding-schemes` available with verifiers
* feat: start kzg prove and verify with sol
* chore: compute crs from kzg prover
* feat: evm kzg verification passing
* tmp
* change: Swap order of G2 coordinates within the template
* Update way to serialize proof with correct order
* chore: update `Cargo.toml`
* chore: add revm
* chore: add `save_solidity`
* refactor: verifiers in dedicated mod
* refactor: have dedicated `utils` module
* chore: expose modules
* chore: update verifier for kzg
* chore: rename templates
* fix: look for binary using also name of contract
* refactor: generate groth16 proof for sha256 pre-image, generate groth16 template with verifying key
* chore: template renaming
* fix: switch circuit for circuit that simply adds
* feat: generates test data on the fly
* feat: update to latest groth16 verifier
* refactor: rename folder, update `.gitignore`
* chore: update `Cargo.toml`
* chore: update templates extension to indicate that they are templates
* chore: rename templates, both files and structs
* fix: template inheritance working
* feat: template spdx and pragma statements
* feat: decider verifier compiles, update test for kzg10 and groth16 templates
* feat: parameterize which size of the crs should be stored on the contract
* chore: add comment on how the groth16 and kzg10 proofs will be linked together
* chore: cargo clippy run
* chore: cargo clippy tests
* chore: cargo fmt
* refactor: remove unused lifetime parameter
* chore: end merge
* chore: move examples to `folding-schemes` workspace
* get latest main changes
* fix: temp fix clippy warnings, will remove lints once not used in tests only
* fix: cargo clippy lint added on `code_size`
* fix: update path to test circuit and add step for installing solc
* chore: remove `save_solidity` steps
* fix: the borrowed expression implements the required traits
* chore: update `Cargo.toml`
* chore: remove extra `[patch.crates-io]`
* fix: update to patch at the workspace level and add comment explaining this
* refactor: correct `staticcall` with valid input/output sizes and change return syntax for pairing
* refactor: expose modules and remove `dead_code` calls
* chore: update `README.md`, add additional comments on `kzg10` template and update `groth16` template comments
* chore: be clearer on attributions on `kzg10`
---------
Co-authored-by: CPerezz <c.perezbaro@gmail.com>
Co-authored-by: arnaucube <root@arnaucube.com> 10 months ago Enable WASM-compat and monitor it in the CI (#142)
* fix: Use `target_pointer_size` conditional compilation
There are some parts of the code where is needed to de/serialze
`usize`s. These, have sizes that vary depending on the target
achitecture the code is compiled for.
Hence, this adapts the de/serialization to the specific pointer size for
which the crate is being compiled to.
* change: Support WASM-compatibility and polish Cargo.toml
In order to support Wasm-compat and to simplify and improve `Cargo.toml`
readability, the follwing changes have been made:
- All the deps that can use `parallel` feature, do so. As `rayon`
supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported
- `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears
to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions
- By default, the crate uses `"ark-circom/default"` which selects the
`wasmer/sys` feature such that it knows where wasmer is
suposed to be run`.
- Added a `wasm` feature which forces `ark-circom/wasm` to be used
instead. Which internally selects the `wasmer/js` backend to be used
such that in-browser execution is possible.
- Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such
that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets,
this is not the case as they're automatically supported.
For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support
* feat: Support WASM-compatibility tests in CI
Add support for both testing the build of `sonobe/folding-schemes` for
WASM-targets and also, it's build as a dependency for a WASM-crate.
This includes a build job for the three main supported rust-WASM targets
and the same but for a thrid crate creted on-the-fly which uses
`sonobe/folding-schemes` as a dependency.
* chore: Add README docs about WASM-compat & feats
* ci: don't run WASM-compat job if PR is draft
* chore: depend on `arnaucube/circom-compat` fork.
Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we
can already switch to it as we were depending before.
* chore: minimal build/test instructions
* fix: CI typos
* fix: Update CI to use correct feature sets
* fix: `ark-grumpkin` versioning issues
As mentioned in
https://github.com/privacy-scaling-explorations/sonobe/issues/146
there's a big issue that involves some dependencies of the crate.
As a temporary fix, this forces the workspace to rely on a
"non-existing" version of `ark-grumpkin` which is immediately patched at
workspace-level for a custom version that @arnaucube owns with some
cherry-picked commits.
While this allows the CI to pass and crate to build, a better solution
is needed.
* fix: Clippy CI avoiding --all-targets
* fix: use `wasm` feat only with folding-schemes 4 months ago Enable WASM-compat and monitor it in the CI (#142)
* fix: Use `target_pointer_size` conditional compilation
There are some parts of the code where is needed to de/serialze
`usize`s. These, have sizes that vary depending on the target
achitecture the code is compiled for.
Hence, this adapts the de/serialization to the specific pointer size for
which the crate is being compiled to.
* change: Support WASM-compatibility and polish Cargo.toml
In order to support Wasm-compat and to simplify and improve `Cargo.toml`
readability, the follwing changes have been made:
- All the deps that can use `parallel` feature, do so. As `rayon`
supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported
- `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears
to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions
- By default, the crate uses `"ark-circom/default"` which selects the
`wasmer/sys` feature such that it knows where wasmer is
suposed to be run`.
- Added a `wasm` feature which forces `ark-circom/wasm` to be used
instead. Which internally selects the `wasmer/js` backend to be used
such that in-browser execution is possible.
- Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such
that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets,
this is not the case as they're automatically supported.
For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support
* feat: Support WASM-compatibility tests in CI
Add support for both testing the build of `sonobe/folding-schemes` for
WASM-targets and also, it's build as a dependency for a WASM-crate.
This includes a build job for the three main supported rust-WASM targets
and the same but for a thrid crate creted on-the-fly which uses
`sonobe/folding-schemes` as a dependency.
* chore: Add README docs about WASM-compat & feats
* ci: don't run WASM-compat job if PR is draft
* chore: depend on `arnaucube/circom-compat` fork.
Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we
can already switch to it as we were depending before.
* chore: minimal build/test instructions
* fix: CI typos
* fix: Update CI to use correct feature sets
* fix: `ark-grumpkin` versioning issues
As mentioned in
https://github.com/privacy-scaling-explorations/sonobe/issues/146
there's a big issue that involves some dependencies of the crate.
As a temporary fix, this forces the workspace to rely on a
"non-existing" version of `ark-grumpkin` which is immediately patched at
workspace-level for a custom version that @arnaucube owns with some
cherry-picked commits.
While this allows the CI to pass and crate to build, a better solution
is needed.
* fix: Clippy CI avoiding --all-targets
* fix: use `wasm` feat only with folding-schemes 4 months ago Enable WASM-compat and monitor it in the CI (#142)
* fix: Use `target_pointer_size` conditional compilation
There are some parts of the code where is needed to de/serialze
`usize`s. These, have sizes that vary depending on the target
achitecture the code is compiled for.
Hence, this adapts the de/serialization to the specific pointer size for
which the crate is being compiled to.
* change: Support WASM-compatibility and polish Cargo.toml
In order to support Wasm-compat and to simplify and improve `Cargo.toml`
readability, the follwing changes have been made:
- All the deps that can use `parallel` feature, do so. As `rayon`
supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported
- `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears
to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions
- By default, the crate uses `"ark-circom/default"` which selects the
`wasmer/sys` feature such that it knows where wasmer is
suposed to be run`.
- Added a `wasm` feature which forces `ark-circom/wasm` to be used
instead. Which internally selects the `wasmer/js` backend to be used
such that in-browser execution is possible.
- Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such
that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets,
this is not the case as they're automatically supported.
For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support
* feat: Support WASM-compatibility tests in CI
Add support for both testing the build of `sonobe/folding-schemes` for
WASM-targets and also, it's build as a dependency for a WASM-crate.
This includes a build job for the three main supported rust-WASM targets
and the same but for a thrid crate creted on-the-fly which uses
`sonobe/folding-schemes` as a dependency.
* chore: Add README docs about WASM-compat & feats
* ci: don't run WASM-compat job if PR is draft
* chore: depend on `arnaucube/circom-compat` fork.
Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we
can already switch to it as we were depending before.
* chore: minimal build/test instructions
* fix: CI typos
* fix: Update CI to use correct feature sets
* fix: `ark-grumpkin` versioning issues
As mentioned in
https://github.com/privacy-scaling-explorations/sonobe/issues/146
there's a big issue that involves some dependencies of the crate.
As a temporary fix, this forces the workspace to rely on a
"non-existing" version of `ark-grumpkin` which is immediately patched at
workspace-level for a custom version that @arnaucube owns with some
cherry-picked commits.
While this allows the CI to pass and crate to build, a better solution
is needed.
* fix: Clippy CI avoiding --all-targets
* fix: use `wasm` feat only with folding-schemes 4 months ago Enable WASM-compat and monitor it in the CI (#142)
* fix: Use `target_pointer_size` conditional compilation
There are some parts of the code where is needed to de/serialze
`usize`s. These, have sizes that vary depending on the target
achitecture the code is compiled for.
Hence, this adapts the de/serialization to the specific pointer size for
which the crate is being compiled to.
* change: Support WASM-compatibility and polish Cargo.toml
In order to support Wasm-compat and to simplify and improve `Cargo.toml`
readability, the follwing changes have been made:
- All the deps that can use `parallel` feature, do so. As `rayon`
supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported
- `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears
to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions
- By default, the crate uses `"ark-circom/default"` which selects the
`wasmer/sys` feature such that it knows where wasmer is
suposed to be run`.
- Added a `wasm` feature which forces `ark-circom/wasm` to be used
instead. Which internally selects the `wasmer/js` backend to be used
such that in-browser execution is possible.
- Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such
that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets,
this is not the case as they're automatically supported.
For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support
* feat: Support WASM-compatibility tests in CI
Add support for both testing the build of `sonobe/folding-schemes` for
WASM-targets and also, it's build as a dependency for a WASM-crate.
This includes a build job for the three main supported rust-WASM targets
and the same but for a thrid crate creted on-the-fly which uses
`sonobe/folding-schemes` as a dependency.
* chore: Add README docs about WASM-compat & feats
* ci: don't run WASM-compat job if PR is draft
* chore: depend on `arnaucube/circom-compat` fork.
Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we
can already switch to it as we were depending before.
* chore: minimal build/test instructions
* fix: CI typos
* fix: Update CI to use correct feature sets
* fix: `ark-grumpkin` versioning issues
As mentioned in
https://github.com/privacy-scaling-explorations/sonobe/issues/146
there's a big issue that involves some dependencies of the crate.
As a temporary fix, this forces the workspace to rely on a
"non-existing" version of `ark-grumpkin` which is immediately patched at
workspace-level for a custom version that @arnaucube owns with some
cherry-picked commits.
While this allows the CI to pass and crate to build, a better solution
is needed.
* fix: Clippy CI avoiding --all-targets
* fix: use `wasm` feat only with folding-schemes 4 months ago Enable WASM-compat and monitor it in the CI (#142)
* fix: Use `target_pointer_size` conditional compilation
There are some parts of the code where is needed to de/serialze
`usize`s. These, have sizes that vary depending on the target
achitecture the code is compiled for.
Hence, this adapts the de/serialization to the specific pointer size for
which the crate is being compiled to.
* change: Support WASM-compatibility and polish Cargo.toml
In order to support Wasm-compat and to simplify and improve `Cargo.toml`
readability, the follwing changes have been made:
- All the deps that can use `parallel` feature, do so. As `rayon`
supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported
- `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears
to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions
- By default, the crate uses `"ark-circom/default"` which selects the
`wasmer/sys` feature such that it knows where wasmer is
suposed to be run`.
- Added a `wasm` feature which forces `ark-circom/wasm` to be used
instead. Which internally selects the `wasmer/js` backend to be used
such that in-browser execution is possible.
- Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such
that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets,
this is not the case as they're automatically supported.
For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support
* feat: Support WASM-compatibility tests in CI
Add support for both testing the build of `sonobe/folding-schemes` for
WASM-targets and also, it's build as a dependency for a WASM-crate.
This includes a build job for the three main supported rust-WASM targets
and the same but for a thrid crate creted on-the-fly which uses
`sonobe/folding-schemes` as a dependency.
* chore: Add README docs about WASM-compat & feats
* ci: don't run WASM-compat job if PR is draft
* chore: depend on `arnaucube/circom-compat` fork.
Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we
can already switch to it as we were depending before.
* chore: minimal build/test instructions
* fix: CI typos
* fix: Update CI to use correct feature sets
* fix: `ark-grumpkin` versioning issues
As mentioned in
https://github.com/privacy-scaling-explorations/sonobe/issues/146
there's a big issue that involves some dependencies of the crate.
As a temporary fix, this forces the workspace to rely on a
"non-existing" version of `ark-grumpkin` which is immediately patched at
workspace-level for a custom version that @arnaucube owns with some
cherry-picked commits.
While this allows the CI to pass and crate to build, a better solution
is needed.
* fix: Clippy CI avoiding --all-targets
* fix: use `wasm` feat only with folding-schemes 4 months ago Enable WASM-compat and monitor it in the CI (#142)
* fix: Use `target_pointer_size` conditional compilation
There are some parts of the code where is needed to de/serialze
`usize`s. These, have sizes that vary depending on the target
achitecture the code is compiled for.
Hence, this adapts the de/serialization to the specific pointer size for
which the crate is being compiled to.
* change: Support WASM-compatibility and polish Cargo.toml
In order to support Wasm-compat and to simplify and improve `Cargo.toml`
readability, the follwing changes have been made:
- All the deps that can use `parallel` feature, do so. As `rayon`
supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported
- `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears
to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions
- By default, the crate uses `"ark-circom/default"` which selects the
`wasmer/sys` feature such that it knows where wasmer is
suposed to be run`.
- Added a `wasm` feature which forces `ark-circom/wasm` to be used
instead. Which internally selects the `wasmer/js` backend to be used
such that in-browser execution is possible.
- Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such
that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets,
this is not the case as they're automatically supported.
For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support
* feat: Support WASM-compatibility tests in CI
Add support for both testing the build of `sonobe/folding-schemes` for
WASM-targets and also, it's build as a dependency for a WASM-crate.
This includes a build job for the three main supported rust-WASM targets
and the same but for a thrid crate creted on-the-fly which uses
`sonobe/folding-schemes` as a dependency.
* chore: Add README docs about WASM-compat & feats
* ci: don't run WASM-compat job if PR is draft
* chore: depend on `arnaucube/circom-compat` fork.
Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we
can already switch to it as we were depending before.
* chore: minimal build/test instructions
* fix: CI typos
* fix: Update CI to use correct feature sets
* fix: `ark-grumpkin` versioning issues
As mentioned in
https://github.com/privacy-scaling-explorations/sonobe/issues/146
there's a big issue that involves some dependencies of the crate.
As a temporary fix, this forces the workspace to rely on a
"non-existing" version of `ark-grumpkin` which is immediately patched at
workspace-level for a custom version that @arnaucube owns with some
cherry-picked commits.
While this allows the CI to pass and crate to build, a better solution
is needed.
* fix: Clippy CI avoiding --all-targets
* fix: use `wasm` feat only with folding-schemes 4 months ago Enable WASM-compat and monitor it in the CI (#142)
* fix: Use `target_pointer_size` conditional compilation
There are some parts of the code where is needed to de/serialze
`usize`s. These, have sizes that vary depending on the target
achitecture the code is compiled for.
Hence, this adapts the de/serialization to the specific pointer size for
which the crate is being compiled to.
* change: Support WASM-compatibility and polish Cargo.toml
In order to support Wasm-compat and to simplify and improve `Cargo.toml`
readability, the follwing changes have been made:
- All the deps that can use `parallel` feature, do so. As `rayon`
supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported
- `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears
to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions
- By default, the crate uses `"ark-circom/default"` which selects the
`wasmer/sys` feature such that it knows where wasmer is
suposed to be run`.
- Added a `wasm` feature which forces `ark-circom/wasm` to be used
instead. Which internally selects the `wasmer/js` backend to be used
such that in-browser execution is possible.
- Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such
that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets,
this is not the case as they're automatically supported.
For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support
* feat: Support WASM-compatibility tests in CI
Add support for both testing the build of `sonobe/folding-schemes` for
WASM-targets and also, it's build as a dependency for a WASM-crate.
This includes a build job for the three main supported rust-WASM targets
and the same but for a thrid crate creted on-the-fly which uses
`sonobe/folding-schemes` as a dependency.
* chore: Add README docs about WASM-compat & feats
* ci: don't run WASM-compat job if PR is draft
* chore: depend on `arnaucube/circom-compat` fork.
Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we
can already switch to it as we were depending before.
* chore: minimal build/test instructions
* fix: CI typos
* fix: Update CI to use correct feature sets
* fix: `ark-grumpkin` versioning issues
As mentioned in
https://github.com/privacy-scaling-explorations/sonobe/issues/146
there's a big issue that involves some dependencies of the crate.
As a temporary fix, this forces the workspace to rely on a
"non-existing" version of `ark-grumpkin` which is immediately patched at
workspace-level for a custom version that @arnaucube owns with some
cherry-picked commits.
While this allows the CI to pass and crate to build, a better solution
is needed.
* fix: Clippy CI avoiding --all-targets
* fix: use `wasm` feat only with folding-schemes 4 months ago Enable WASM-compat and monitor it in the CI (#142)
* fix: Use `target_pointer_size` conditional compilation
There are some parts of the code where is needed to de/serialze
`usize`s. These, have sizes that vary depending on the target
achitecture the code is compiled for.
Hence, this adapts the de/serialization to the specific pointer size for
which the crate is being compiled to.
* change: Support WASM-compatibility and polish Cargo.toml
In order to support Wasm-compat and to simplify and improve `Cargo.toml`
readability, the follwing changes have been made:
- All the deps that can use `parallel` feature, do so. As `rayon`
supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported
- `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears
to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions
- By default, the crate uses `"ark-circom/default"` which selects the
`wasmer/sys` feature such that it knows where wasmer is
suposed to be run`.
- Added a `wasm` feature which forces `ark-circom/wasm` to be used
instead. Which internally selects the `wasmer/js` backend to be used
such that in-browser execution is possible.
- Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such
that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets,
this is not the case as they're automatically supported.
For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support
* feat: Support WASM-compatibility tests in CI
Add support for both testing the build of `sonobe/folding-schemes` for
WASM-targets and also, it's build as a dependency for a WASM-crate.
This includes a build job for the three main supported rust-WASM targets
and the same but for a thrid crate creted on-the-fly which uses
`sonobe/folding-schemes` as a dependency.
* chore: Add README docs about WASM-compat & feats
* ci: don't run WASM-compat job if PR is draft
* chore: depend on `arnaucube/circom-compat` fork.
Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we
can already switch to it as we were depending before.
* chore: minimal build/test instructions
* fix: CI typos
* fix: Update CI to use correct feature sets
* fix: `ark-grumpkin` versioning issues
As mentioned in
https://github.com/privacy-scaling-explorations/sonobe/issues/146
there's a big issue that involves some dependencies of the crate.
As a temporary fix, this forces the workspace to rely on a
"non-existing" version of `ark-grumpkin` which is immediately patched at
workspace-level for a custom version that @arnaucube owns with some
cherry-picked commits.
While this allows the CI to pass and crate to build, a better solution
is needed.
* fix: Clippy CI avoiding --all-targets
* fix: use `wasm` feat only with folding-schemes 4 months ago Enable WASM-compat and monitor it in the CI (#142)
* fix: Use `target_pointer_size` conditional compilation
There are some parts of the code where is needed to de/serialze
`usize`s. These, have sizes that vary depending on the target
achitecture the code is compiled for.
Hence, this adapts the de/serialization to the specific pointer size for
which the crate is being compiled to.
* change: Support WASM-compatibility and polish Cargo.toml
In order to support Wasm-compat and to simplify and improve `Cargo.toml`
readability, the follwing changes have been made:
- All the deps that can use `parallel` feature, do so. As `rayon`
supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported
- `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears
to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions
- By default, the crate uses `"ark-circom/default"` which selects the
`wasmer/sys` feature such that it knows where wasmer is
suposed to be run`.
- Added a `wasm` feature which forces `ark-circom/wasm` to be used
instead. Which internally selects the `wasmer/js` backend to be used
such that in-browser execution is possible.
- Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such
that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets,
this is not the case as they're automatically supported.
For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support
* feat: Support WASM-compatibility tests in CI
Add support for both testing the build of `sonobe/folding-schemes` for
WASM-targets and also, it's build as a dependency for a WASM-crate.
This includes a build job for the three main supported rust-WASM targets
and the same but for a thrid crate creted on-the-fly which uses
`sonobe/folding-schemes` as a dependency.
* chore: Add README docs about WASM-compat & feats
* ci: don't run WASM-compat job if PR is draft
* chore: depend on `arnaucube/circom-compat` fork.
Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we
can already switch to it as we were depending before.
* chore: minimal build/test instructions
* fix: CI typos
* fix: Update CI to use correct feature sets
* fix: `ark-grumpkin` versioning issues
As mentioned in
https://github.com/privacy-scaling-explorations/sonobe/issues/146
there's a big issue that involves some dependencies of the crate.
As a temporary fix, this forces the workspace to rely on a
"non-existing" version of `ark-grumpkin` which is immediately patched at
workspace-level for a custom version that @arnaucube owns with some
cherry-picked commits.
While this allows the CI to pass and crate to build, a better solution
is needed.
* fix: Clippy CI avoiding --all-targets
* fix: use `wasm` feat only with folding-schemes 4 months ago Enable WASM-compat and monitor it in the CI (#142)
* fix: Use `target_pointer_size` conditional compilation
There are some parts of the code where is needed to de/serialze
`usize`s. These, have sizes that vary depending on the target
achitecture the code is compiled for.
Hence, this adapts the de/serialization to the specific pointer size for
which the crate is being compiled to.
* change: Support WASM-compatibility and polish Cargo.toml
In order to support Wasm-compat and to simplify and improve `Cargo.toml`
readability, the follwing changes have been made:
- All the deps that can use `parallel` feature, do so. As `rayon`
supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported
- `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears
to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions
- By default, the crate uses `"ark-circom/default"` which selects the
`wasmer/sys` feature such that it knows where wasmer is
suposed to be run`.
- Added a `wasm` feature which forces `ark-circom/wasm` to be used
instead. Which internally selects the `wasmer/js` backend to be used
such that in-browser execution is possible.
- Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such
that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets,
this is not the case as they're automatically supported.
For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support
* feat: Support WASM-compatibility tests in CI
Add support for both testing the build of `sonobe/folding-schemes` for
WASM-targets and also, it's build as a dependency for a WASM-crate.
This includes a build job for the three main supported rust-WASM targets
and the same but for a thrid crate creted on-the-fly which uses
`sonobe/folding-schemes` as a dependency.
* chore: Add README docs about WASM-compat & feats
* ci: don't run WASM-compat job if PR is draft
* chore: depend on `arnaucube/circom-compat` fork.
Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we
can already switch to it as we were depending before.
* chore: minimal build/test instructions
* fix: CI typos
* fix: Update CI to use correct feature sets
* fix: `ark-grumpkin` versioning issues
As mentioned in
https://github.com/privacy-scaling-explorations/sonobe/issues/146
there's a big issue that involves some dependencies of the crate.
As a temporary fix, this forces the workspace to rely on a
"non-existing" version of `ark-grumpkin` which is immediately patched at
workspace-level for a custom version that @arnaucube owns with some
cherry-picked commits.
While this allows the CI to pass and crate to build, a better solution
is needed.
* fix: Clippy CI avoiding --all-targets
* fix: use `wasm` feat only with folding-schemes 4 months ago Enable WASM-compat and monitor it in the CI (#142)
* fix: Use `target_pointer_size` conditional compilation
There are some parts of the code where is needed to de/serialze
`usize`s. These, have sizes that vary depending on the target
achitecture the code is compiled for.
Hence, this adapts the de/serialization to the specific pointer size for
which the crate is being compiled to.
* change: Support WASM-compatibility and polish Cargo.toml
In order to support Wasm-compat and to simplify and improve `Cargo.toml`
readability, the follwing changes have been made:
- All the deps that can use `parallel` feature, do so. As `rayon`
supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported
- `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears
to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions
- By default, the crate uses `"ark-circom/default"` which selects the
`wasmer/sys` feature such that it knows where wasmer is
suposed to be run`.
- Added a `wasm` feature which forces `ark-circom/wasm` to be used
instead. Which internally selects the `wasmer/js` backend to be used
such that in-browser execution is possible.
- Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such
that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets,
this is not the case as they're automatically supported.
For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support
* feat: Support WASM-compatibility tests in CI
Add support for both testing the build of `sonobe/folding-schemes` for
WASM-targets and also, it's build as a dependency for a WASM-crate.
This includes a build job for the three main supported rust-WASM targets
and the same but for a thrid crate creted on-the-fly which uses
`sonobe/folding-schemes` as a dependency.
* chore: Add README docs about WASM-compat & feats
* ci: don't run WASM-compat job if PR is draft
* chore: depend on `arnaucube/circom-compat` fork.
Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we
can already switch to it as we were depending before.
* chore: minimal build/test instructions
* fix: CI typos
* fix: Update CI to use correct feature sets
* fix: `ark-grumpkin` versioning issues
As mentioned in
https://github.com/privacy-scaling-explorations/sonobe/issues/146
there's a big issue that involves some dependencies of the crate.
As a temporary fix, this forces the workspace to rely on a
"non-existing" version of `ark-grumpkin` which is immediately patched at
workspace-level for a custom version that @arnaucube owns with some
cherry-picked commits.
While this allows the CI to pass and crate to build, a better solution
is needed.
* fix: Clippy CI avoiding --all-targets
* fix: use `wasm` feat only with folding-schemes 4 months ago |
|
name: CI Check
on:
merge_group:
pull_request:
push:
branches:
- main
env:
CARGO_TERM_COLOR: always
# Disable incremental compilation.
#
# Incremental compilation is useful as part of an edit-build-test-edit cycle,
# as it lets the compiler avoid recompiling code that hasn't changed. However,
# on CI, we're not making small edits; we're almost always building the entire
# project from scratch. Thus, incremental compilation on CI actually
# introduces *additional* overhead to support making future builds
# faster...but no future builds will ever occur in any given CI environment.
#
# See https://matklad.github.io/2021/09/04/fast-rust-builds.html#ci-workflow
# for details.
CARGO_INCREMENTAL: 0
# Allow more retries for network requests in cargo (downloading crates) and
# rustup (installing toolchains). This should help to reduce flaky CI failures
# from transient network timeouts or other issues.
CARGO_NET_RETRY: 10
RUSTUP_MAX_RETRIES: 10
# Don't emit giant backtraces in the CI logs.
RUST_BACKTRACE: short
# Jobs launched for a PR event cancel the ongoing one for the same workflow + PR,
# Only retries (of the same run) for a Push event cancel the prior one.
concurrency:
group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
cancel-in-progress: true
jobs:
test:
if: github.event.pull_request.draft == false
name: Test
runs-on: ubuntu-latest
strategy:
matrix:
feature_set: [basic]
include:
- feature_set: basic
features: --features default,light-test
steps:
- uses: actions/checkout@v2
- uses: actions-rs/toolchain@v1
- uses: noir-lang/noirup@v0.1.3
with:
toolchain: nightly
- name: Download Circom
run: |
mkdir -p $HOME/bin
curl -sSfL https://github.com/iden3/circom/releases/download/v2.1.6/circom-linux-amd64 -o $HOME/bin/circom
chmod +x $HOME/bin/circom
echo "$HOME/bin" >> $GITHUB_PATH
- name: Download solc
run: |
curl -sSfL https://github.com/ethereum/solidity/releases/download/v0.8.4/solc-static-linux -o /usr/local/bin/solc
chmod +x /usr/local/bin/solc
- name: Execute compile.sh to generate .r1cs and .wasm from .circom
run: ./frontends/src/circom/test_folder/compile.sh
- name: Execute compile.sh to generate .json from noir
run: ./frontends/src/noir/test_folder/compile.sh
- name: Run tests
uses: actions-rs/cargo@v1
with:
command: test
args: --release --workspace --no-default-features ${{ matrix.features }}
- name: Run Doc-tests
uses: actions-rs/cargo@v1
with:
command: test
args: --doc
build:
if: github.event.pull_request.draft == false
name: Build target ${{ matrix.target }}
runs-on: ubuntu-latest
strategy:
matrix:
target:
- wasm32-unknown-unknown
- wasm32-wasi
# Ignoring until clear usage is required
# - wasm32-unknown-emscripten
steps:
- uses: actions/checkout@v3
- uses: actions-rs/toolchain@v1
with:
override: false
default: true
- name: Add target
run: rustup target add ${{ matrix.target }}
- name: Wasm-compat frontends build
uses: actions-rs/cargo@v1
with:
command: build
args: -p frontends --no-default-features --target ${{ matrix.target }} --features "wasm, parallel"
- name: Wasm-compat folding-schemes build
uses: actions-rs/cargo@v1
with:
command: build
args: -p folding-schemes --no-default-features --target ${{ matrix.target }} --features "default,light-test"
- name: Run wasm-compat script
run: |
chmod +x .github/scripts/wasm-target-test-build.sh
.github/scripts/wasm-target-test-build.sh
shell: bash
examples:
if: github.event.pull_request.draft == false
name: Run examples & examples tests
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions-rs/toolchain@v1
- uses: noir-lang/noirup@v0.1.3
with:
toolchain: nightly
- name: Download Circom
run: |
mkdir -p $HOME/bin
curl -sSfL https://github.com/iden3/circom/releases/download/v2.1.6/circom-linux-amd64 -o $HOME/bin/circom
chmod +x $HOME/bin/circom
echo "$HOME/bin" >> $GITHUB_PATH
- name: Download solc
run: |
curl -sSfL https://github.com/ethereum/solidity/releases/download/v0.8.4/solc-static-linux -o /usr/local/bin/solc
chmod +x /usr/local/bin/solc
- name: Execute compile.sh to generate .r1cs and .wasm from .circom
run: ./frontends/src/circom/test_folder/compile.sh
- name: Execute compile.sh to generate .json from noir
run: ./frontends/src/noir/test_folder/compile.sh
- name: Run examples tests
run: cargo test --examples
- name: Run examples
run: cargo run --release --example 2>&1 | grep -E '^ ' | xargs -n1 cargo run --release --example
fmt:
if: github.event.pull_request.draft == false
name: Rustfmt
timeout-minutes: 30
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions-rs/toolchain@v1
- uses: Swatinem/rust-cache@v2
- run: rustup component add rustfmt
- uses: actions-rs/cargo@v1
with:
command: fmt
args: --all --check
clippy:
if: github.event.pull_request.draft == false
name: Clippy lint checks
runs-on: ubuntu-latest
strategy:
matrix:
feature_set: [basic, wasm]
include:
- feature_set: basic
features: --features default,light-test
# We only want to test `frontends` package with `wasm` feature.
- feature_set: wasm
features: -p frontends --features wasm,parallel --target wasm32-unknown-unknown
steps:
- uses: actions/checkout@v2
- uses: actions-rs/toolchain@v1
with:
components: clippy
- uses: Swatinem/rust-cache@v2
- name: Add target
run: rustup target add wasm32-unknown-unknown
- name: Run clippy
uses: actions-rs/cargo@v1
with:
command: clippy
args: --no-default-features ${{ matrix.features }} -- -D warnings
typos:
if: github.event.pull_request.draft == false
name: Spell Check with Typos
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Use typos with config file
uses: crate-ci/typos@master
with:
config: .github/workflows/typos.toml
|