Read about our upcoming Code of Conduct on this issue

  1. 27 Nov, 2020 1 commit
  2. 07 Nov, 2020 1 commit
    • Georges Racinet's avatar
      multi-vcs: validate Project vcs_type against Application Settings · e90fbe3ee00f
      Georges Racinet authored
      Now that we have the `vcs_types` Application Settings field,
      we use it to enforce upon Project creation that the selected
      `vcs_type` is among them.
      This validation has to be done by a separate method in order
      to access the `CurrentSettings` object.
      Also, we've considered making the default value for `vcs_type` in
      `CreateService` not to be the library-level default, so that
      explicitely passing a value is never required, even in the case where
      the library default is not allowed by Application Settings, but
      finally decided that failing with an explicit message in that case
      was better than such magic. Note also that the Web UI will always
      pass a value, so this case is in practice for API calls only.
      branch : heptapod
  3. 31 Oct, 2020 1 commit
    • Georges Racinet's avatar
      Project model: validation of vcs_type · 53af134a42a1
      Georges Racinet authored
      This is simply ensuring the value is a support type
      We're testing this twice (model and service) because `project_spec`
      is not yet in the Heptapod CI shortlist and it takes too much time
      that such a trivial test would be worth it. Of course, it has
      its intrinsic value, and we will activate it soonish, but that's not
      the current concern. Also this prepares for potentially more advanced
      behaviour at the service level.
      branch : heptapod
  4. 19 Sep, 2020 1 commit
  5. 20 Aug, 2020 1 commit
  6. 20 Jul, 2020 1 commit
  7. 18 Jun, 2020 1 commit
  8. 09 Jun, 2020 1 commit
    • Georges Racinet's avatar
      Read the Docs integration · 272f83c2db16
      Georges Racinet authored
      Closes #282
      Generic GitLab does not need an Read the Docs integration, since
      Read the Docs has a Gitlab integration, but Heptapod needs one.
      This integration is disabled for Git repositories (not yet available
      in the Web UI, but partly working on Heptapod 0.13).
      Since the URL target should most of the times be under, the TLS verification is enabled by default.
      This will send a POST to readthedocs for each named branch. We may
      want to complement with some filtering later on.
      branch : heptapod-stable
  9. 03 Jun, 2020 1 commit
  10. 20 May, 2020 1 commit
  11. 08 May, 2020 1 commit
    • Georges Racinet's avatar
      Gitlab::Mercurial adopted method for repo creation · d9eac4fb23dd
      Georges Racinet authored
      The main advantage is that this looks more uniform from the
      upper layers, at the price of making
      `Git::Repository.create_repository` accept arbitrary
      Also `Gitlab::Shell` is slowly being faded away. By
      calling the raw repo's `create_repository` we are
      actually anticipating on later versions.
      The saner structure can be also be felt in that we
      don't need to give some methods a classmethod
      version any more.
      branch : heptapod
  12. 24 Apr, 2020 1 commit
  13. 20 Apr, 2020 1 commit
  14. 14 Apr, 2020 1 commit
  15. 10 Apr, 2020 1 commit
  16. 09 Apr, 2020 2 commits
  17. 06 Apr, 2020 3 commits
  18. 02 Apr, 2020 1 commit
  19. 01 Apr, 2020 1 commit
  20. 31 Mar, 2020 1 commit
    • Georges Racinet's avatar
      hashed storage: adapting path to group HGRC · 3c0b374e853d
      Georges Racinet authored
      In the case of the hashed storage, we keep a
      subset of the directory hierarchy for namespaces
      and the repo HGRC includes from that, hence depending
      on the namespace path from the storage root and the
      depth of the hashed storage (currently a constant, at
      two intermediate subdirectories).
      In both the hashed and non-hashed cases, this is provided by
      `relative_path_from`, whose result is just `../../hgrc` in
      the non hashed case.
      The inclusion path is relative to the storage root, hence
      this independent of the storage location, which can
      change (reconfig, change of host by backup & restore)
      with no need to crawl through repositories.
      This partially defeats one of the advantages of the
      hash storage: avoiding too much top level directories.
      This shouldn't be critical for Heptapod because
      1. By the time we have instances that big that this cluttering
         is a problem, assuming we just don't use a FS with hashmap
         directories (XFS for instance), we'll be able to come up
         with other mechanisms
      2. It's about namespaces having either HGRC settings or subgroups.
         These should be the minority. After all, using subgroups
         reduces the number of toplevel groups.
      branch : heptapod
  21. 26 Mar, 2020 1 commit
  22. 25 Mar, 2020 1 commit
  23. 24 Mar, 2020 1 commit
  24. 23 Mar, 2020 3 commits
  25. 18 Mar, 2020 2 commits
  26. 17 Mar, 2020 1 commit
  27. 16 Mar, 2020 1 commit
  28. 13 Mar, 2020 1 commit
  29. 12 Mar, 2020 2 commits
  30. 09 Mar, 2020 1 commit
  31. 05 Mar, 2020 1 commit
  32. 02 Mar, 2020 2 commits