This might not be an issue because the branch created will have the same name, but I don't know exactly how everything will play out.

They should be put in a separate repo where they are rebuilt Monday morning (the Arch images are built Sunday) and on any changes.

This reddit post brings up a good point. Updates from GitHub aren't vetted before building and pushing.

It isn't an automated solution, but if the Action that checked GitHub for updates also put a link to the release page, code could be more easily vetted to ensure that upstream isn't introducing any obvious, malicious code.

I think it would be nice if the comment that gets posted after every build had a little header that resembled the following:

Build Results

If the PR looks good to merge, apply the lgtm label to the PR.

I'm not sure how this can be easily done, but it would be nice if the old build result comments got hidden for being outdated when GH Actions finishes a new build.

Right now the manual tests (as defined by the .aurmanifest.json) run in the same environment that built the package in the first place. Any make-depends packages are still available when they aren't guaranteed to be on a fresh install.

A possible solution is to upload the .tar.zst file as an artifact that can be downloaded in a new docker step to have the manual test command run.

Running namcap against the built Ngrok package produces an error referencing the fact that we aren't putting the license text in the package to be installed even though we declare that Ngrok has a custom license. example

This should be as simple as adding another file that gets copied to the licenses directory when building the package.

When the bot comments the build results, its lines should different than the programs it is calling.

Prepending lines with [AutomatedAUR] should be enough to make it easy to figure out where a line comes from.

Another option is to use quote blocks or code blocks to show program output separately from the bot's output.

Quote

Code

PR #69 is currently blocked because the python-av package is an AUR package and not available on the classic repositories.

Even though it's not the most automatic of ways to handle this, the .aurmanifest.json could have a list of AUR dependencies that Automated AUR could then install with a AUR manager like Yay or Paru(just to manage any further AUR deps).

The more automatic way I see right now is just to iterate through the dependency list and cross-check them with the Pacman database to see if they are available in the default repos. If they aren't then we would assume they were AUR packages and then install them with the AUR manager.

The whole system needs to be re-thought to include AUR dependencies as first class citizens so that packages which use them can be properly supported.

In order to support this without complicating the code too much, this would replace the github type with a github-releases type and a new github-tags type. This will indicate to the package updater which method to use for a project.

ngrok uses equinox.io to handle update distribution. In order to support auto updates for any app on Equinox the package updater will need the appID, which will be located somewhere in the binary.

Whether it's inferred from modified files or set manually, the AUR commit messages should be more descriptive.