| Age | Commit message (Collapse) | Author |
|---|
|
Before converting to the new `WithGoBuildInformation()` monitoring
option in the preceding commit we always exposed the build time. We have
stopped doing that now and instead only expose information that Go puts
into the binary itself.
As a result, we can now drop the infrastructure to embed the build time
into the binary. This has the advantage that it significantly improves
incremental build times: previously we'd basically have to rebuild all
binaries every single time, as the embedded build time changes every
second. As we stop doing that we can in many cases skip this step. On my
machine this leads to a 3.5x build speedup.
Benchmark 1: make
Time (mean ± σ): 12.163 s ± 0.148 s [User: 16.677 s, System: 3.496 s]
Range (min … max): 12.044 s … 12.328 s 3 runs
Benchmark 2: make GO_LDFLAGS=
Time (mean ± σ): 3.469 s ± 0.060 s [User: 5.593 s, System: 1.880 s]
Range (min … max): 3.433 s … 3.539 s 3 runs
Summary
'make GO_LDFLAGS=' ran
3.51 ± 0.07 times faster than 'make'
This has been benchmarked with the preceding commit which still embedded
the build time into the binary. By stubbing out the `GO_LDFLAGS`, which
is how we put the build time into the resulting binary, we are able to
emulate the new behaviour with this commit.
But besides the quality-of-life improvements for developers another
significant advantage is that we now have reproducible builds.
Changelog: fixed
|
|
Praefect uses its own wrapper functions to derive version information,
but ultimately it really only shells out to `internal/version`. The only
difference is that Gitaly would return a "Gitaly"-prefixed string while
Praefect returns a "Praefect"-prefixed string.
Deduplicate this infrastructure by adding a new parameter to the
`GetVersionString()` function.
|
|
We're compiling the Go module version of the Gitaly package into the
code. This was used in the past to locate the correct set of auxiliary
binaries like `gitaly-git2go-v15`. But since we have started to package
those binaries into the main `gitaly` executable we don't need to tell
apart different module versions anymore. We have thus removed the last
user of `version.GetModuleVersion()` in 1ba0ce586 (Hardcode module
version in git2go binary name variable, 2022-06-28).
Drop the infrastructure to expose the module version.
|
|
Reformat sources with gofumpt.
|
|
0 downtime deployment replaces the binaries on the disk and then
does the HUP. When gitaly-git2go binary replaced with the new major
version, but gitaly process is still of the previous release the
gob fails to process marshalled data as it operates with structs
of the different import path (module major version is part of the
path). The change introduces version suffix to the gitaly-git2go
binary. It allows gitaly to call a proper binary of the gitaly-git2go
as it now uses a version suffix. At the time of deployment the new
binary will be placed and the old one will remain untouched. The
running old gitaly process will refer to the old binary of the
gitaly-git2go and after HOP the new gitaly binary will refer the
new version of the gitaly-git2go.
BinaryPath function support one corner case - for the gitlab.com
the deployment is not yet changed, but it already has a new v14
binary of the gitaly-git2go. That is why we first check if versioned
binary is present and if not it falls back to the raw name without
suffix. That ad hoc fix should be removed once deployment is changed.
Part of: https://gitlab.com/gitlab-org/gitaly/-/issues/3647
|
|
Prior to this change, the build time was displayed when the -version
flag was passed. This made it possible that the output was unstable for
the same version. The .com upgrade script depended on them being equal.
This change simply removes it.
Related: https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3598
|
|
|
|
|
