1. 11 Nov, 2021 1 commit
    • Georges Racinet's avatar
      Read The Docs integration: fixing class reference in Project · 75ca31a5edb0
      Georges Racinet authored
      The case of the class name was wrong.
      
      This was found by the (not present yet in GitLab 14.2.6) Integrations
      API RSpec tests on GitLab 14.4, affecting apparently only the DELETE
      call. Impact in Heptapod 0.25 is not clear, but the fact remains that
      the case was wrong.
      
      --HG--
      branch : heptapod-oldstable
      75ca31a5edb0
  2. 19 Aug, 2021 1 commit
  3. 02 Aug, 2021 1 commit
  4. 20 Jul, 2021 2 commits
  5. 17 Jun, 2021 1 commit
  6. 16 Jun, 2021 1 commit
  7. 19 May, 2021 1 commit
  8. 20 Apr, 2021 1 commit
  9. 18 May, 2021 1 commit
    • Georges Racinet's avatar
      Project model: avoid all LFS code paths for Mercurial · 983c999f447d
      Georges Racinet authored
      It's for now just a source of breakage, even though in HGitaly
      we made it so that trivial responses are returned.
      
      Of course things will have to be very different the day we
      actually integrate Mercurial LFS.
      
      --HG--
      branch : heptapod
      983c999f447d
  10. 30 Mar, 2021 1 commit
  11. 02 Apr, 2021 1 commit
    • Georges Racinet's avatar
      Fully native mode: feature flags and `Project#hgitaly1?` · 25538af903cb
      Georges Racinet authored
      Following the examples from
      https://docs.gitlab.com/ce/development/feature_flags/index.html,
      we are introducing two feature flags:
      
      - `hg_fully_native` will be used to switch the whole instance
        to the fully native mode to be developped (HGitaly2 milestone).
      - `hgitaly1_fallback` will be used to get back for a specific project
        to the partial native mode of HGitaly1
      
      The evaluation is done relative to the whole instance or the project.
      Setting these feature flags for a group does nothing. This should
      be good enough for our progressive testing strategy. The documentation
      also warns against using several actors for one feature flag, hence
      we would need a third one to introduce group-level control.
      
      The convenience method `hgitaly1?` on the Project model provides
      a uniform way to know if the project is a Mercurial native one, running
      in HGitaly1 mode. To that end, it combines the `vcs_type` field and
      the feature flag, so that the result is meaningful for all kinds of
      projects.
      
      Because the code controlled by the feature flags will typically
      be one of the  `GitalyClient` classes, it won't have direct access
      to the relevant project. Hence we are also providing the `hgitaly1?`
      method, on the three raw repository classes, that should in practice
      be the one to use from most code, notably classes within the
      `GitalyClient` module.
      
      Finally, we introduce new RSpec example files for the Project and
      Repository models in the Mercurial cases. That will help minimize
      useless conflicts when merging upstream GitLab. Because we don't
      have much specifics, it didn't seem useful to make separate files
      for the Repository model: we're testing the Repository (its
      `raw_repository` factory method notably), together with
      `Project#hgitaly1?`.
      
      --HG--
      branch : heptapod
      25538af903cb
  12. 16 Mar, 2021 1 commit
  13. 12 Mar, 2021 1 commit
  14. 18 Feb, 2021 1 commit
  15. 20 Jan, 2021 1 commit
  16. 19 Jan, 2021 2 commits
    • Georges Racinet's avatar
      Services (Project integrations): exclusion system based on VCS type · 373bc9a4ff41
      Georges Racinet authored
      In particular, we're fixing the RSpec tests for the services
      API: they were failing because the `readthedocs` service is
      disable for the (Git) project provided by the fixture.
      
      Part of #397
      
      --HG--
      branch : heptapod
      373bc9a4ff41
    • Georges Racinet's avatar
      Projects: moved personal namespace limit to model · 21b6da130e4d
      Georges Racinet authored
      Heptapod has specific logic so that it is more obvious to
      users that can't create projects in their personal namespace
      that they may still do it in a Group.
      
      But at least in current GitLab, such checks are done at lower
      level than the service, namely in the model. So we need to
      use our specific check (calling specific method) there.
      
      This was spotted by the test in `spec/requests/api/projects.rb`
      because our `deny_namespace!` ended up in the API in a 400 error
      (message: "invalid namespace") instead of the expeted 403 with
      explicit message about the limit
      
      --HG--
      branch : heptapod
      21b6da130e4d
  17. 16 Jan, 2021 1 commit
    • Georges Racinet's avatar
      Projects model: fixed default_branch_or_master · 07fed0fa3a1a
      Georges Racinet authored
      For empty Git projects, it was returning the value meant for
      empty Mercurial projects.
      
      Strictly speaking, that was for projects without a known
      default branch. These are empty projects in practice.
      
      --HG--
      branch : heptapod
      07fed0fa3a1a
  18. 17 Dec, 2020 1 commit
  19. 14 Dec, 2020 1 commit
  20. 26 Nov, 2020 1 commit
  21. 19 Nov, 2020 1 commit
  22. 27 Nov, 2020 3 commits
  23. 21 Oct, 2020 1 commit
  24. 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.
      
      --HG--
      branch : heptapod
      e90fbe3ee00f
  25. 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.
      
      --HG--
      branch : heptapod
      53af134a42a1
  26. 19 Sep, 2020 1 commit
  27. 20 Aug, 2020 1 commit
  28. 20 Jul, 2020 1 commit
  29. 18 Jun, 2020 1 commit
  30. 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
      https://readthedocs.io, 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.
      
      --HG--
      branch : heptapod-stable
      272f83c2db16
  31. 03 Jun, 2020 1 commit
  32. 20 May, 2020 1 commit
  33. 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
      arguments.
      
      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.
      
      --HG--
      branch : heptapod
      d9eac4fb23dd
  34. 24 Apr, 2020 1 commit
  35. 20 Apr, 2020 1 commit
  36. 14 Apr, 2020 1 commit