Skip to content
  1. Feb 06, 2024
  2. Feb 02, 2024
  3. Feb 01, 2024
  4. Jan 25, 2024
  5. Jan 24, 2024
  6. 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
  7. Jan 18, 2024
  8. Jan 16, 2024
  9. Jan 12, 2024
  10. Jan 11, 2024
  11. Jan 10, 2024
  12. Jan 09, 2024
  13. Jan 05, 2024
  14. Jan 03, 2024
  15. Dec 21, 2023
  16. Dec 01, 2023
  17. Nov 29, 2023
  18. Nov 22, 2023
  19. Nov 21, 2023
  20. Nov 20, 2023
  21. Nov 16, 2023
  22. 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
  23. Nov 06, 2023