Skip to content
Snippets Groups Projects
  1. Apr 30, 2020
  2. Apr 29, 2020
  3. Apr 25, 2020
  4. Apr 26, 2020
  5. Apr 24, 2020
  6. Apr 20, 2020
    • Georges Racinet's avatar
      GitLab hooks: handling connection errors · 53fdbb7ab328
      Georges Racinet authored
      The returned message is very generic, but the exact cause will
      be ovious in the logs. Most immediate case is misconfiguration.
      53fdbb7ab328
    • Georges Racinet's avatar
      Fixed conditional imports through requests in hg "bare" context · 8cca59bd3923
      Georges Racinet authored
      Some libraries have to be excluded from the `demandimport` mechanism,
      because the requests library has conditional imports and checks and them.
      
      There wasn't any problem with these in early tests, all conducted
      in HTTP context: probably gunicorn did an earlier, regular import.
      
      But through SSH, which spawns a `hg` subprocess directly,
      the problem is immediate.
      8cca59bd3923
  7. Apr 19, 2020
  8. Mar 10, 2020
    • Georges Racinet's avatar
      GitLab hooks: post-receive directly through internal REST API · a9f1a24b9679
      Georges Racinet authored
      This implements the `post-receive` hook by a direct HTTP call to the
      internal API endpoint. For this, two new config parameters in the
      `heptapod` section are introduced:
      
      - gitlab-internal-api-secret-file
      - gitlab-internal-api-url
      
      
      We're keeping the previous structure, with a `name`
      that's now almost useless and leads us to the
      complication of the `_hook_methods` dict.
      This keeps compatibility for the caller (also
      part of this package since Heptapod 0.12), allowing
      us to refactor in a separate step.
      a9f1a24b9679
  9. Apr 23, 2020
  10. Feb 17, 2020
  11. Apr 20, 2020
    • Georges Racinet's avatar
      hook check_publish: porting to future hg 5.4 · cac20dfe000d
      Georges Racinet authored
      The structure of the `phases` transaction attribute has changed.
      It's now a list of (key, value) pairs instead of a dict,
      and keys are lazy ranges (`xrange` in Python2) of revision numbers.
      
      The new unit test doesn't prove it really works for a given
      Mercurial version, only a separate run will do that, but it'll
      help developers work on both versions at once if they need to
      change the logic.
      cac20dfe000d
  12. Mar 27, 2020
    • Georges Racinet's avatar
      tests: using a more universal rebase call · d325833962a6
      Georges Racinet authored
      In Mercurial 5.3, `source` and `base` are single valued, hence
      just a string, whereas in current default branch, future 5.4,
      they become lists.
      
      We could fix that by version introspection, but in that case, we're
      rebasing a topic with a single changeset, so that switching to
      the implicit form, or `rev`, which is already expected to be
      a list should work for both versions.
      d325833962a6
  13. Apr 20, 2020
  14. Apr 18, 2020
  15. Apr 05, 2020
  16. Mar 30, 2020
  17. Mar 27, 2020
  18. Apr 05, 2020
    • Georges Racinet's avatar
      pull-force-topic: avoid divergence in overlapping pulls · 359d9bf9e090
      Georges Racinet authored
      As reported in heptapod#226, repeatedly importing the same
      changeset rewrites it several time, which is the very
      definition of content divergence.
      
      With these changes, we avoid re-pulling a changeset that's
      already present, yet obsolete. In the stacked PR use-case,
      the end result is that the second topic is orphan, but that's
      a much more frequent and easier to solve condition.
      
      We actually already had something for a similar case in the
      form of `non_obsolete_revs()`, but at the time the scenario of
      stacked PRs had been thought of only a posteriori, at the
      time of writing the docstring
      for the corresponding `test_already_obsolete()`. We could
      have thinked a bit more here.
      
      In truth `non_obsolete_revs()` is probably useless with our
      solution which is to take obsolete changesets into account in
      the initial assessment of the pull to be made, and that
      reflects with it not filtering anything in our existing tests.
      Since we are on the eve of a major release, we still keep it
      out of caution, only adding a direct test to restore coverage
      359d9bf9e090
  19. Mar 30, 2020
  20. Mar 29, 2020
  21. Mar 27, 2020
Loading