1. 07 Mar, 2021 6 commits
    • Georges Racinet's avatar
      Updated version file for release · 5e734cb30bb4
      Georges Racinet authored
      --HG--
      branch : heptapod-0-20
      5e734cb30bb4
    • Georges Racinet's avatar
      Merged heptapod branch into release branch · 330194732bc1
      Georges Racinet authored
      Brings only a #396, a fix for RSpec tests.
      
      --HG--
      branch : heptapod-0-20
      330194732bc1
    • Georges Racinet's avatar
      Merged heptapod-stable into heptapod branch · be814789285b
      Georges Racinet authored
      --HG--
      branch : heptapod
      be814789285b
    • Georges Racinet's avatar
      Fixed syntax error in release script · c0df42322c33
      Georges Racinet authored
      --HG--
      branch : heptapod-stable
      c0df42322c33
    • Georges Racinet's avatar
      Heptapod CI: enabling requests/* RSpec tests · 44d5c0be2a1f
      Georges Racinet authored
      These are just the tests at the top level of the directoy.
      Concludes #396.
      
      The weird thing is that the offending
      `requests/git_http_spec.rb` was already part of the `extended`
      scope. Not sure what in CI did not trigger the SQL query limit.
      We'll also keep a closer look on this one (crucial anyway) as
      part of the default scope.
      
      --HG--
      branch : heptapod-stable
      44d5c0be2a1f
    • Georges Racinet's avatar
      Tests: excluding GitHttpController from SQL query counts · aee5f8f82897
      Georges Racinet authored
      Exceeding the threshold turns into a hard error only in RSpec
      tests context.
      
      More information in [development docs](doc/development/query_count_limits.md)
      
      Closes #396
      
      It turns out that auto-creation of the Git repository takes
      between 110 and 120 SQL requests, and we couldn't spot
      any obvious looping pattern. Also running the test on
      pristine GitLab gave us the same result.
      
      It is not clear how this test is not failing in upstream CI.
      While it makes sense that the case of auto-creation, with the
      two HTTP requests in a single transaction is probably the
      heaviest for the Git HTTP controller, one could argue that
      this is just too many SQL queries. Fixing that seems out of
      scope for Heptapod.
      
      --HG--
      branch : heptapod-stable
      aee5f8f82897
  2. 05 Mar, 2021 3 commits
  3. 04 Mar, 2021 2 commits
  4. 03 Mar, 2021 5 commits
  5. 01 Mar, 2021 8 commits
  6. 27 Feb, 2021 5 commits
  7. 26 Feb, 2021 4 commits
  8. 25 Feb, 2021 7 commits
    • Georges Racinet's avatar
      hg-configexpress: pinning version · a06614accc5d
      Georges Racinet authored
      as often, we're still allowing bugfix releases.
      
      --HG--
      branch : heptapod
      a06614accc5d
    • Georges Racinet's avatar
      Container Registry stats: hooking in root stats refresher service · c2f439f9becf
      Georges Racinet authored
      This service is itself called by a worker that is enqueued
      only if the root (top-level) namespace is marked for refresh.
      Probably to avoid running on millions of dormant personal namespaces,
      to be further investigated.
      
      A nice side effect is that the RSpec tests for
      `StatisticsRefresherService` actually call our
      `ContainerRegistryStatsService`. Of course, without real or fake data,
      this is trivial, but they could actually detect a naming inconsistency
      that we fixed.
      
      --HG--
      branch : heptapod
      c2f439f9becf
    • Georges Racinet's avatar
      Container Registry stats: aggregation in RootStorageStatistics · 06a21328d2d5
      Georges Racinet authored
      Strictly speaking, the total, `storage_size`, was already
      taking containers into account, since ProjectStatistics do.
      
      What we're adding is the separate field, with its GraphQL
      exposition.
      
      --HG--
      branch : heptapod
      06a21328d2d5
    • Georges Racinet's avatar
      Container Registry stats: main service for computation · 5c1173525496
      Georges Racinet authored
      This runs for top-level namespaces, providing a reasonable
      assessment per project, which summed up for top-level
      namespaces represents actual usage, except that there layer
      sharing between top-level groups is ignored.
      
      This is a compromise between practicality, scalability and
      we hope for billing cases that it will be clearer to users
      that the registry billing is the same as if they were alone
      on the instance: no bill smaller than expected, but also no
      bill climbing up for unexpected reasons.
      
      --HG--
      branch : heptapod
      5c1173525496
    • Georges Racinet's avatar
      Container Registry stats: group-level aggregations with API · 7fe0c054dc24
      Georges Racinet authored
      The new field is not yet displayed in the admin page, where
      the others are. One must stay aware that these aggregations
      are from direct projects only: projects from subgroups are
      not taken into account.
      
      --HG--
      branch : heptapod
      7fe0c054dc24
    • Georges Racinet's avatar
      ProjectStatistics: added registry size_share to total storage_size · 9447db3ce555
      Georges Racinet authored
      --HG--
      branch : heptapod
      9447db3ce555
    • Georges Racinet's avatar
      Container Registry stats: column on namespace_root_storage_statistics · e6bf3caea424
      Georges Racinet authored
      Group-level aggregation, as in the ReST API is done by simple
      SQL sums on the fly (not taking subgroup into accounts), so there
      was no column to add.
      
      On the other hand, the `Namespace::RootStorageStatistics` model
      is meant to store periodic execution of stats aggregation
      done by `Namespaces::RootStatisticsWorker`.
      
      These can be queried with the GraphQL API.
      
      --HG--
      branch : heptapod
      e6bf3caea424