Skip to content
Snippets Groups Projects
  1. Mar 02, 2022
  2. Mar 01, 2022
  3. Feb 26, 2022
  4. Feb 15, 2022
    • Georges Racinet's avatar
      New development cycle · e3f7b440
      Georges Racinet authored
      e3f7b440
    • Georges Racinet's avatar
      bac33d4a
    • Georges Racinet's avatar
      Setting version for release · 99c8325e
      Georges Racinet authored
      yes, the dev version should have been 0.21.0dev0
    • Georges Racinet's avatar
      Bumped Gitaly protocol to 14.6 · 0efcb9e1
      Georges Racinet authored
      All the changes seem to be related to praefect, except
      in FetchBundleRequest (probably for pull mirrors)
      
         // UpdateHead will update HEAD if there is a HEAD reference listed in the bundle
         bool update_head = 3;
      
      Reminder: HEAD is used in Git to record the default GitLab branch.
      0efcb9e1
    • Georges Racinet's avatar
      RepositoryService.CreateRepository: style uniformity in errors · 43cf3344
      Georges Racinet authored
      This is actually a good example to explain my take on this,
      which is not shared by all developers around. This is more
      readable in my mind because
      
      - the single statement (outlined by further indentations) goes
        straight to the point, which is to return some explicit error,
        rather than distracting attention of the reader with preparations
        about secondary aspects (error message).
      - name of variables in preparations tend to have very
        generic semantics (`msg`, `value`, `res`) and to be reused a lot.
        That is, in Python, a source of bugs that can be hard to track.
        OTOH using something more specific like `already_exists_msg`
        would be overkill.
      - `repr` or `%r` is a great way to make the messages understandable even
        if there are empty strings or whitespaces. In this specific case,
        f-strings would be appropriate, too.
      
      Should write this in a coding style somewhere…
      43cf3344
    • Georges Racinet's avatar
      RepositoryService.CreateRepository: error if path already taken · f7c06a89
      Georges Racinet authored
      In version 14.6, Gitaly makes it an error to attempt to create
      a repository if anything already exists at the target path
      (even broken symlinks).
      
      This is worth a minor version change.
      
      This deprives us of the way we were triggering actual
      repository creation errors in tests.
      To maintain coverage, we're now using the broken symlink
      trick one step higher in the file hierarchy: on the storage itself.
      Playing with permissions would not work in CI.
      f7c06a89
    • Georges Racinet's avatar
      errors.already_exists() · 46369243
      Georges Racinet authored
      This gRPC error code was not used yet. We will need it for
      upcoming changes related to Gitaly 14.6
      46369243
  5. Jan 23, 2022
    • Georges Racinet's avatar
    • Georges Racinet's avatar
      Gitaly Comparison tests: discover Gitaly and Git paths · c7ae3e5a
      Georges Racinet authored
      In our CI image, the `gitaly` executable sits right at
      the top. Moving it back there was an actual choice of ours that
      we could have reverted, but it feels actually right for the
      Gitaly home directory in the CI image not to be necessarily a
      source checkout or carry build intermediate results (to keep it
      slim).
      
      For better flexibility, we introduce a simple discovery that
      can take care of both.
      
      Also, in CI, we have `/usr/local/bin/git`, with the right
      version: no reason to use the one that Gitaly can build.
      c7ae3e5a
  6. Jan 21, 2022
  7. Jan 03, 2022
  8. Dec 26, 2021
  9. Nov 26, 2021
  10. Nov 22, 2021
  11. Nov 20, 2021
    • Georges Racinet's avatar
      MercurialRepository.Push: prevent auto-publication and GitLab sync · bd3911e6
      Georges Racinet authored
      The GitLab sync would need to get user information to ask for
      permission (pre-receive hook) and to send resulting information
      (post-receive hook). This would require changing a bunch of internal
      APIs in the Rails application for the `hg-push` mirror update use case
      (currently the only one).
      
      Furthermore, the post-receive hook would in turn
      trigger an update of the `hg-push` remote mirror, resulting in effect in an
      infinite loop of pushes (we've witnessed the state maintainer `pretxnclose`
      Mercurial hook running even if no auto publication occurred).
      
      This can be improved later on, but for now, we'll make the push
      effectively read-only by disabling auto publication, and that
      allows us to unplug the GitLab state maintainer (`heptapod_sync`).
      
      Users of `hg-push` mirrors will see an explicit message in the
      mirror settings page in the case where the push would have been
      publishing. Chances are that publication by the mirrorring would
      have been very unwelcome anyway (note also that in its first
      incarnation, the Rails app won't expose the `include_drafts` boolean).
      bd3911e6
Loading