Autogit is a Bash tool to automatically build, update or install Pacman applications from PKGBUILD’s available on Github, Gitlab and AUR via configurable makepkg, devtools, or Manjaro chrootbuild commands. It can also create automatically repo names like core, extra, community and create/update a repo database file via repo-add. Additionally it clears each local repo with paccache to only keep the latest package version.
Basically if you want to avoid a “git clone” and the rest of the procedure each time a PKGBUILD has been updated and trust the source, then this tool might be for you. Here are some examples:
Auto create your own local repositories, add them to /etc/pacman.conf and update with Pacman.
Compile packages from different sources into one repository while building all in a clean “chroot”, e.g. AUR, Gitlab, Github.
Compile the same package from different branches into different repositories, or add a “-git” PKGBUILD for development on a different branch etc.
Use “makepkg” to directly install packages after compilation.
2 different options are available to compare and update applications. In case of a “-git” package it checks for the latest commit to update and can either run once or in a loop with a timer setting.
More information on how to set it up is available in autogit.conf, examples are included.
Currently the AUR, 6 Github and 6 Gitlab sources are available to use. There is no limitation of packages for each source, which need to be added to the reponames folder source files.
In sum 13 different repos can be enabled/created and will be updated together.
Autogit 0.25 was released and is considered to have stable core functionality. I’m currently running it with buildpkg 24/7 on 3 Manjaro Gitlab repos (core, community, extra) with 15 different packages plus my own Github and it seems to do it’s job fine. As always feedback is welcome, happy building!
Absolutely not, I’m glad if it’s helpful for you guys!
Thanks to @Yochanan i’ve changed some things around buildpkg, so that it now shouldn’t matter for which architecture one is building. As long as it’s set in the right place of the config the binary’s will be moved to the preset repo.
Next step is to implement up to 6 repo’s for Gitlab and Github and add a error handling in case the online source is not available.
Please let me know if there is still something missing or should be implemented!
A new release is out with added check for server availability and support for 6 Gitlab repos, which are preset to all available Manjaro repos in the config file and reponames folder.
In theory one could auto-build all manjaro software into separate local repos and repoadd should do the rest. At least in my tests with a added local repository to pacman.conf it works pretty well and the apps get updated through pacman when i run a system update.
New version is out with a massive cleaning and improvements.
removed duplicate code where possible
repoadd now only will be triggered for the specific repo when a update or new build has been done - if enabled. This should be much more resource friendly and faster if a lot repos are enabled.
Thanks for the feedback, I think your suggestion is the current state right now after implementing all the wanted functionality and a big cleaning.
I still need to improve on my comments, but the code should be in readable state - at least I hope so.
From my point of view this tool is currently feature complete as it does what it was meant to do.
Still there is one downside, which it can’t handle like a AUR helper would do for example. Building git packages is not really something it is made for, although it can do it. But as it checks for the pkgver and pkgrel it will always rebuild git packages.
This case only applies to git packages which have no “normal” versioning. There is currently no way to check the latest online version, as the online PKGBUILD refers to a older version compared to the local one. Checking the latest built package might be an indicator, but won’t solve the problem as it needs to know when a package is out of date. I will think about how to solve that case with the current approach.
This is not the current state anymore, right now it supports 6 Gitlab, 6 Github and the AUR source.
The repeating code is one single function with variables in itself to allow different parameter for all the different sources.
The most things have a default.
The Servercheck is by default off and needs to be un-commented for each server, as i have no idea who uses what.
the default settings for “buildpkg” and “makepkg” can either be used as they are, or changed to user preference.
After that the default build method shoud be set to the preferred one.
repo-add is by default off
Finally un-comment the first variable of the preferred source(s) and change the binary folder name to own preferences, that should be all for Github and AUR. If you use Gitlab you also should check the URL as it is preset to Manjaro’s Gitlab. The source filenames can also be changed to user preference in the settings, but also need to be renamed in the reponames folder.
Basically everything that is in the settings, can be changed for each source.
The sources files in the “reponames” folder are interpreted line by line - for each application one line. Expressing them in one line would lead to a whole new complexity in order to read them accurate. Also as this are all independent packages which can have different Github sources etc., it would be hard to keep an overview and to not make mistakes when adding/deleting packages.
Yes and yes
The AUR can be seen as any other source. The URL itself shouldn’t normally be touched as long as it doesn’t change.
That is currently not possible other than manually splitting sources to different machines, but a nice idea that i will think about.
, something to look at 
