Skip to content
  1. Jan 24, 2024
  3. Jan 23, 2024
    • Dominique's avatar
      feat: add decoded XCM data in `blocks` endpoint (#1364) · 555817c8
      Dominique authored 
      

* feat: add decoded xcm data in blocks endpoint

* add types to fix any lint errors

* update copyright year

* fix paraId filter for horizontal msgs

* fix xcm decoding for moonbeam horizontal msg

* add yarn.lock file

* update docs

* removed moonbeam package

* adding back yarn.lock

* changed variable to const

* retrieved yarn.lock from master branch

* added a test for decoding upward msg in polkadot block

* added test for decoding horizontal msg in KAH block

* updated cacheKey with query params of decodedXcmMsgs and paraId
- updated docs in blocks controller comments

* replaced mocked data of block 18207445 with those of block 18468942
- in block 18468942 we have 2 upward msgs from two different parachains so with the same mocked data we can add 2 tests
- added a test to check the query param paraId is working as expected

* replaced mocked data of block 5831776 with those of block 3356195
- in block 3356195 we have downward and horizontal msgs so with the same mocked data we can test two different directions

* changed structure of decodedXcmMsgs response
- changed structure of the decodedMsgs response so that it always returns three arrays (filled or empty), one for each direction.
- removed an if statement as unnecessary in XCMDecoder
- updated corresponding tests with the new structure of the response

* reintroduced the if statement so that paraId query param works when connected to parachain

* added test to check if query param paraId works correctly also in horizontal msgs

* run linter

* added the decodedXcmMsgs response for blockId endpoint
- the response is a combination of Block and BlockXCM response with the use of allOf
- added schema for Liquidity Pool because the swagger was complaining
- changed the order of a hash field so that it aligns of it actually appears in the corresponding response

* added decodedXcmMsgsArg and paraId in the options arg

* added validation for paraId query param
- changed type of paraId after validation
- renamed boolean option for decodedXcmMsgs so it is shorter

* XCMDecoder changes from Tarik's Amazing review
- changes in imports
- replaced class name with the keyword 'this'
- replaced static with readonly for class properties
- replaced static with private for class methods
- changed specname to lowercase

* reused mockApi's 'perClass' in the other mocked apis
- added the 'type' keyword in more imports

* run linter & refix imports

* Update src/services/blocks/BlocksService.ts

Co-authored-by: default avatarTarik Gul <[email protected]>

* fix on the perClass field

---------

Co-authored-by: default avatarmarshacb <[email protected]>
Co-authored-by: default avatarTarik Gul <[email protected]>
      555817c8
  5. Jan 18, 2024
  7. Jan 16, 2024
  9. Jan 12, 2024
  11. Jan 11, 2024
  13. Jan 10, 2024
  15. Jan 09, 2024
  17. Jan 05, 2024
  19. Jan 03, 2024
  21. Dec 21, 2023
  23. Dec 01, 2023
  25. Nov 29, 2023
  27. Nov 22, 2023
  29. Nov 21, 2023
  31. Nov 20, 2023
  33. Nov 16, 2023
  35. Nov 08, 2023
    • Yuri Volkov's avatar
      ci: fixing gitspiegel trigger workflow · bdb92715
      Yuri Volkov authored 
      The first attept to use a workflow to protect GitLab CI from untrusted contributors failed, because GitHub doesn't pass secrets to workflows for PRs that originate from forks. 
 
This uses a different approach: instead of triggerring gitspiegel API directly from the workflow, we're just spawning an empty workflow with a specific path, and gitspiegel listens for `workflow_run` event to start mirroring.  

The idea is the same: for the first-time contributors, running workflows would require manual aciton and that would block mirroring. But this time, we don't need any secrets to make it work.
      bdb92715
  37. Nov 06, 2023
  39. Nov 02, 2023
  41. Nov 01, 2023
  43. Oct 31, 2023
  45. Oct 30, 2023
  47. Oct 27, 2023
  49. Oct 24, 2023
  51. Oct 23, 2023