This instance will be upgraded to Heptapod 0.31.0 (final) on 2022-05-24 at 14:00 UTC+2 (a few minutes of down time)

  1. 24 Aug, 2021 2 commits
  2. 26 Jul, 2021 1 commit
  3. 23 Jul, 2021 1 commit
  4. 28 Jun, 2021 1 commit
  5. 19 Aug, 2021 3 commits
  6. 04 Aug, 2021 3 commits
  7. 26 Jul, 2021 1 commit
  8. 23 Jul, 2021 1 commit
  9. 28 Jun, 2021 1 commit
  10. 03 Aug, 2021 2 commits
  11. 26 Jul, 2021 1 commit
  12. 04 Jun, 2021 3 commits
  13. 31 May, 2021 1 commit
  14. 04 Jun, 2021 1 commit
  15. 02 Jun, 2021 1 commit
    • Pavlo Strokov's avatar
      fix: upgrade of the gitaly dependency · 34d81ef7a529
      Pavlo Strokov authored
      Gitaly project now properly respects module release flow
      and includes a module suffix in the package name. It requires
      to re-write all non-suffixed imports with suffixed of a specific
      version of tha module. With proper module versioning we don't
      need to use a 'replace' directive to point to specific commit
      and can use semantic versioning for the gitaly dependency.
      
      Part of: https://gitlab.com/gitlab-org/gitaly/-/issues/3177
      34d81ef7a529
  16. 01 Jun, 2021 1 commit
  17. 31 May, 2021 1 commit
  18. 01 Jun, 2021 1 commit
  19. 31 May, 2021 1 commit
  20. 16 Jun, 2021 1 commit
  21. 12 Jun, 2021 3 commits
  22. 24 May, 2021 1 commit
  23. 14 May, 2021 1 commit
    • Nick Thomas's avatar
      Fix opentracing setup for gitlab-sshd · 5c36c3b5a3f4
      Nick Thomas authored
      Previously, opentracing (if configured) was initialized late in the
      gitlab-shell process's lifespan, coming just before making a gRPC
      call to Gitaly.
      
      By moving the opentracing initialization to be at process startup, we
      make it available for the whole process lifecycle, which is very useful
      to gitlab-sshd, as it means we'll only call tracing.Initialize() once
      on process startup, rather than once per SSH connection.
      
      To get this working, we need to introduce a context to gitlab-sshd.
      This carries the client/service name, but also carries an initial
      correlation ID. The main outcome of this is that all calls to the
      authorized_keys endpoint from a given gitlab-sshd process will now
      share a correlation ID. I don't have a strong opinion about this either
      way.
      
      Changelog: fixed
      5c36c3b5a3f4
  24. 21 May, 2021 1 commit
  25. 20 May, 2021 1 commit
  26. 19 May, 2021 1 commit
  27. 20 May, 2021 2 commits
  28. 19 May, 2021 1 commit
  29. 18 May, 2021 1 commit