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. 23 Jan, 2022 1 commit
  2. 26 Dec, 2021 1 commit
  3. 23 Dec, 2021 3 commits
  4. 24 Nov, 2021 3 commits
  5. 23 Nov, 2021 1 commit
    • Igor Drozdov's avatar
      Remove SSL_CERT_DIR logging · 2970ae7c21dd
      Igor Drozdov authored
      This log entry doesn't respect log level, because the log level
      is configured after this logging happens
      2970ae7c21dd
  6. 16 Nov, 2021 1 commit
  7. 15 Nov, 2021 1 commit
    • Patrick Steinhardt's avatar
      Fix usage of out-of-date Gitaly images · 6e4e76df7ef9
      Patrick Steinhardt authored
      Our CI jobs and docker-compose pull in the "latest" tag of Gitaly. As it
      turns out though, "latest" is pointing to Gitaly v13.3.0-rc5, which is
      definitely not the latest versionat this point in time. This is because
      CNG was converted to not use the "latest" tag anymore, but instead to
      use a tag called "master" in gitlab-org/build/CNG!519.
      
      Fix this by using the new "master" tag instead.
      6e4e76df7ef9
  8. 16 Nov, 2021 1 commit
  9. 15 Nov, 2021 9 commits
  10. 12 Nov, 2021 3 commits
  11. 10 Nov, 2021 1 commit
    • Stan Hu's avatar
      Relax key and username matching for sshd · 145796e7e295
      Stan Hu authored
      Due to the way sshd works, gitlab-shell could be called with a single
      string in the form:
      
      ```
      /path/to/gitlab-shell -c key-id
      ```
      
      However, due to the tightening of the regular expressions in fcff692b
      this string no longer matches, so logins would fail with:
      
      ```
      Failed to get username: who='' is invalid
      ```
      
      This can be reproduced by changing the user's shell to point to
      gitlab-shell. For example:
      
      ```
      usermod git -s /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell
      ```
      
      While setting gitlab-shell as the user's shell isn't officially
      supported, gitlab-shell still should be able to cope with the key being
      specified as the last argument. We now split the argument list and use
      the last value.
      
      Relates to https://gitlab.com/gitlab-org/gitlab-shell/-/issues/530
      145796e7e295
  12. 21 Oct, 2021 1 commit
  13. 20 Oct, 2021 2 commits
  14. 13 Oct, 2021 3 commits
  15. 12 Oct, 2021 1 commit
  16. 13 Oct, 2021 2 commits
  17. 12 Oct, 2021 1 commit
  18. 08 Sep, 2021 1 commit
  19. 07 Oct, 2021 2 commits
    • Igor Drozdov's avatar
      Merge branch '499-log-command-invocation' into 'main' · 194f995a8cbb
      Igor Drozdov authored
      Log command invocation
      
      See merge request gitlab-org/gitlab-shell!535
      194f995a8cbb
    • Nick Thomas's avatar
      Log command invocation · ff79c56dbc2e
      Nick Thomas authored
      Use reflection to log the command we are about to execute, both in
      gitlab-shell and gitlab-sshd. Include the environment, which has all
      the context we need to understand what the command is expected to do.
      
      Changelog: added
      ff79c56dbc2e
  20. 06 Oct, 2021 2 commits
    • Igor Drozdov's avatar
      Merge branch 'fix-logging-channel-type' into 'main' · 032c716977e8
      Igor Drozdov authored
      Fix logging channel type
      
      See merge request gitlab-org/gitlab-shell!534
      032c716977e8
    • Nick Thomas's avatar
      Fix logging channel type · c23605b604d1
      Nick Thomas authored
      Currently we get this in some log messages:
      
      logrus_error="can not add field \"channel_type\""
      
      This is because we're trying to add a function, rather than the result
      of the function call (a string) to the `log.Fields`. Whoops!
      
      Changelog: fixed
      c23605b604d1