To spot slow or anomalous tests across CI runs, record each test's run
duration when LAZYGIT_TEST_TIMING is set (to a file path);
run_integration_tests.sh prints them at the end, sorted by slowest
first. CI sets it for all integration jobs.
The harness appends to a file rather than writing to stdout/stderr
because `go test` captures those and only surfaces them with -v, which
would drown the signal in every test's verbose logs.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add one extra integration-tests job that runs the whole suite under the
race detector. A `race` matrix dimension (default false) plus an include
entry adds a single git-latest job with LAZYGIT_RACE_DETECTOR set; races
live in lazygit's own Go code rather than in git, so one git version is
enough, and using latest skips the git-build steps.
The race job skips coverage collection: it's redundant with the non-race
latest job and would only slow the -race build down further.
I keep getting slightly confused as to which is which, so make this
extra clear.
While at it, change the default to minor, this is the option that is
more often used now that we don't have regular scheduled releases any
more.
This is useful for cutting a patch release for the previous version
when master already contains work that shouldn't be released yet; for
example, v0.63.1 had to be tagged and released by hand from a v0.63.1
branch off the v0.63.0 tag because the workflow could only release
master.
Scheduled runs are unaffected: with no input provided, the ref is
empty and the checkout falls back to the default branch.
When creating a patch release from a branch called `v0.63.1`, the new
tag would get the same name and pushing it would fail with `error: src
refspec v0.63.1 matches more than one`.
The Get Latest Tag step used to pick the most recently created tag in
the entire repo, regardless of whether it is reachable from the commit
being released. In preparation for supporting releases from branches
other than master, use the nearest tag that is an ancestor of the
checked-out commit instead. This way, a patch release cut from an
older release branch bumps that branch's own latest tag even when
master already carries a newer release, and the "changes since last
release" check compares against the release that actually precedes
this one in history.
golangci-lint bundles gofumpt v0.8.0, which formats code differently
from the v0.9.2 we pin in go.mod. Enforcing formatting through
golangci-lint may therefore disagree with `just format`.
Remove gofumpt from golangci-lint's formatters and instead run the
pinned `go tool gofumpt` as a standalone check via a new
scripts/gofumpt-check.sh, wired into CI, `just lint`, and `make lint`.
goimports stays in golangci-lint; it's stable across versions and
nothing runs a competing copy of it.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
When this was added (dafac52a4c), the job used
golangci-lint-action@v2, which had the problem that its step log was
sparse (it mostly produced PR annotations), so re-running `golanci-lint
run` was a workaround to dump readable errors into the console. The
current version of the action no longer has this problem, so we can
remove that fallback (it would conflict with what we are about to do in
this branch).
This isn't a valid key, and according to claude it's not possible to configure
it to get only security updates (I'm too lazy to read the docs). I suppose this
means we will now get pull requests for any updated dependencies, but maybe
that's useful; we'll see how annoying this gets.
There's too much manual work involved in releasing now (updating translations,
copying docs-master) to make automatic releases infeasible. I'm not worried that
I forget to release on the first Saturday of every month.
Keeping the code commented out in case we want to re-enable it at some point.
It is being auto-bumped by homebrew, like most formulae these days, so no reason
for us to do that explicitly; and it actually fails with an error message, so
stop trying.
Instead of requiring the user to install the right version of the tool in their
.bin folder, create a shim that automatically runs the right version of the
tool. This has several benefits:
- it works out of the box with no setup required (the tool will be automatically
downloaded and compiled the first time it is used)
- no work needed for developers when we bump the golangci-lint version
- it works in working copies that are used in different environments (e.g.
locally on a Mac, or inside a dev container)
Co-authored-by: kyu08 <49891479+kyu08@users.noreply.github.com>
The version choice is a little arbitrary, but see discussion at
https://github.com/jesseduffield/lazygit/pull/4559#issuecomment-2876201680.
The main reason why I'm updating the version now is that versions before 2.27
had a bug with branch sorting, where sorting by -committerdate (which will be
our default soon) would sort branches that point at the same commit in reverse
alphabetical order rather than alphabetical order. While this is only slightly
annoying but not a huge deal for users, it makes maintaining our integration
tests across versions very hard. So I wanted to update to at least 2.27 to get
around this problem, and went with 2.32 after the discussion linked to above.
The choice of which versions to run integration tests on is pretty arbitrary
too, I just picked some at random which are about 5 to 6 minor versions apart.
As far as I can tell, this is the only way to make sure that releases show up as
created by me. Also, we totally don't want it to run in other people's forks
(although it would likely just have failed there, but still).
The restriction only applies to scheduled runs; manually triggering the action
is still possible from everywhere. There needs to be a personal access token
named LAZYGIT_RELEASE_PAT configured on the repo for this to work, though.
Stefan Haller
dependabot[bot]andGitHub
Ubuntu
dageckoandStefan Haller
Padraic SlatteryandStefan Haller
kyu08