Scheduled downtime of 1h starting on 2020-01-27 at 11:00 UTC+1 as this instance will be migrated to Clever Cloud hosting

  1. 14 Jan, 2020 1 commit
  2. 13 Jan, 2020 3 commits
  3. 08 Jan, 2020 1 commit
  4. 07 Jan, 2020 5 commits
    • Merging: fixed some hg calls that didn't have proper HGRCPATH · a156fa668f7
      Graft of bcef37284f4f
      Because that is crucial for proper output of `hg log` and friends
      (we don't want warnings about obsolescence markers being there but
      obsolescence not being enabled), we have to pass the environment
      to all `hg` calls, and to use `popen()`.
      The `popen()` syntax is much saner anyway, shell-script like
      syntax should be avoided in anything but simplest scripts (even
      though %W actually builds an array, it's just wanting bad stuff
      to happen). Should have done that before.
      branch : heptapod
      Georges Racinet authored
    • Restoring SSH dropdown clone option · 98caa20e0db
      Closes #153
      Had to adapt it for Mercurial, which always use URLs.
      Also worthwile to note is that we previously made 'http'
      the default (well it was the only reasonable one), now
      we just let the standard GitLab machinery decide according
      to various settings and possibly user preferences.
      branch : heptapod
      Georges Racinet authored
    • Factorized Mercurial access level logic · cecd90c9124
      In the previous changes for SSH support, we introduced
      the `access_level` method in `hg_access.rb`, which made some
      of the logic in `hg_http_controller` a duplicate.
      Now we refactor that so that `hg_access.rb` is the only
      one responsible for this.
      branch : heptapod
      Georges Racinet authored
    • Merge from heptapod-0-7 with adaptations · 330499f403c
      - repos.hgrc does not exist any more. The activation of
        the `heptapod` extension done in heptapod-0-7 branch
        is indeed present in its new incarnation (required.hgrc
        in `py-heptapod`)
      - in repository.rb, `pull_force_topic` needs to pass HGRCPATH
        and use the proper `hg` executable
      branch : heptapod
      Georges Racinet authored
    • Rake task to remove legacy SSH key · 01fba293dd2
      We don't need to create an SSH key for inner pushes to Git,
      quite the contrary: now we want to remove it.
      See #144 for context.
      branch : heptapod
      Georges Racinet authored
  5. 05 Jan, 2020 8 commits
    • Imports: let's be tolerant with slashes in topic names · 36f0b04ca3d
      Since hg-git!31313131313131313131313131313131313131313131313131313131313131 these would be refused by default. We don't
      want to abort a looong import for a tiny ill-named topic.
      branch : heptapod-0-7
      Georges Racinet authored
    • Next version from main branch will be 0.9 · ba7aec04bac
      branch : heptapod
      Georges Racinet authored
    • Heptapod-source: installation guide · 9c205f11eae
      branch : heptapod
      Georges Racinet authored
    • Heptapod-source: made hgserve URL configurable · 0ae5fd0aeaa
      As noted in the example, it doesn't work readily with
      a Unix domain socket, we'll retry later with the library
      wrapper that GitLab uses in version 10.5.8 (introduced for
      XSS protection, but who knows)
      branch : heptapod
      Georges Racinet authored
    • Splitting default HGRC in two · dd747e13d61
      This is exactly what Docker installations will need so
      that their `heptapod.hgrc` is fully under control of the
      local admin and can later be relocated to a source or Omnibus
      branch : heptapod
      Georges Racinet authored
    • Heptapod-source: finally moved repos.hgrc to py-heptapod · a8813c1570f
      Since we'll need to list the hgrcs in gitlab-shell
      without a priori knowledge of the Rails root,
      it's simpler for the configuration to be exactly the
      same in Rails and in Shell, and the most symmetric
      location to put it is in `py-heptapod`.
      We also take the occasion to centralize the hgrc_path
      method in a dedicated library.
      branch : heptapod
      Georges Racinet authored
    • Removing Gemnasium dependencies · 2e64dcb2a4f
      The gemnasium-gitlab-service gem is not available anymore,
      making the Rails app impossible to build and start from the
      given Gemfile.
      It would be completely useless anyway, because the Gemnasium
      service has closed, following the buyout by GitLab.
      Hence we remove anything about Gemnasium from Heptapod.
      branch : heptapod
      Georges Racinet authored
    • Heptapod-source: configurable global HGRC and hg executable · ff600b368c8
      In source installs, it can happen that the proper `hg`
      executable to be used is not the system-wide one. For
      example, a developer would want to install the exact
      version of Mercurial and of the `heptapod` extensions in
      a virtualenv.
      In source installs, the path to the global hgrc won't
      typically be the `/etc/gitlab/heptapod.hgrc` we've been
      using in Docker context.
      Moreover, we'd like not to store in the repo something
      that actually depends on installation details of the instance
      at the time of its creation.
      HGRCPATH serves the same purpose of enforcing some common
      settings, without being stored in the repo. The Rails
      application will now read the path to an instance wide
      specific HGRC from its config, with a default that makes Docker
      installation work without writing Chef rules (Omnibus) for
      Mercurial yet.
      Because HGRCPATH is meant to specify several paths, we take
      also the opportunity to get rid of the '%include' directive
      we had in the previous 'heptapod.hgrc', and pass over the
      one for structural and default settings (for now bundled
      with the Rails app) together with the user-defined one.
      Mercurial operation that does not originate directly from
      the Rails app is for now only through `hgserve`, which will
      have to load the exact same global HGRCs – that was already
      the case before this change.
      One consequence of all this is that our separtion of repo-local
      HGRCs with a `hgrc.local` that's manageable by the local admin
      is now useless, we remove it: from now on, the repo-local HRGC is
      under full control of the local admin.
      Docker instances will need a migration step for that.
      branch : heptapod
      Georges Racinet authored
  6. 02 Jan, 2020 1 commit
  7. 24 Dec, 2019 1 commit
  8. 22 Dec, 2019 1 commit
  9. 21 Dec, 2019 3 commits
    • SSH support: enforcing write permission for all protocols · 888c426ffbf
      Really, it's probably time this configuration file goes to
      branch : heptapod
      Georges Racinet authored
    • api-internal: exposing Mercurial access level · 0aa00db7d6e
      This will be called by GitLab Shell, in order to
      decide if to proceed with the SSH command, and to
      pass over the access level to Mercurial.
      branch : heptapod
      Georges Racinet authored
    • HgAccess: new method to centralize the permission level · 0b1222a7819
      With Mercurial over SSH, GitLab currently can't know
      upfront the commands that will be issued on the repo,
      because that is part of the payload, not of the
      server-side executable.
      Once read access is cleared (including anonymous access),
      most of our HTTP permisson checking works also this way,
      because that's what `hgweb_mod` provides out of the
      box. We also have the extreme case of publish permission:
      Mercurial does not know if it's needed from the applied
      command, but from the result of processing the changes.
      That's why we enforce it in a `pretxnclose` hook.
      We need therefore a way to centralize the user access level
      (`read`, `write`, `publish`) for the different ways to pass
      it over to Mercurial and return it to pass it over to Mercurial,
      and it makes sense to provide that at the library level.
      Returning `nil` means no access.
      We'll use it for clarity and code deduplication in the Hg
      Project controller in a follow-up (could be post 0.8.0)
      branch : heptapod
      Georges Racinet authored
  10. 17 Dec, 2019 3 commits
    • Fixed hg project rename/destroy/transfer for v10.5.0.pre · 6af9b9a7161
      In v10.5.0, GitLab actually simplified their method structure
      for these actions, probably because they are to be handed over
      to Gitaly.
      It is therefore simpler to abid to their new style, and just
      add a line for the hg repo rather than keep Mercurial specific methods.
      Of course we'll have to revise this once we restablish Git support
      branch : heptapod
      Georges Racinet authored
    • Merged with v10.5.0.pre · 89aad9adb46
      Thanks to the previous revert/resync to v10.4.0.pre,
      we only had two conflicts to fix, and a change to partially
      branch : heptapod
      Georges Racinet authored
    • Resynced to common ancestor of 10.4.0-rc2 and 10.5.0.pre · 9c3bdb25d5b
      Actually, 10.4.0-rc2 was not in the main history line that
      was Git master at the time, so we're reverting to b40d600d09d9.
      Also, we had some remnants from
      10.3.x security fixes (notably the wrapping of HTTParty into
      GitLab::HTTP, and the symlink protection in imports)
      Of course concrete Heptapod versions will be made with merges
      from GitLab stable branches that will put all stability and
      security fixes back.
      It's probably more interesting to look at the resulting diff
      with b40d600d09d9 than at the diff of the present revision.
      branch : heptapod
      Georges Racinet authored
  11. 16 Dec, 2019 1 commit
  12. 15 Dec, 2019 5 commits
  13. 13 Dec, 2019 4 commits
  14. 10 Dec, 2019 1 commit
  15. 07 Dec, 2019 2 commits