aurci and aurci2 serve the same purpose: Build AUR packages automatically and provide them in a way that they can be installed by pacman.
Unfortunately, aurci was very hard to maintain, because the codebase was hard to understand. aurci2 tries to provide the same functionality but with improved readability and maintainability. (And add functionality that was missing in aurci -- but in there hard to introduce because it was not clear where/how.)
- Be explicit rather than implicit -- don't rely on defaults and environmental variables but state the intent by using the appropriate flags and passing the appropriate variables.
- Use less obscure syntax (e.g. do not use heavily nested bash commands and special bash features -- for a bash-pro this is probably more understandable, but not for the "normal" developer)
- Clearly devide the "stages" of building packages into preparation (within Dockerfile -- could potentially be cached) and (re)build (within CMD bash script).
- Use a framework (github actions) rather than writing plain bash code.
By chosing a framework that allows for more abstraction and structure, it is possible to write aurci2 much cleaner.
It for example allows to
- clearly define interfaces in the form of an action.yaml.
- factor out common functionality:
- Provide an action that allows to delete a release
- Provide an action that builds AUR packages
- The common functionality can be shared with others and can be easily documented.
- use functionality provided by others, e.g. softprops/action-gh-release to provide the release.