Skip to content
Snippets Groups Projects
  1. Jun 09, 2020
    • Georges Racinet's avatar
      Send GitLab notifications even if there are just prune reasons · f8fd032408c7
      Georges Racinet authored
      In some future, perhaps without hg-git, we may want not to
      represent prunings also in changes. If that happens, we'll still
      want GitLab to learn about them.
      f8fd032408c7
    • Georges Racinet's avatar
      Topic vanished: return HeadPruneReason from the analysis · 617f56354d43
      Georges Racinet authored
      This was left as TODO in the introduction of HeadPruneReasons:
      the analysis method is the one that has all information to
      distinguish cases. Before we sent precise prune reasons to GitLab
      we had no other choice than setting the new Git SHA, which was
      obviously artificial for a vanished topic.
      
      We still have some cases where we won't tell GitLab anything, though.
      617f56354d43
  2. Jun 08, 2020
    • Georges Racinet's avatar
      GitLab hooks: sending hg_prune payload · 11949a1466bc
      Georges Racinet authored
      We need to serialize the hg_prune field itself as JSON, since the
      GitLab internal API would accept only plain string as values on the
      other side (or we'd have to go to great length with the `Hash` param
      type to produce the flexibility we need).
      
      GitLab branch names are received as bytes and output as base64 in the
      resulting payload, leaving the burden to guess the encoding to the Rails
      application. This is less cowardly as it sounds: on the Rails side, there's
      already a layer of decoding and encoding guesswork for the `changes`
      parameter (identical to a Git post-receive stdin payload). Hence, we'll
      be able to use the same system for consistent results.
      11949a1466bc
  3. Jun 07, 2020
    • Georges Racinet's avatar
      GitLab hooks: reduced duplication · 561605221ea1
      Georges Racinet authored
      The request firing and first error treatments are
      now done in the base Hook class, thanks to the new
      'api_endpoint` class attribute.
      561605221ea1
    • Georges Racinet's avatar
      Git: extracting prune reasons and passing them to gitlab.hooks · 85141e35eca6
      Georges Racinet authored
      Part of heptapod#269
      
      The prune reasons are given as a dict mapping GitLab branch names to
      `HeadPruneReason` instances.
      
      At this point the `gitlab.hooks.PostReceive` class will just
      ignore the prune reasons, the next move will be to send them
      alongside the usual changes (now called `git_changes`) to the
      new API endpoint.
      
      This is almost compatible with the previous operation, except
      that merge request detection wouldn't work for topics, since
      we're pruning them right away and we don't have the new GitLab
      logic yet.
      
      No details are provided for closed branches, but we have the
      infrastructure to do so.
      85141e35eca6
    • Georges Racinet's avatar
      GitLab hooks: reorganized in subclasses · 0aeb0de073dc
      Georges Racinet authored
      The design dated back to the time when the Hook class was
      merely a wrapper to call external executables provided by
      GitLab, whose file name was actually `self.name`.
      
      It's much clearer to specialize them in the `PreReceive` and
      `PostReceive` classes.
      
      On the `hgext3rd.heptapod.git` side, we had the `_gl_repos`
      attribute to avoid multiple instantiations (dating back from
      the triple inner push era) and everything was also string oriented.
      It's much simpler and no less efficient to instantiate the
      proper hooks in `heptapod_apply_changes`.
      0aeb0de073dc
    • Georges Racinet's avatar
      Representation for reasons a GitLab branch can be pruned · 132b19233a88
      Georges Racinet authored
      The idea is that we are going to develop a "post-receive" hook
      to pass additional Mercurial information to GitLab. This new
      hook and its supporting data classes should survive the move to
      native Mercurial, hence `heptapod.gitlab` should be the right
      place to put them.
      
      It would be tempting to use `attrs` for these simple data
      classes, and maybe we will. For now, let's just not add
      dependencies.
      132b19233a88
  4. Jun 08, 2020
  5. Jun 07, 2020
  6. May 28, 2020
  7. May 27, 2020
  8. May 23, 2020
  9. May 22, 2020
  10. May 21, 2020
  11. May 15, 2020
  12. 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
  13. May 17, 2020
  14. May 18, 2020
  15. 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
  16. May 16, 2020
  17. 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
  18. May 17, 2020
  19. 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
  20. 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
Loading