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.
There's no way to tell cron to run a job on the first Saturday of a month, so we
tell it to run every Saturday, and manually check whether it's the first week of
the month. This is not ideal because we'll get notifications about failed
releases three times a month, but it's better than nothing for now.
1) the cron schedule was wrong: it was doing every saturday, rather than
the first saturday of each month.
2) It wasn't triggering a deploy despite pushing a tag because clearly
github doesn't want that to happen.
Now it triggers a deploy, and it also allows triggering from the UI,
letting you specify minor/patch bump and whether to ignore blocking
PRs/issues. As such I'm removing support for the old method of pushing
the tag. The new way is the only way.
Github actions refuses to trigger a workflow from another workflow, but
if you use your own personal access token (in this case,
GITHUB_API_TOKEN), it should work.
This script is failing currently on
https://github.com/jesseduffield/lazygit/pull/3631 because that fork's
master branch is 300 commits behind our own, but the feature branch is
up to date.
The thing is, we don't actually need to involve the master branch. All
we care about is the feature branch's own commits, so this commit simply
fetches those commits and checks them.
It is annoying when CI builds suddenly start to fail because the linter was
updated and finds new things to complain about.
Updating the linter and fixing the code accordingly should be a dedicated
activity.
It used to be a common thing to have to update Config.md in a PR (and we often
forgot despite the template). As of #3565 this is no longer necessary, so remove
this from the template.
Updating docs in general is still a good thing to think about, so we leave this
in.
Codacy's coverage report feature requires the use of a secret key, which
is only available on the main repo and is not available on forks. So,
the step has been always failing on any forks. This commit ensures that
we only run it on non-forks.
This greatly diminishes the value of the coverage reports. I've talked
to one of the Codacy people and advised that they should just have an
API key for coverage reports which is not a secret, like what bugsnag
does.
