|
||
---|---|---|
.make | ||
.vscode | ||
cmd/apollo | ||
etc | ||
lib | ||
web | ||
.gitattributes | ||
.gitignore | ||
.woodpecker.yml | ||
CHANGELOG.md | ||
CONTRIBUTING.md | ||
LICENSE.md | ||
Makefile | ||
README.md | ||
TODO.md | ||
go.mod | ||
go.sum |
README.md
What is Apollo?
Apollo offers a web administrative console and web integrated telephony services for a Coventry phone system. It is the point of network api contact, and provides additional client support services, such as rosters and dialing directories for coventry specific endpoints like partisipate. Apollo requires and suppliments an install of Coventry to be at all useful.
Installation
Make "install" is sufficient to install the Apollo integration server on a generic posix system. This installs to /usr/local by default, and can be overridden with a PREFIX setting, such as ''make PREFIX=/usr install''. The Makefile also makes it easy to cross-compile, as well as managing separate debug and release builds. It also should be easy to integrate with traditional OS packaging.
In git checkouts I manage a vendor directory outside of git. This is because it may generate different content when you update the go.mod file. Generating a vendor branch means it also can get into the stand-alone dist tarball, and that can then be used in network isolated build systems. Since the builds are cached anyway without a vendor directory, this has no impact on performance. The vendor directory is only refreshed if the go.sum file changes.
Participation
Apollo is written in Go. I use go modules support, so this project can be cloned into any stand-alone directory and built there. I also use a front-end Makefile to simplify builds and offer basic project automation.
My Makefile includes a "dist" target, which produces a stand-alone tarball that
can then be used to build install the tools detached from the repo. This is
particularly useful for OS packaging. I include a "lint", "test", and
"coverage" target to test and verify code. The default make builds binaries in
target/{build-type} in a manner like rust cargo does, where they can then be
tested. Cross-compiling goes into target/{GOOS}-
{GOARCH}. Many of these
special targets are standardized in the .make directory.
Support
Support is offered thru https://git.gnutelephony.org/apollo/issues. When entering a new support issue, please mark it part of the support project. I also have dyfet@jabber.org. Apollo packaging build support for some GNU/Linux distributions may be found on https://pkg.gnutelephony.org/apollo. I also have my own build infrastructure for Alpine using ProduceIt, and I publish apk binary packages thru https://public.tychosoft.com/alpine. In the future maybe other means of support will become possible.