Skip to content
Snippets Groups Projects
  1. Oct 09, 2024
    • Alexander Samusev's avatar
      [ci] Move test-linux-stable-no-try-runtime to GHA (#5979) · 48b56aa1
      Alexander Samusev authored
      PR moves `test-linux-stable-no-try-runtime` from gitlab to github.
      I disabled two tests because our current runners don't have necessary
      syscalls enabled. Will continue working on it in
      https://github.com/paritytech/ci_cd/issues/1056
      Also PR remove `gh cli` installation since it's installed in the
      `ci-unified` image.
      
      close https://github.com/paritytech/ci_cd/issues/1023
      48b56aa1
    • Andrei Eres's avatar
      Bump PoV request timeout (#5924) · 3ad12919
      Andrei Eres authored
      # Description
      
      We previously set the PoV request timeout to 1.2s based on synchronous
      backing, which allowed for 5 PoVs per relay block. With asynchronous
      backing, we no longer have a time budget and can increase the value to
      2s.
      
      Fixes https://github.com/paritytech/polkadot-sdk/issues/5885
      
      ## Integration
      
      This PR shouldn't affect downstream projects.
      
      ## Review Notes
      
      This PR can be followed by experiments with Gluttons on Kusama to
      confirm that the timeout is sufficient.
      3ad12919
    • Egor_P's avatar
      [Release/CI] Github flow to build `polkadot`/`polkadot-parachain` rc binaries... · c4770762
      Egor_P authored
      [Release/CI] Github flow to build `polkadot`/`polkadot-parachain` rc binaries and deb package (#5963)
      
      This PR introduces a GitHub flow, that should replace a semi manual part
      of the release process to build rc binaries for `polkadot` and
      `polkadot-parachain` + the `polkadot` deb package.
      
      Right now, this part of the release is done on the `cleanroom` machine
      by the release engineers via triggering bash scripts directly on the
      server. These GitHub flows should replace it and move everything to the
      CI.
      
      The whole flow is meant to be run in the new
      [paritytech-release](https://github.com/paritytech-release) where the
      automated release is going to be moved.
      
      The flow includes the following steps:
      - Build `polkadot`, `polakdot-prepare-worker`, `polkadot-execute-worker`
      and `polkadopt-parachain` binaries
      - Sign those artefacts using `gpg` and generate a sha256 checksum
      - Build deb package for `polakdot`
      - Make a GitHub attestation
      - Upload artefacts to the S3 buckets
      
      Closes: https://github.com/paritytech/release-engineering/issues/223
      
      
      
      ---------
      
      Co-authored-by: default avatarOliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
      c4770762
    • Alexander Samusev's avatar
      [ci] Remove short-benchmarks from Gitlab (#5988) · 6765bcd8
      Alexander Samusev authored
      PR removes short-benchmarks from GitLab, adds condition for
      cargo-check-rutimes
      6765bcd8
    • Javier Viola's avatar
      Disable flaky tests reported in 5972/5973/5974 (#5976) · 6c2b46f9
      Javier Viola authored
      Disable flaky tests reported in:
      #5972 
      #5973 
      #5974
      6c2b46f9
  2. Oct 08, 2024
  3. Oct 07, 2024
  4. Oct 06, 2024
  5. Oct 05, 2024
    • Javier Viola's avatar
    • Maksym H's avatar
      update runners for cmd and docs (#5938) · cb8f4665
      Maksym H authored
      Updated runners for CMD and Docs
      cb8f4665
    • Cyrill Leutwiler's avatar
      [pallet-revive] immutable data storage (#5861) · a8ebe9af
      Cyrill Leutwiler authored
      
      This PR introduces the concept of immutable storage data, used for
      [Solidity immutable
      variables](https://docs.soliditylang.org/en/latest/contracts.html#immutable).
      
      This is a minimal implementation. Immutable data is attached to a
      contract; to keep `ContractInfo` fixed in size, we only store the length
      there, and store the immutable data in a dedicated storage map instead.
      Which comes at the cost of requiring an additional storage read (costly)
      for contracts using this feature.
      
      We discussed more optimal solutions not requiring any additional storage
      accesses internally, but they turned out to be non-trivial to implement.
      Another optimization benefiting multiple calls to the same contract in a
      single call stack would be to cache the immutable data in `Stack`.
      However, this potential creates a DOS vulnerability (the attack vector
      is to call into as many contracts in a single stack as possible, where
      they all have maximum immutable data to fill the cache as efficiently as
      possible). So this either has to be guaranteed to be a non-issue by
      limits, or, more likely, to have some logic to bound the cache.
      Eventually, we should think about introducing the concept of warm and
      cold storage reads (akin to EVM). Since immutable variables are commonly
      used in contracts, this change is blocking our initial launch and we
      should only optimize it properly in follow-ups.
      
      This PR also disables the `set_code_hash` API (which isn't usable for
      Solidity contracts without pre-compiles anyways). With immutable storage
      attached to contracts, we now want to run the constructor of the new
      code hash to collect the immutable data during `set_code_hash`. This
      will be implemented in a follow up PR.
      
      ---------
      
      Signed-off-by: default avatarCyrill Leutwiler <bigcyrill@hotmail.com>
      Signed-off-by: default avatarxermicus <cyrill@parity.io>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarAlexander Theißen <alex.theissen@me.com>
      Co-authored-by: default avatarPG Herveou <pgherveou@gmail.com>
      a8ebe9af
    • Branislav Kontur's avatar
      Bridge relayer backwards compatibility for reading storage InboundLaneData/OutboundLaneData (#5921) · 73bf37ab
      Branislav Kontur authored
      For permissionless lanes, we add `lane_state` to the `InboundLaneData`
      and `OutboundLaneData` structs. However, for a period of time (until
      both BHK and BHP are upgraded to the same version), we need the relayer
      to function with runtimes where one has been migrated with `lane_state`
      and the other has not. This PR addresses the incompatibility by
      introducing wrapper structs for decoding without `lane_state`.
      73bf37ab
    • Adrian Catangiu's avatar
      XCM paid execution barrier supports more origin altering instructions (#5917) · d968c941
      Adrian Catangiu authored
      The AllowTopLevelPaidExecutionFrom allows ClearOrigin instructions
      before the expected BuyExecution instruction, it also allows messages
      without any origin altering instructions.
      
      This commit enhances the barrier to also support messages that use
      AliasOrigin, or DescendOrigin. This is sometimes desired in asset
      transfer XCM programs that need to run the inbound assets instructions
      using the origin chain root origin, but then want to drop privileges for
      the rest of the program. Currently these programs drop privileges by
      clearing the origin completely, but that also unnecessarily limits the
      range of actions available to the rest of the program. Using
      DescendOrigin or AliasOrigin allows the sending chain to instruct the
      receiving chain what the deprivileged real origin is.
      
      See https://github.com/polkadot-fellows/RFCs/pull/109 and
      https://github.com/polkadot-fellows/RFCs/pull/122
      
       for more details on
      how DescendOrigin and AliasOrigin could be used instead of ClearOrigin.
      
      ---------
      
      Signed-off-by: default avatarAdrian Catangiu <adrian@parity.io>
      d968c941
    • Iulian Barbu's avatar
      templates: add genesis config presets for minimal/solochain (#5868) · f8807d1e
      Iulian Barbu authored
      # Description
      
      Closes [#5790](https://github.com/paritytech/polkadot-sdk/issues/5790).
      Useful for starting nodes based on minimal/solochain when doing
      development or for testing omni node with less happy code paths. It is
      reusing the presets defined for the nodes chain specs.
      
      ## Integration
      
      Specifically useful for development/testing if generating chain-specs
      for `minimal` or `solochain` runtimes from `templates` directories.
      
      ## Review Notes
      
      Added `genesis_config_presets` modules for both minimal/solochain. I
      reused the presets defined in each node `chain_spec` module
      correspondingly.
      
      ### PRDOC
      
      Not sure who uses templates, maybe node devs and runtime devs at start
      of their learning journey, but happy to get some guidance on how to
      write the prdoc if needed.
      
      ### Thinking out loud
      
      I saw concerns around sharing functionality for such genesis config
      presets between the template chains. I think there might be a case for
      doing that, on the lines of this comment:
      https://github.com/paritytech/polkadot-sdk/pull/4739#issuecomment-2157341035.
      I would add that `parachains-common::genesis_config_heleper` contains a
      few methods from those mentioned, but I am unsure if using it as a
      dependency for templates is correct. Feels like the comment suggests
      there should be a `commons` crate concerning just `templates`, which I
      agree with to some degree, if we assume `cumulus` needs might be driven
      in certain directions that are not relevant to `templates` and vice
      versa. However I am not so certain about this, so would welcome some
      thoughts, since I am seeing `parachains-common` being used already in a
      few runtime implementations:
      https://crates.io/crates/parachains-common/reverse_dependencies?page=3
      
      ,
      so might be a good candidate already for the `common` logic.
      
      ---------
      
      Signed-off-by: default avatarIulian Barbu <iulian.barbu@parity.io>
      f8807d1e
  6. Oct 04, 2024
Loading