I've now upgraded my personal server to this version and things didn't exactly go smoothly. The problem is that we need to rebuild all packages (the version tracking system before was really unstable so it is replaced with this PR). As I have a rather large repository (about ~130 packages), running all the builds at the same time did overload my server and lead to timeouts in the docker communication and drove sqlite to its knees.

Unless you have a small package repository, make sure you do the following:

• Make a backup of serene.db beforehand (just in case).
• Make sure you have the newer version of the cli installed before you update the server.
• After upgrading the server image, rebuild all your packages manually, ideally in small groups:
  • You can pass multiple packages to resolve between them, e.g. serene build --gentle --resolve package-a package-b package-c.
  • Once you only have a few leftovers, you can also try building all outdated packages with serene build --all.

I will now test this build for 1-2 days and see how it goes.

@VirtCode if you merge #14 and rebase this I wouldn't mind testing this on a decently sized repo.

$ serene list | wc -l                                                                                                                                                                        
222

okay, sounds great!
Will merge the agent stuff either this evening or tomorrow, and do a rebase then.

I think I will also have a look at implementing some basic heuristics regarding the migration to the new version tracking, such that you can use them to upgrade your repo. Upgrading my repo of 133 packages was already quite a pain (to rebuild everything without overloading my server), so I don't want to imagine how it is with 222.

How about a queue system? Basically only allow a limited amount of packages to build at a time. On my previous server with HDDs I was running into frequent timeouts even while building 2 or 3 at a time (#3). This should solve almost all issues assuming the queue schedules the dependencies in the right order.

Or maybe we can use the docker resource restrictions and allow for multiple slower builds in parallel without overwhelming the host (since many packages build quite quickly). But that will definitely require some tweaking on the user side based on their hardware.

True, that's actually a great idea. With the current rewrite of the scheduler it is also pretty easy to add that I think.

Will have a look at that, but will probably be some time after christmas, am pretty busy atm.

With CONCURRENT_BUILDS the update process went quite smoothly but I have a few comments.

1. --all implies --gentle but that isn't documented or obvious from --help. Also, no way to turn it off outside of just manually listing all the packages as arguments.
2. Packages that were removed from the aur result in a cryptic could not resolve dependencies: <pkgname> as opposed to the expected aur package '<pkgname>' does not exist (404) that you get when adding a package
3. (unrelated to PR) non-devel packages (badly named) that behave like devel packages will always fail to build. Would be nice if we could manually set the devel flag to avoid the dreaded version mismatch issue. I've seen this in your to-do lists already so just pointing it out as a real issue.