As we reevaluate how to best support and maintain Staging Ref in the future, we encourage development teams using this environment to highlight their use cases in the following issue: https://gitlab.com/gitlab-com/gl-infra/software-delivery/framework/software-delivery-framework-issue-tracker/-/issues/36.

Skip to content
Snippets Groups Projects
  1. May 09, 2024
  2. Mar 29, 2024
  3. Mar 21, 2024
  4. Feb 16, 2024
  5. Feb 15, 2024
  6. Feb 08, 2024
  7. Jan 29, 2024
  8. Jan 18, 2024
  9. Jan 02, 2024
  10. Nov 24, 2023
  11. Oct 12, 2023
  12. Sep 08, 2023
  13. Sep 07, 2023
  14. Sep 06, 2023
  15. Aug 02, 2023
  16. Jul 06, 2023
  17. Jun 29, 2023
  18. Jun 16, 2023
  19. Apr 13, 2023
  20. Apr 07, 2023
  21. Mar 07, 2023
  22. Feb 08, 2023
  23. Jan 27, 2023
  24. Jun 23, 2022
  25. May 05, 2022
  26. Apr 18, 2022
  27. Feb 02, 2022
  28. Sep 16, 2021
    • Kevin's avatar
      makefile: properly quote '$' in VERSION_STRING · 726945b3
      Kevin authored
      If git is not available or gitlab-shell is not built in a repository, it falls back the VERSION file. That command is not properly escaped and results in the message:
      
      > awk: cmd. line:1: Unexpected token
      
      When you remove the `2>/dev/null`. Escape the '$' characters to solve this.
      726945b3
  29. Sep 07, 2021
  30. Jul 26, 2021
  31. Jul 01, 2021
  32. May 17, 2021
    • Nick Thomas's avatar
      Fix opentracing setup for gitlab-sshd · de13980f
      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
      de13980f
Loading