Skip to content
Snippets Groups Projects
  1. May 19, 2020
  2. 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
  3. May 08, 2020
  4. May 06, 2020
  5. May 05, 2020
    • Georges Racinet's avatar
      Typo in docstring · f6622702df2b
      Georges Racinet authored
      f6622702df2b
    • Georges Racinet's avatar
      gitlab-mirror: simplify case of topic change by public changeset · 0b995383421b
      Georges Racinet authored
      For the call to `published_topic_latest_hg_sha` in the case the
      previous changeset is obsoleted by a public changeset, since we now get
      `None` if the successor is not on topic, we can avoid checking
      that condition in advance, to test the `None` return value explicitely
      without creating dead code.
      
      Using a revset for that will be marginally slower.
      0b995383421b
    • Georges Racinet's avatar
      gitlab-mirror: recover if latest changeset of published topic can't be found · fa72d730f498
      Georges Racinet authored
      This condition was an indication of corruption, but refusing the push
      currently does much more harm than cleaning up the condition, even
      if the cleanup risks itself to turn out wrong.
      
      In the case detailed in heptapod#265, we had a Git repository
      inconsistency which we could only reproduce manually by forcing
      the Git branch for the topic: the previously know topic head was
      both public and not on topic.
      
      Getting `None` in the other call to
      `published_topic_latest_hg_sha` can't happen,
      but this will have to be refactored for clarity.
      fa72d730f498
  6. May 03, 2020
    • Georges Racinet's avatar
      hooks: work from a share · d89ffa5e2d7e
      Georges Racinet authored
      We're going to need to send GitLab hooks from the temporary
      working directories (shares) that are used in Rails to perform
      operations. For that, the path to the Git repo must be inferred
      from the share source path.
      d89ffa5e2d7e
  7. Apr 30, 2020
  8. Apr 29, 2020
  9. Apr 23, 2020
  10. Feb 17, 2020
  11. Apr 18, 2020
  12. Apr 05, 2020
  13. Mar 30, 2020
  14. Mar 27, 2020
  15. 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
  16. Mar 30, 2020
  17. Mar 29, 2020
  18. Mar 27, 2020
Loading