Skip to content
Snippets Groups Projects
  1. Jun 10, 2020
  2. Jun 09, 2020
  3. 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
  4. 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
  5. Jun 08, 2020
  6. Jun 07, 2020
  7. May 28, 2020
  8. May 27, 2020
  9. May 23, 2020
  10. May 22, 2020
  11. May 21, 2020
  12. May 15, 2020
  13. 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
  14. May 17, 2020
  15. May 18, 2020
  16. 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
  17. May 16, 2020
Loading