* mark template and utils as non-publish * switch to development version for testing * activate unleash check * maybe if I disable all rules... * Fix isolated compilation of `max-encoded-len-derive` with `syn` error[E0369]: binary operation `==` cannot be applied to type `syn::Path` --> src/lib.rs:88:29 | 88 | .filter(|attr| attr.path == parse_quote!(max_encoded_len_crate)) | --------- ^^ ----------------------------------- _ | | | syn::Path error: aborting due to previous error For more information about this error, try `rustc --explain E0369`. Error: could not compile `max-encoded-len-derive` * WIP: bump changes crates since v3 tag to next breaking cargo unleash version bump-breaking --changed-since v3.0.0 cargo unleash version set-pre dev --changed-since v3.0.0 FIXME: Don't modify crates that are not yet released, e.g. `max-encoded-len-derive` * Update lockfile * WIP: Bump sp-transaction-pool as well * WIP: Bump sp-offchain as well * WIP: Bump frame-system-rpc-runtime-api as well * WIP: Bump sp-authority-discovery as well * Manually deactivate dev-deps before `cargo unleash check` Otherwise we run into `Cycle detected` error. * Bump sp-consensus-slots * Add missing Cargo.lock change * Bump sp-consensus-vrf as well * Bump sp-keyring as well * Bump sp-consensus-pow as well * Try to speed up the `unleash-check` job Previously, the job took 106 minutes - let's see if explicitly specifying a `CARGO_TARGET_DIR` will help * fixup: Ensure the temp target dir exists for unleash check * Bump pallet-transaction-payment-rpc-runtime-api as well Needed for Polkadot * Bump pallet-transaction-payment-rpc as well Needed for Polkadot * Try updating crates after patching in the Polkadot CI job * Use another approach to update patched Substrate crates * Try to update all sp-core versions in Polkadot CI job * Simplify sp-core version checking * Apply another shellcheck lint * Just do the simplest thing I guess * Welp don't do --offline then * Clean up `unleash-check` job triggers Co-authored-by: Denis Pisarev <denis.pisarev@parity.io> * Fix a note in unleash-check cache step * Add a note about temporary optimization in cargo-unleash * Pin a newer version of cargo-unleash Co-authored-by: Igor Matuszewski <xanewok@gmail.com> Co-authored-by: Denis Pisarev <denis.pisarev@parity.io>
Substrate chain configurations.
This crate contains structs and utilities to declare a runtime-specific configuration file (a.k.a chain spec).
Basic chain spec type containing all required parameters is
ChainSpec. It can be extended with
additional options that contain configuration specific to your chain.
Usually the extension is going to be an amalgamate of types exposed
by Substrate core modules. To allow the core modules to retrieve
their configuration from your extension you should use ChainSpecExtension
macro exposed by this crate.
use std::collections::HashMap;
use sc_chain_spec::{GenericChainSpec, ChainSpecExtension};
#[derive(Clone, Debug, serde::Serialize, serde::Deserialize, ChainSpecExtension)]
pub struct MyExtension {
pub known_blocks: HashMap<u64, String>,
}
pub type MyChainSpec<G> = GenericChainSpec<G, MyExtension>;
Some parameters may require different values depending on the
current blockchain height (a.k.a. forks). You can use ChainSpecGroup
macro and provided Forks structure to put
such parameters to your chain spec.
This will allow to override a single parameter starting at specific
block number.
use sc_chain_spec::{Forks, ChainSpecGroup, ChainSpecExtension, GenericChainSpec};
#[derive(Clone, Debug, serde::Serialize, serde::Deserialize, ChainSpecGroup)]
pub struct ClientParams {
max_block_size: usize,
max_extrinsic_size: usize,
}
#[derive(Clone, Debug, serde::Serialize, serde::Deserialize, ChainSpecGroup)]
pub struct PoolParams {
max_transaction_size: usize,
}
#[derive(Clone, Debug, serde::Serialize, serde::Deserialize, ChainSpecGroup, ChainSpecExtension)]
pub struct Extension {
pub client: ClientParams,
pub pool: PoolParams,
}
pub type BlockNumber = u64;
/// A chain spec supporting forkable `ClientParams`.
pub type MyChainSpec1<G> = GenericChainSpec<G, Forks<BlockNumber, ClientParams>>;
/// A chain spec supporting forkable `Extension`.
pub type MyChainSpec2<G> = GenericChainSpec<G, Forks<BlockNumber, Extension>>;
It's also possible to have a set of parameters that is allowed to change
with block numbers (i.e. is forkable), and another set that is not subject to changes.
This is also possible by declaring an extension that contains Forks within it.
use serde::{Serialize, Deserialize};
use sc_chain_spec::{Forks, GenericChainSpec, ChainSpecGroup, ChainSpecExtension};
#[derive(Clone, Debug, Serialize, Deserialize, ChainSpecGroup)]
pub struct ClientParams {
max_block_size: usize,
max_extrinsic_size: usize,
}
#[derive(Clone, Debug, Serialize, Deserialize, ChainSpecGroup)]
pub struct PoolParams {
max_transaction_size: usize,
}
#[derive(Clone, Debug, Serialize, Deserialize, ChainSpecExtension)]
pub struct Extension {
pub client: ClientParams,
#[forks]
pub pool: Forks<u64, PoolParams>,
}
pub type MyChainSpec<G> = GenericChainSpec<G, Extension>;
License: GPL-3.0-or-later WITH Classpath-exception-2.0