Benjamin Kampmann
c78c2892a4
* 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>
Executive Module
The Executive module acts as the orchestration layer for the runtime. It dispatches incoming extrinsic calls to the respective modules in the runtime.
Overview
The executive module is not a typical pallet providing functionality around a specific feature. It is a cross-cutting framework component for the FRAME. It works in conjunction with the FRAME System module to perform these cross-cutting functions.
The Executive module provides functions to:
- Check transaction validity.
- Initialize a block.
- Apply extrinsics.
- Execute a block.
- Finalize a block.
- Start an off-chain worker.
Implementations
The Executive module provides the following implementations:
Executive: Type that can be used to make the FRAME available from the runtime.
Usage
The default Substrate node template declares the Executive type in its library.
Example
Executive type declaration from the node template.
#
/// Executive: handles dispatch to the various modules.
pub type Executive = executive::Executive<Runtime, Block, Context, Runtime, AllPallets>;
Custom OnRuntimeUpgrade logic
You can add custom logic that should be called in your runtime on a runtime upgrade. This is done by setting an optional generic parameter. The custom logic will be called before the on runtime upgrade logic of all modules is called.
#
struct CustomOnRuntimeUpgrade;
impl frame_support::traits::OnRuntimeUpgrade for CustomOnRuntimeUpgrade {
fn on_runtime_upgrade() -> frame_support::weights::Weight {
// Do whatever you want.
0
}
}
pub type Executive = executive::Executive<Runtime, Block, Context, Runtime, AllPallets, CustomOnRuntimeUpgrade>;
License: Apache-2.0