Read about our upcoming Code of Conduct on this issue

  1. 13 Nov, 2021 1 commit
    • Georges Racinet's avatar
      GitLab hooks: removed annoying and misleading failure message · 0db46e66b9fd
      Georges Racinet authored
      The original wording was appropriate when the pre-receive call was
      done actually after the transaction. It was then useful to warn the
      user of a possible decrepancy. But an error in pre-receive has long
      since become a trigger for transaction abort.
      
      On the other hand, the original message was still appropriate for
      the post-receive call, expanding it a bit to include "actions" not
      triggered.
      0db46e66b9fd
  2. 10 Nov, 2021 1 commit
  3. 03 Nov, 2021 4 commits
  4. 25 Oct, 2021 1 commit
    • Georges Racinet's avatar
      Closed branches: don't break if no new changeset in transaction · cf9852a71d45
      Georges Racinet authored
      The `%d` in the revset used to analyse new changesets produces
      a hard error if the revno does not exist, instead of an empty
      result.
      
      We could later on try and introduce a logic similar to MR detection,
      but the topic is not always visible to GitLab anyway, for instance
      if the closing changeset is the only one, so that would require
      more changes.
      
      Meanwhile, we have a solution for one of the cases of heptapod#452
      cf9852a71d45
  5. 03 Nov, 2021 1 commit
    • Georges Racinet's avatar
      Error handling: ensure tracebacks are produced in GitLab mirror hook · db8189107a65
      Georges Racinet authored
      (adapted graft of 4728e33a7d5c)
      
      Here we consider straight Abort errors to be user errors, hence not
      warranting a server-side traceback in the logs. On the other hand, all
      other uncatched errors will be logged at error level.
      
      This makes use of `hg-loggingmod` 0.3.0 ability to log tracebacks in
      the logs.
      
      This can certainly be improved further, as it doesn't prevent
      server-side tracebacks to be displayed to SSH clients, for instance.
      db8189107a65
  6. 13 Oct, 2021 1 commit
  7. 03 Aug, 2021 1 commit
  8. 05 Jul, 2021 13 commits
  9. 01 Jul, 2021 7 commits
    • Georges Racinet's avatar
      Merged heads on default branch · 1d2e5b266d48
      Georges Racinet authored
      That is why it's not so good an idea to make a topic for release
      matters (forgot to update after pull). In that precise case, it's
      not worth a new version
      1d2e5b266d48
    • Georges Racinet's avatar
      New dev cycle · a3cb19724c93
      Georges Racinet authored
      a3cb19724c93
    • Georges Racinet's avatar
      Added tag 2.8.0 for changeset 470cbb0e2c86 · 591b89a6fffb
      Georges Racinet authored
      591b89a6fffb
    • Georges Racinet's avatar
      Setting version for release · 470cbb0e2c86
      Georges Racinet authored
      470cbb0e2c86
    • Georges Racinet's avatar
      GitLab Hooks: making sure repo object is used only for path and ui · 7b46103e469d
      Georges Racinet authored
      Because the post-receive hook is now called in the locks release
      callback, we need to make sure it doesn't use anything that the
      release just invalidated, notably weak refs.
      
      But the hooks were only using the repository object for
      
      - the path to the repository (taking sharing into account)
      - `repo.ui`
      
      We now extract these two elements, and immediately delete the
      reference to the repository object. Both linters and the tests
      with full coverage complete the proof that no other use is
      occurring.
      7b46103e469d
    • Georges Racinet's avatar
      post-receive: fire after locks release · c81b287a10c3
      Georges Racinet authored
      This is a merge of change done on the stable branch, where
      it was restricted to Merge Request creations by pushvars to
      limit the risks.
      
      In all cases, it makes sense to send the post-receive only after
      new writes are permitted, because there's no telling what writes
      the Rails app would need to perform directly.
      
      As far as I understand, Git locking is weaker than Mercurial's,
      as it happens on a file-per-file basis. That's why the Rails app
      could easily grow new problematic writes that wouldn't be rejected
      by locks in the Git case.
      c81b287a10c3
    • Georges Racinet's avatar
      Next version on default branch will be 2.8 · 1d82854ea46e
      Georges Racinet authored
      …and it will match Heptapod 0.23, while Heptapod 0.22 has 2.7
      1d82854ea46e
  10. 25 Jun, 2021 1 commit
    • Georges Racinet's avatar
      post-receive: fire after locks release for MR creation pushvar · 3238d801bc5e
      Georges Racinet authored
      Because the Rails application can perform Mercurial writes
      synchronously during treatment of the post-receive API call,
      we need the latter to happen only after full locks release.
      
      The only currently know case happens during Merge Request,
      creation, hence we change the behaviour on this stable branch
      only in that case. It would probably be better to make this
      inconditionally for the default branch (after all
      PostReceive should mean the reception is fully done).
      
      Closes heptapod#505
      3238d801bc5e
  11. 24 Jun, 2021 2 commits
  12. 23 Jun, 2021 1 commit
  13. 19 Jun, 2021 2 commits
  14. 16 Jun, 2021 4 commits