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. Mar 29, 2024
  2. Mar 21, 2024
  3. Feb 16, 2024
  4. Feb 15, 2024
  5. Feb 08, 2024
  6. Jan 29, 2024
  7. Jan 18, 2024
  8. Jan 02, 2024
  9. Nov 24, 2023
  10. Oct 12, 2023
  11. Sep 08, 2023
  12. Sep 07, 2023
  13. Sep 06, 2023
  14. Aug 02, 2023
  15. Jul 06, 2023
  16. Jun 29, 2023
  17. Jun 16, 2023
  18. Apr 13, 2023
  19. Apr 07, 2023
  20. Mar 07, 2023
  21. Feb 08, 2023
  22. Jan 27, 2023
  23. Jun 23, 2022
  24. May 05, 2022
  25. Apr 18, 2022
  26. Feb 02, 2022
  27. 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
  28. Sep 07, 2021
  29. Jul 26, 2021
  30. Jul 01, 2021
  31. 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
  32. Apr 12, 2021
Loading