Bob supports sharing binary artifacts with alomost no additional configuration. Most importantly Bob uses implicit versioning to free the user from explicit version management that is usually required by other package building systems. Sharing artifacts requires nothing more than a shared location.
Local builds
Local file system
HTTP(S)
Jenkins builds
Custom adapters
Bob creates a fingerprint from the sources and the involved recipes to locate a matching artifact. This schema fully supports local changes of the source code, changed recipes and building from frequently pushed branches. In case of git Bob does not even need to download the source code at all to compute this fingerprint. Instead the current branch head is queried with git ls-remote which is a light-weight operation.
A typical configuration for a shared WebDAV server can look like this. First you need a nginx server or any other WebDAV capable web server. For nginx the following site configuration is sufficent:
server {
listen 80;
server_name bob.archive.test;
client_max_body_size 0;
location / {
root ...;
dav_methods PUT DELETE MKCOL COPY MOVE;
dav_ext_methods PROPFIND OPTIONS;
dav_access group:rw all:r;
autoindex on;
create_full_put_path on;
allow all;
}
}
On the Bob project side only the following lines have to be added to default.yaml:
archive:
-
backend: http
url: http://bob.archive.test/
That's all what is needed to reliably share artifacts. The functional approach of Bob will assure that a downloaded artifact is always built correctly.
The directory layout of all back-ends are compatible with each other. It is therefore possible to access the same location through different back-ends. This comes in handy if you want to restrict who can upload artifacts but still want to allow public downloads.
Store artifacts in the local file system.
A http server that supports the standard GET and (if upload is desirec) also PUT requests.
Use Microsoft Azure Blob storage for public access.
The up- and download can be done by any command too.