Why not use git for updating? And Actual Budget Update Issues...

[mjschmidt271]

First, let me say how much I appreciate the hard work of everyone involved and believe this project is absolutely top-notch.

---

For context, what got me here is the fact that the Actual Budget update script has been a bit of a mess for weeks now. Nobody's perfect, and hiccups are to be expected, particularly when it comes to a FOSS project like this one.

My issues, however, are a result of what I'd consider easily avoided pain points. For example:

• Breaking changes without indicating as such.
  • The update workflow changed, I had no idea, and spent an hour debugging what should be a simple bash script.
  • I'd recommend a big message that remains on screen indicating that the recent change will break old builds. Then retire the message after however long.
• Lack of graceful error handling.
  • When introducing breaking changes, one should know where it will fail if run on an older installation and, at minimum, give helpful error messages.
  • The ideal case, however, would be introducing a reasonable fix to put the old installation in compliance with the new update script.
    • For example, in the case of actual, this is the error I got

        ✔️  Actual Budget Stopped
       ⠏mv: cannot stat '/opt/actualbudget_bak/.env': No such file or directory
      
      [ERROR] in line 50: exit code 0: while executing command mv /opt/actualbudget_bak/.env /opt/actualbudget

      All in all, not too bad to debug, but it immediately raises questions about why I don't have that .env file, what it's function is in the new installation, and what is the most straightforward way to fix this for myself.
      • A better option, imho, would be to just create the .env file, so that the update can proceed and the installation will be compliant with the next update.
  • Could also do a <cmd> || true to get past the errors, record an error code, and inform the user if the script completed with a non-ideal install condition.
• The more frustrating part is that the user is left with a broken installation after this minor error.
  • I figured out pretty quickly that I could just mv actualbudget_bak actualbudget, but that would be more of an issue for some.
  • My preferred option would be to, in the event that the startup command fails, restore the original, working version unchanged.

    [...]
    systemctl start actualbudget
    systemctl status actualbudget 1> /dev/null
    errcode=$?
    if [ <error happened> ]; then <revert to original>

I thought you said this was about git??

That is correct and brings me to my big-picture question--Why not just use git? I only know that it appears to be avoided based on this comment in #1707 but I'm not sure why.

The main part of the update could be as simple as

git fetch --tags
new_version=$(git describe --tags "$(git rev-list --tags --max-count=1)")
git checkout "${new_version}"
yarn install
<see above>

and if you want to be extra careful, could even do a

git stash push -m "pre-update"
git stash push --include-untracked -m "pre-update untracked files"

I can appreciate the argument against extra dependencies, but... it's git. It's everywhere and specifically designed to be the ideal tool for this use case. It's also 54M for v2.48.1 on the /git/git repo. I suppose that can add up, but could also just drop it into a lxc_bin directory on the server and bind mount it into each LXC.

All that said, please let me know where I've got it completely wrong and what I can do to lend a hand. I'm happy to submit a proof-of-concept PR for the git-based workflow if that seems like an idea others can get on board with.

Thank you all for this fantastic project--it's tough to put into words how much I appreciate all of this!

[MickLesk]

Sorry, actual Budget is one of the most broken Scripts. Just in ttecks time. Every day I think about whether I should remove this script completely. Even in the evaluation, it only shows problems over a longer period of time. This is not only partially poorly developed for bare metal, but there are now major changes in every major version.

If you don't use this tool, you have no chance of maintaining it. And nobody from the community here makes it 🤷🏼‍♂️. So it will probably be removed at some point during the next break.

If you don't like the update mechanism, nobody is forcing you to use the scripts. Then pull a git on a Debian LXC and maintain it with git. You can't assume that we have A-X versions for every LXC. Mostly it's our private computers where we only install LXCs if there is a bug, at most we switch to an old version beforehand and try to install updates. Sometimes it works, sometimes not. If we had a server center, we could deploy every script as soon as an update comes, but nobody pays for that, we are all volunteers and I put another 20 hours a week into the project in addition to my full-time job 😅
With the last breaking change yesterday, we have already fixed over 1500 failed installations (in 4 days).

We have always spoken out against Git because of the problems and inconsistencies. This has nothing to do with the few MB. You have to look at the masses, some projects push permanently against Main, without complete releases etc. Nobody knew which Git version was currently being used by the user. Which one was available before etc. Which one was available before, wrong or bad dependencies etc. Pp. So we always have a release tarball that we can access and that is hopefully consistent enough. However, this is not always the case with projects like Actual Budget and others.

All breaking changes are also noted accordingly in the changelog. Usually also with migration instructions. We can't catch every use case, they are ultimately helper scripts and not “I do everything + every case” scripts.

[mjschmidt271]

That all makes sense to me--thank you for the explanations.

Sounds like the goal is to have standardized procedure for installing, updating, etc., and that git makes it tricky to impossible to always do things the same way?

Anyway, thank you again, and apologies if my post came off as overly critical. Wasn't my intent, and very much appreciate you and this entire community for maintaining this spectacular tool!