I'm not sure if it arose in practice, but: ensure TransactionScreen
in V mode would correctly use the journal's last day as valuation date,
not the day after that.
As first step in our main "check" workflows (push, linux, mac,
windows), check all the commit messages with commitlint.
These workflows can be triggered in various ways:
pull requests, pushes, manually, or scheduled.
For (each push to) a pull request, all commits currently in the PR
branch are checked.
For a regular push, all the pushed commits are checked, usually.
Subcases: push to master, push to other branch, force push;
I think at least the first two work, I don't care to spend more time
on it.
For a manual run, it seemed to check the same commits as a push (which
push ? Not sure how this works).
For a scheduled run - we'll see.
tsInit based on the previous RegisterScreen. Use the RegisterScreen
logic for selecting the new transaction when we cannot find the existing
one.
This enables us to get rid of regenerateTransactions. There is now
different behaviour in the transaction screen when the journal is
reloaded and the transaction being viewed is no longer available, but I
have not been able to find an example which exhibits this different
behaviour. I think it is better to have consistent behaviour between the
register screen and transaction screen when determining which to select.
This corrects a bug where you had to reload twice to reset the valuation
and cost flags, due to the elimination of regenerateTransactions.
Also corrects a regression introduced in
8ab29f84b3 where transaction modifier
postings without multipliers would incorrectly be filtered by commodity.
Adding new CI workflows building static executables for linux, both intel 64-bit and ARM32v7.
These will be useful for providing hledger on Nextcloud, and also as general linux executables, more robust than the ubuntu executable we have been providing.