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.
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.
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.
