Storehouse will be used to manage my public facing software archives.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
David Sugar eb3e403285 Package builds and handling (#5) 4 months ago
.make Cross-builds and build type (#4) 4 months ago
cmd/storehouse Improve make and docker builds (#1) 5 months ago
lib Initial commit 6 months ago
.gitattributes Initial commit 6 months ago
.gitignore Initial commit 6 months ago
CHANGELOG.md Package builds and handling (#5) 4 months ago
Dockerfile Improve make and docker builds (#1) 5 months ago
LICENSE.md Initial commit 6 months ago
Makefile Cross-builds and build type (#4) 4 months ago
README.md Initial commit 6 months ago
go.mod Improve make and docker builds (#1) 5 months ago
go.sum Improve make and docker builds (#1) 5 months ago

README.md

About Storehouse

Storehouse will be used to manage my public facing software archives. It will eventually include a news feed, an api to test for detecting updated releases, and other software release related tools. I also will use it as a reference for other go related work.

Installation

Make "install" is sufficient to install these tools and daemons 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.

Docker and Podman

Storehouse is usable both stand-alone and in a container. The definition for building a storehouse container is a multi-stage Dockerfile which also compiles directly from the current "HEAD" of your git checkout. There is a special ``docker-images'' target to produce a container automatically for you. The Dockerfile automatically stages all development tools and dependencies as well. You can build storehouse and run it in a container with just git and docker (or podman) without requiring any development environment to be setup.

The primary goal of containerization was to make it easy to reliably build, test, and deploy storehouse directly from oci containers, such as for use on MicroOS, Kubernetics, etc. Another goal is to make it easier for anyone to participate in storehouse development.

Participation

Storehouse 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. Many of these special targets are standardized in the .make directory.

Support

Support is offered thru https://codeberg.org/dyfet/storehouse/issues. When entering a new support issue, please mark it part of the support project. I also have dyfet@jabber.org. I will build release packages for Alpine Linux 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.