If you’re using my automatic update script, you might find this new version useful. As always, the script is located at https://pastebin.com/j657uv9A
However, please be sure you go over the README at https://pastebin.com/nwcSH0TH
So what’s the new functionality? In short, it should now be completely hands-off provided everything is setup correctly. You shouldn’t have to edit any lines whatsoever, and it should “just work.” And as of Invoice Ninja v4.3.0, it will attempt to delete
/bootstrap/cache/compiled.php if it exists (I’ll leave this in for users who may not be on the absolute latest releases and want to update later).
While I go over this next part in the README, it’s important that you know what assumptions are being made and what the caveats are.
- You have
locateinstalled. If not, you'll want to do so.
sudo apt install locate
- You have only ONE copy of the Invoice Ninja directory structure on your system (explained below).
- You have sudo access, either to run the script manually, or to run it as a cron task.
- The partition containing
/usr/local/has enough space to store the downloaded ZIP file, as well as to extract the files prior to having them synced to your install folder.
So what are the caveats?
For starters, the script uses
locate to search for a specific composer.json that resides in the Invoice Ninja root directory. This is how it knows where you have IN installed. If there are other copies installed on the same system (or even just the files extracted somewhere),
locate will return multiple paths, and cause problems. That’s another reason to be 100% sure you have full read/write access to the /usr/local/ folder, as we want to make sure the script removes the extracted files when it’s done with them. Also, the script will run
sudo updatedb before
locate to make sure the path returned is the most up to date. This could take a few seconds on some systems if it hasn’t been run in a while. If you’re running it as a daily cron task, this shouldn’t be an issue, however.
The script will detect whether or not you’re using
UPDATE_SECRET in your .env file, and pass the proper URL to wget with the string you set. However, in some cases, wget will return a 400 error, and the artisan commands will not run. If this happens, you can simply run
wget --spider with your URL and
UPDATE_SECRET string, or visit that same URL in your browser and it will go through on the second attempt. If you have to do that, I suggest removing
UPDATE_SECRET from your .env file for now. This issue happens to me whether I’m attempting to trigger the commands with wget, curl, or any browser. Unfortunately, nobody else has reported the same issue, so I’m at a loss as to what could be going on.
Finally, if you still prefer the old version, 4.6.3 of the script has moved to https://pastebin.com/fittpgBB