Read about our upcoming Code of Conduct on this issue

This instance will be upgraded to Heptapod 0.28.1 on 2022-01-26 at 16:00 UTC+1 (a few minutes of down time)

  1. 10 Nov, 2021 1 commit
  2. 13 Oct, 2021 1 commit
  3. 24 Aug, 2021 3 commits
  4. 26 Jul, 2021 1 commit
  5. 23 Jul, 2021 1 commit
  6. 28 Jun, 2021 1 commit
  7. 19 Aug, 2021 3 commits
  8. 04 Aug, 2021 5 commits
  9. 26 Jul, 2021 1 commit
  10. 23 Jul, 2021 1 commit
  11. 28 Jun, 2021 1 commit
  12. 03 Aug, 2021 2 commits
  13. 26 Jul, 2021 1 commit
  14. 04 Jun, 2021 3 commits
  15. 31 May, 2021 1 commit
  16. 04 Jun, 2021 1 commit
  17. 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
  18. 01 Jun, 2021 1 commit
  19. 31 May, 2021 1 commit
  20. 01 Jun, 2021 1 commit
  21. 31 May, 2021 1 commit
  22. 16 Jun, 2021 1 commit
  23. 12 Jun, 2021 3 commits
  24. 24 May, 2021 1 commit
  25. 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
  26. 21 May, 2021 1 commit
  27. 20 May, 2021 1 commit