Read about our upcoming Code of Conduct on this issue

This instance will be upgraded to Heptapod 0.28.1 on 2022-01-26 at 16:00 UTC+1 (a few minutes of down time)

  1. 13 Dec, 2020 5 commits
  2. 06 Dec, 2020 2 commits
  3. 05 Dec, 2020 4 commits
    • Georges Racinet's avatar
      knapsack: allow report generation if not on CI · f724d7805e7b
      Georges Racinet authored
      First experiences for parallelization of RSpec tests will
      be done on personal workstations. The KNAPSACK_GENERATE_REPORT
      variable should be enough to gate it.
      
      --HG--
      branch : heptapod-stable
      f724d7805e7b
    • Georges Racinet's avatar
      RSpec hg_access_protected_branches: removed lengthy setup · 611aad7f35ed
      Georges Racinet authored
      It turns out that these tests don't need the branches to actually
      exist. This gets the time to run this RSpec file down from 10
      minutes to less than 4 on my development workstation.
      
      That is enough to make sharding meaningful.
      
      Of course that raises the question whether they test anything,
      since some expected Forbidden could actually now be raised for
      the wrong reason. There is the case of the
      `safe_commit_for_new_protected_branch?` where one checks that
      protected branch rules are applied even if the commit actually
      creates the protected branch (through wildcard protection,
      that is indeed possible), but this is not currently covered,
      although it should.
      
      In other words actual coverage is no worse, and we should add
      new tests for the cases that aren't strongly covered,
      (perhaps UPSTREAM).
      
      The empty repo is a special case, but the general factory fixture
      takes care of that.
      
      --HG--
      branch : heptapod-stable
      611aad7f35ed
    • Georges Racinet's avatar
      RSpec tests for hg_access: using an empty repo for main tests · fc0da2f09a87
      Georges Racinet authored
      Thanks to this, the running time goes down from about 3mn to
      1mn and 50s on my system.
      
      The LFS tests are probably irrelevant: the day we activate Mercurial's
      version of LFS, we will certainly have to perform other types of checks.
      But then, they will perhaps serve as reminders that there is
      something to adapt.
      
      --HG--
      branch : heptapod-stable
      fc0da2f09a87
    • Georges Racinet's avatar
      RSpec tests for hg_access: split in two · 84b0544435e7
      Georges Racinet authored
      The tests involving protected branches are likely to have different
      setup needs that the other. The bad news is that it's unbalanced:
      tests for protected branches take 10mn on my system, the others
      `hg_access_main_spec.rb` amount for just 3mn.
      
      --HG--
      branch : heptapod-stable
      84b0544435e7
  4. 07 Dec, 2020 1 commit
    • Georges Racinet's avatar
      Heptapod CI: match HGitaly build/spawn with Gitaly · 56a1a392e87d
      Georges Racinet authored
      This creates and preserves the `tmp/tests/hgitaly` subdir
      and separates for CI the install (build) and startup (spawn)
      phases.
      
      By putting `hgitaly.socket` in that preserved directory,
      it also fixes test runs on developer machines involving
      several spec files (previously, the socket was destroyed
      at the end of each spec file)
      
      This is heavier than strictly needed for HGitaly, but
      matching what is already done for Gitaly will help us
      schedule differently (prepare phase, straight download), and
      prebuilding just Gitaly, but with `TestEnv` that actually starts
      HGitaly is an unmaintanable mess.
      
      --HG--
      branch : heptapod-stable
      56a1a392e87d
  5. 02 Dec, 2020 1 commit
    • Georges Racinet's avatar
      pipeline-emails: resist recipients being nil, RSpec tests and CI · f95f97278d0e
      Georges Racinet authored
      In practice, the feature will work for the "Pipeline Emails"
      integration, because these are triggered separately from
      regular pipeline emails, with exactly the list as given in
      the integration config.
      
      Turns out that in all RSpec tests/examples about pipeline
      emails, the list of recipients was actually `nil`, because
      that is the email of the testing user. The case hence
      seems articial, but let's not break because of that.
      
      In the new test we don't use the `deliver_to` from `EmailSpec`
      because it apparently actually reconstructs the envelop-to
      from To and Bcc values.
      
      Finally, the test in spec/models was explicitely looking
      for recipients in the Bcc field, it had to be adapted after
      CI complained.
      
      --HG--
      branch : heptapod
      f95f97278d0e
  6. 22 Nov, 2020 1 commit
  7. 20 Nov, 2020 1 commit
  8. 16 Nov, 2020 1 commit
    • Georges Racinet's avatar
      Branch acces checks: direct identification of legit merges · 948dac54b949
      Georges Racinet authored
      Closes #368
      
      To let merges done from the Rails application be checked
      against the distinct set of merge rules rather that push
      rules, GitLab looks for MRs matching the pre-receive changes by
      comparing with the merge commit sha that's always available
      (and set by the Repository Model) before the actual branch move.
      
      Because the Mercurial change can be atomic, we have no other
      option than passing a special parameter down from
      `Repository#merge` through the Mercurial backend, with the
      `HEPTAPOD_ACCEPT_MERGE_ID` environment variable.
      In turn the Mercurial process will add it to its pre-receive
      hook payload, and the target branch can be compared to switch
      from (direct) push to (Rails) merge mode.
      
      In the case of merges intended from the very beginning to be
      fast forwards, the commit sha is already known in advance,
      but we're using the same mechanism for consistency in the
      check.
      
      Finally, there was a good dose of wrestling with those RSpec
      examples that care about merging to a protected branch, because
      of the on-demand nature of instantiation.
      
      --HG--
      branch : heptapod-stable
      948dac54b949
  9. 15 Nov, 2020 1 commit
    • Georges Racinet's avatar
      Restore branch protection for Mercurial · b9859c4b49e1
      Georges Racinet authored
      The fix is simple enough and all functional tests are passing.
      This is the occasion to restore/adapt the RSpec tests for
      branch protections.
      
      This still have the unwanted consequence that some MR merges
      will fail, because the related permission checks (occurring
      in pre-receive API endpoint) won't find the matching MR.
      
      This will be handled in a subsequent changeset, for more
      on this, see #368.
      
      --HG--
      branch : heptapod-stable
      b9859c4b49e1
  10. 13 Nov, 2020 1 commit
  11. 03 Nov, 2020 1 commit
  12. 30 Oct, 2020 3 commits
  13. 22 Oct, 2020 1 commit
  14. 21 Oct, 2020 1 commit
  15. 14 Oct, 2020 1 commit
  16. 13 Oct, 2020 1 commit
  17. 25 Nov, 2020 2 commits
  18. 19 Nov, 2020 2 commits
  19. 09 Nov, 2020 2 commits
  20. 08 Nov, 2020 3 commits
    • Georges Racinet's avatar
      HGitalyRepository: Git-based list_last_commit_for_tree · e77cd6a5f21f
      Georges Racinet authored
      Arguably, this method has nothing to do with Trees – it
      uses paths, not actual Git Tree objects and could therefore
      be implemented directly in HGitaly.
      
      To be frank, if we had come to that conclusion earlier we
      probably would have made it that way, but now that this code
      is there, we can as well turn to other pressing matters.
      
      A consequence is the `hpd_back_convert!` method, but it could
      turn out to be useful for something else. Of course, like its
      cousins in the `Tree` and `Blob` class, we'd prefer not to
      need it at all.
      
      --HG--
      branch : heptapod
      e77cd6a5f21f
    • Georges Racinet's avatar
      Tree: transitional implementation for Mercurial native repo · e77d525616cd
      Georges Racinet authored
      Similar to what's been done previously for Blob, we switch back
      to Git mode and the point is the the Tree OID is the Git one,
      while the corresponding Commit ID is the Mercurial one.
      
      --HG--
      branch : heptapod
      e77d525616cd
    • Georges Racinet's avatar
      Blob: transitional implementation for native Mercurial repos · 6db10a1faece
      Georges Racinet authored
      Git blobs are typically addressed by their OID, meaning that
      we only have to address the few methods that allow to find that
      OID from a Commit and a relative path.
      
      For example, `Gitlab::Workhorse` returns a special payload including
      the blob OID to the Workhorse server in front of the Rails app,
      allowing it to serve the full blob content directly from Gitaly.
      
      We are systematically calling `gitsha_from_sha` and its converse
      here, hoping it won't be too much of an overhead.
      
      The changes to the `Blob` method are tested through methods of
      `Repository` (inherited by `HgitalyRepository`) that in turn call
      them. Comparison with the case of `HgGitRepository` is provided
      for reference.
      
      --HG--
      branch : heptapod
      6db10a1faece
  21. 07 Nov, 2020 4 commits
    • Georges Racinet's avatar
      multi-vcs: restrict Project creation Web UI according to app setting · 1c314c133569
      Georges Racinet authored
      In the helper, we're now making the distinction between all
      possible values and those that are enabled in the application settings.
      
      In the default value, we're in particular treating the corner case
      where the library-level default is not allowed by Application Settings.
      It is not expected with the current possible values to happen often,
      but one may even imagine people restricting to Git as part as a
      transition plan from upstream GitLab CE to Heptapod.
      
      We don't want to do the same for the API, because the default
      is quite arbitrary in that case, and it's not guaranteed a
      human being would be witnessing its value.
      
      --HG--
      branch : heptapod
      1c314c133569
    • 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
    • Georges Racinet's avatar
      multi-vcs: application settings panel to set VCS types on new projects · dfa98ee0aa7a
      Georges Racinet authored
      This allows to fill in the new `vcs_types` field.
      
      --HG--
      branch : heptapod
      dfa98ee0aa7a
    • Georges Racinet's avatar
      Abiding to some Rubocop rules · 601956cea856
      Georges Racinet authored
      I'm especially not happy with the trailing comma rule in
      Hashes, but doing it anyway.
      
      --HG--
      branch : heptapod
      601956cea856
  22. 08 Nov, 2020 1 commit