1. 21 Jan, 2022 12 commits
  2. 20 Jan, 2022 2 commits
  3. 19 Jan, 2022 3 commits
  4. 18 Jan, 2022 17 commits
    • Matt Smiley's avatar
      Allow faster local builds · ead34b5a
      Matt Smiley authored
      This applies Patrick's patch from:
      !4192 (comment 810475985)
      The only changes from his original patch are:
      * Rename "WITH_BUILD_ID" to "WITH_GNU_BUILD_ID" for clarity.
      * Enable it by default.  Verified that disabling locally works.
      The intent here is to allow developers to optionally speed up their
      local builds by a few seconds, by using a single invocation of
      "go build" rather than a separate invocation for each binary.
      The only reason we need to run "go build" separately for each binary is
      to provide each binary a unique value for GNU build-id.  We always want
      that build-id to be present for binaries we may deploy or ship, but during
      local builds, they are not needed unless doing local profiling.
    • Patrick Steinhardt's avatar
      Merge branch 'pks-ci-run-tests-unprivileged' into 'master' · 7cd8ef21
      Patrick Steinhardt authored
      ci: Run tests as unprivileged user
      See merge request !4254
    • Sami Hiltunen's avatar
      Merge branch 'enable_libgit2_fsync' into 'master' · c275ce42
      Sami Hiltunen authored
      Enable fsync for git objects written by git2go
      Closes #3998
      See merge request !4261
    • Pavlo Strokov's avatar
      Merge branch 'ps-sort-list-ref' into 'master' · 62920dd3
      Pavlo Strokov authored
      ref: Sort results of ListRefs
      Closes #3855
      See merge request !4221
    • Patrick Steinhardt's avatar
      git: Set up Git hooks via symlinks · 47b61cae
      Patrick Steinhardt authored
      When introducing the new temporary hooks directory created by the Git
      command factory we had to resort to writing a wrapper script because
      `gitaly-hooks` required the first argument to be set to the hook name
      we're about to execute. This has been fixed now though, where it can
      also use its zeroth argument to derive the hook name.
      Refactor the code to not write a wrapper script anymore, but instead to
      just create symlinks pointing at the `gitaly-hooks` binary. This avoids
      having to spawn the shell just to execute the binary and thus reduces
      one more point of friction.
      Use of the temporary hooks directory is still guarded by a feature flag
      which hasn't yet been rolled out, so we don't need a new feature flag
      for this change.
    • Patrick Steinhardt's avatar
      cmd/gitaly-hooks: Resolve hook name by zeroth argument · 49aa813f
      Patrick Steinhardt authored
      The old way of executing the `gitaly-hooks` binary works via a wrapper
      script which resolves the location of the binary via an environment
      variable and then executes that script with its initial argument set to
      the hook name we want to execute. With the new temporary hooks directory
      created at runtime we're still essentially doing the same thing, except
      that we don't need the environment variable anymore because we already
      write the path of the `gitaly-hooks` binary into the wrapper script
      This is needlessly roundabout though: instead of using a wrapper script
      we can simply create symlinks which directly point to `gitaly-hooks`.
      The only problem is that we cannot resolve the hook name in that case
      because we don't set the first argument to it anymore. This can be
      worked around though: when executing a symlink, the zeroth argument will
      be set to the location of the symlink and not to the location of the
      linked binary. We can thus use it to resolve the hook name instead of
      having to pass an extra argument. While we need to be able to continue
      handling non-hook cases like e.g. when executing "gitaly-hooks check",
      the basename in that case will be `gitaly-hooks` and thus easily
      discernable, as well.
      Refactor the code to do so. Due to backwards compatibiliy concerns we
      need to retain both old and new way to resolve the hook name. The
      upgrade path is easy enough:
          - We either have a basename of "gitaly-hooks" in the zeroth argument
            and will then take the first argument as hook name. This is
            currently used by the `gitlab-shell-hook` wrapper script and when
            executing the binary directly.
          - Or we have a basename different of "gitaly-hooks", where we then
            use the zeroth argument to resolve the hook name.
      The only outlier is the temporary wrapper script we write in via the Git
      command factory, which both has its zeroth and first arguments set to
      the hook name. Given that this code is guarded by a feature flag though
      which hasn't yet been rolled out this is not much of a concern and
      adjusted while at it.
      Furthermore, because the command factory now uses the zeroth argument
      while the `gitlab-shell-hook` wrapper uses the first argument to execute
      the hook, we implicitly test that `gitaly-hooks` handles both ways as
      expected because all of our tests randomly switch between both hook
    • GitLab Release Tools Bot's avatar
      Update changelog for 14.6.3 · aeec715b
      GitLab Release Tools Bot authored
      [ci skip]
    • Patrick Steinhardt's avatar
      cmd/gitaly-hooks: Strip arguments before passing them to hook logic · 6b84fe8d
      Patrick Steinhardt authored
      The Git hook implementations we use currently get the complete command
      line arguments, even though they only care about their own hook-specific
      arguments. This has worked alright until now, but we're about to
      introduce an alternative way of resolving the hook name via the zeroth
      argument, and in that case stripping the initial two arguments doesn't
      fly well anymore.
      Refactor the code to only pass in arguments relevant to the hooks. This
      allows us to strip less arguments when introducing the new way to
      resolve the hook name.
    • Patrick Steinhardt's avatar
      cmd/gitaly-hooks: Extract function which execute hooks · eda5e6cb
      Patrick Steinhardt authored
      Refactor the code executing hooks and pull it out into its own function
      such that we can reuse its logic.
    • Toon Claes's avatar
      Merge branch 'ps-msg-check' into 'master' · 871f4415
      Toon Claes authored
      command: Fix log message verification
      Closes #3980
      See merge request !4249
    • Patrick Steinhardt's avatar
      Merge branch 'jv-ssh-sidechannel-2' into 'master' · b5722938
      Patrick Steinhardt authored
      Add SSHUploadPackWithSidechannel
      Closes gitlab-com/gl-infra/scalability#1513
      See merge request !4251
    • Pavlo Strokov's avatar
      ref: Sort results of ListRefs · e1c29d57
      Pavlo Strokov authored
      In order to provide more flexibility to our API
      we are extending ListRefs RPC with sorting.
      The caller now can set a sorting key and a direction
      in which the results will be returned back.
      Closes: #3855
      Change: added
    • Toon Claes's avatar
      Merge branch 'ps-code-cleanup' into 'master' · 870d04c2
      Toon Claes authored
      Cleanup from unused/deprecated code
      Closes #3997
      See merge request !4258
    • James Fargher's avatar
      gitaly-git2go: Enable git2go fsync for git objects · ee6f7f1e
      James Fargher authored
      We already use `core.fsyncObjectFiles` to enable fsync on git itself.
      Changelog: changed
    • James Fargher's avatar
      gitaly-git2go: Ensure both subcommand result error fields are set · 2af0319c
      James Fargher authored
      We cannot remove Error until next release.
    • James Fargher's avatar
      gitaly-git2go: Convert ConflictError to an actual error · 8b703507
      James Fargher authored
      In order to centralised error handling in future releases it would be
      nice to also remove the ConflictError specific Error field. To that end
      here we convert it to a go error type that can be passed through the new
      Err error field.
    • James Fargher's avatar
      gitaly-git2go: Ensure all subcommands have a compatible error return · fe157a75
      James Fargher authored
      This will allow us to generically send git2go.Result for error handling
      no matter what sub-command is being used and still have errors handled
      correctly. Gob encoding allows us to have different structs with
      differing field sets, as long as the fields we care about are named the
      same and are type compatible.
  5. 17 Jan, 2022 6 commits
    • Patrick Steinhardt's avatar
      Merge branch 'toon-modify-env-cleanup-test' into 'master' · b119c197
      Patrick Steinhardt authored
      testhelper: ModifyEnvironment cleans after itself
      See merge request !4263
    • Pavlo Strokov's avatar
      Merge branch 'pks-git-deprecate-ruby-hooks-directory' into 'master' · ac73d94e
      Pavlo Strokov authored
      git: Support setup of the hooks directory at runtime
      Closes #3932
      See merge request !4259
    • Patrick Steinhardt's avatar
      doc: Update hooks documentation to reflect new setup · 42b5313d
      Patrick Steinhardt authored
      Update the hooks documentation to reflect the new hooks setup which uses
      a temporary directory.
    • Patrick Steinhardt's avatar
      git: Support setup of the hooks directory at runtime · dfeeebe1
      Patrick Steinhardt authored
      Gitaly's hooks are currently located in the Ruby directory, which we can
      (hopefully) get rid off soon. As a consequence, we also need to move our
      hooks somewhere else. While we could just create a different on-disk
      directory which is installed alongside with Gitaly, this creates more
      complexity than is worth it. Instead, we can just set up the hook
      directory at runtime by creating a temporary directory which has all the
      necessary hooks set up. Like this, we have one thing less that needs to
      be configured given that the only configuration we need for this to work
      is the location of the "gitaly-hooks" binary, which is easily derived
      from the binary path.
      This new temporary directory is being created by the Git command factory
      at creation time. Ideally, this was done by just creating symlinking the
      required hooks to the `gitaly-hooks` binary. Unfortunately though, it
      depends on the first parameter being set to the name of the hook that is
      about to be executed. This is rather pointless: it could just derive the
      name from its zeroth argument, which would be set to the symlinks path
      anyway. That would require a separate change to `gitaly-hooks` though,
      and due to backwards-compatibility reasons that would require a full
      release cycle.
      Instead, we're writing a wrapper script into the hook directory that's
      the same as our current `gitlab-shell-hook` script. There are two
      differences though:
          1. The new script doesn't need the `GITALY_BIN_DIR` environment
             variable anymore to resolve the path of `gitaly-hooks`, but
             instead has its path resolved at creation-time of the script
          2. The new script sets both the zeroth and first argument of
             `gitaly-hooks` to its own name. This will eventually allow us to
             migrate `gitaly-hooks` to resolve the hook name via its zeroth
             argument. In the end, this means that we can then get rid of the
             wrapper script altogether.
      This change is done behind a new feature flag given that execution of
      hooks is essential to all writing code paths. This feature flag is
      injected with a random value into all of our tests to assert that they
      work correctly both with the flag enabled and disabled.
      Changelog: changed
    • Jacob Vosmaer's avatar
      gitaly: implement SSHUploadPackWithSidechannel · 3a9a9406
      Jacob Vosmaer authored
      This adds the server side implementation of
    • Jacob Vosmaer's avatar
      gitaly-ssh: add sidechannel support for upload-pack · 12185418
      Jacob Vosmaer authored
      If GITALY_USE_SIDECHANNEL=1 is set, gitaly-ssh will use
      SSHUploadPackWithSidechannel instead of SSHUploadPack.