Skip to content
Snippets Groups Projects
  1. May 23, 2020
  2. May 22, 2020
  3. May 21, 2020
  4. May 15, 2020
  5. May 18, 2020
    • Georges Racinet's avatar
      heptapod-ci: avoid reinstallation of Mercurial · 674b7740d22f
      Georges Racinet authored
      Because Mercurial is loaded through PYTHONPATH, it's not visible
      to pip (even if we'd set PYTHONPATH for the pip command), therefore
      that triggers download/build/install of an unrelated Mercurial
      version.
      674b7740d22f
  6. May 17, 2020
  7. May 18, 2020
  8. May 17, 2020
    • Georges Racinet's avatar
      py3-hgext3rd.heptapod: ported hg-git code · 3f2d996addc5
      Georges Racinet authored
      While we have plans to remove the auxiliary Git mirror repository
      used to expose content to the web app as soon as in Heptapod 0.14,
      we know that this won't be possible before a longer time for
      the repositories backing the wikis. Also this allows us to test
      with python3 earlier, and it's not completely excluded that 0.14 could
      support both Python 2 and Python 3.
      
      As a side note, the difference in representation of bytes string
      between the two Python versions force us to resort to assertions with
      poor style in doctests. We'll live with that.
      3f2d996addc5
  9. May 16, 2020
  10. May 20, 2020
    • Georges Racinet's avatar
      c1bbd8cb85a4
    • Georges Racinet's avatar
      py3: ported the WSGI wrapper · bbfcd3668ac0
      Georges Racinet authored
      This forced us to clean up the situation with HTTP error responses.
      
      - the status line now conforms to the common practice (no user level
        message)
      - the body (error details) is normalized to UTF-8. This gives us simpler
        code paths and the odds of outputting garbage are very low (complete assessment
        in the comment, keep in mind that we'll be supporting python2 for
        one or two months at most in Heptapod).
      bbfcd3668ac0
    • Georges Racinet's avatar
      py3: port of heptapod.hooks package · 17823c0c3207
      Georges Racinet authored
      In the case of `gitlab-mirror`, at this point the underlying command
      from `hgext3rd.heptapod` is not ported.
      17823c0c3207
  11. May 17, 2020
  12. May 16, 2020
    • Georges Racinet's avatar
      py3: making heptapod.gitlab compatible · 174c7508ba75
      Georges Racinet authored
      GitLab filesystem paths are enforced to be ASCII, see
      `app/validators/project_path_validator.rb` and
      `lib/gitlab/path_regex.rb`.
      
      The paradigm here is that output sent back to the caller
      will have to be as bytes, since we'll be in Mercurial code.
      
      The `format_` functions all take unicode strings as input,
      so that alignments are less wrong than with bytes.
      
      Mostly all of this is ASCII anyway at this point, but it doesn't
      harm to be somewhat ready for i18n in push messages.
      
      Overall, we prefer to have occasional `?` replacement marks
      rather than failed pushes (these can be business critical for
      our users).
      174c7508ba75
  13. May 20, 2020
    • Georges Racinet's avatar
      py3: port of testhelpers · c97c523cd00d
      Georges Racinet authored
      The conventions about incoming strings had to be made explicit,
      which led us to initiate a proper docstring for `LocalRepoWrapper`.
      
      Of course that doesn't mean that the convention is perfectly
      respected, but it can be considered a specification. We already
      have at least one case that needs conversions, to be handled when
      the need arises.
      c97c523cd00d
    • Georges Racinet's avatar
      py3: making heptapod extension installable · 9d1e1acae65b
      Georges Racinet authored
      This is the minimum so that Mercurial accepts to load it.
      In turn the heptapod extension is used as an example of how
      to load an extension in tests in `test_testhelpers`, so
      this intermediate change is needed to port testhelpers to
      Python3.
      
      Of course we should use another extension, perhaps one
      shipping with Mercurial so that testhelpers don't depend
      onto hgext3rd.heptapod any more, but that will be another
      day.
      9d1e1acae65b
  14. May 17, 2020
  15. May 18, 2020
  16. May 16, 2020
  17. May 19, 2020
  18. May 18, 2020
    • Georges Racinet's avatar
      Sending GitLab notifications for tags · 80e5c47712bd
      Georges Racinet authored
      Before this, neither pre-receive nor post-receive notifications
      were sent. The former would be a major security concern for
      upstream GitLab, much less for us, since most of the permission
      checking is actually done by Mercurial.
      
      The latter explains why there aren't pipelines running for tags
      and why it takes a while for the tags to be visible in the
      "Run pipeline" page.
      
      Closes heptadod#260
      
      What happened here is that the tags were correctly exported
      and this was tested, but it happened before `update_references()`,
      which is in particular the method that's responsible for sending
      notifications.
      
      Once the tags were written in the Git repo, of course
      'update_references()` wouldn't see them. But it's worse than that:
      `get_exportable()` only inspects heads (all these methods are
      really ill-named in hg-git).
      
      We considered not duplicating `export_hg_tags()` and comparing the
      tags before and after, but it has the major drawback for us to
      write immediately to the Git repo, whereas we want to send the
      `pre-receive` notification to GitLab before writing.
      
      Besides, `export_hg_tags()` wasn't so complicated, and our testing
      is more thorough than in upstream hg-git.
      80e5c47712bd
    • Georges Racinet's avatar
      Override GitHandler.export_commits() from hg-git · 74a2f8127f5d
      Georges Racinet authored
      This is a pristine copy as of hg-git 0.9.0a1
      74a2f8127f5d
  19. May 14, 2020
  20. Apr 26, 2020
    • Georges Racinet's avatar
      Wiki: made `master` Git branch always identical to `branch/default` · f425f770945e
      Georges Racinet authored
      GitLab wikis only read from `master`, and that's
      pretty hardcoded, down the way to Gitaly, which itself embeds the
      Gollum library, instead of just providing raw repo content.
      
      Since we don't want to fork Gitaly, as long as we are using a Git mirror,
      it's simpler to tie the `master` and `branch/default` Git branches
      together in the case of wikis.
      f425f770945e
Loading