Remote Caching with bobc
bobc is an open source implementation of a remote artifact store for bob. It is a subset of the Bob Build Platform (https://bob.build), and lets you manage your projects and their artifacts. Bobc lacks complex features like fine-grained authorization controls and a web-based user interface. However, it is a valuable resource since it allows you to evaluate the bob caching features on your own infrastructure, without committing to using the cloud platform.
Setting up bobc locally
bobc is packaged as a docker image and can be run locally along with its dependencies (Postgres & MinIO) in a docker-compose environment.
In order to build the bobc container, you need the following dependencies present in your system:
- Bob with Nix (https://bob.build/docs/getting-started/installation/)
- Docker (https://docs.docker.com/get-docker/)
Building the container
First, clone the GitHub repository and cd
into it:
git clone https://github.com/benchkram/bobc
cd bobc
Now, let's build the containter:
bob build container
Starting the environment
Authentiction
Authentication on bobc is done using a static API_KEY, which can be configured when the docker-compose environment is started. Bob will later use this key to authenticate with bobc and push artifacts to it.
Starting the docker-compose environment
export API_KEY=api-key
docker compose up -d
You can verify bobc has started by opening http://localhost:8100/api/health
Note: MinIO at localhost requires a host alias to be set up in order to work properly.
You should add the following to your /etc/hosts
file:
127.0.0.1 minio
Creating a project
bobc does not bundle a web interface, so we have to interact with the REST API in order to create a project.
To do so, open a new terminal session and use the following curl command:
export PROJECT_NAME=bobc-example
curl -X POST http://localhost:8100/api/projects \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $API_KEY" \
-d "{\"name\": \"bobc-example\"}"
This will create a project named bobc-example
.
Syncing artifacts
Setting up an authentication context
Next, you should configure an authentication context for bob. We'll pass the API_KEY as bearer token to the auth init
command.
bob auth init --token=$API_KEY
Verify artifact sync is working
You can utilize the example
bob project present in the bobc repository to test the artifact sync.
The example directory includes a bob.yaml that builds a simple Go binary and then packages it into a Docker container.
The example bob.yaml also includes a project
directive that specifies the remote URL:
# "project" here in the scope of bobc could be anything. It is not checked. However,
# it is required to be passed to maintain compatibility with bob and its OpenAPI contract.
localhost:8100/project/bobc-example
You can verify artifact sync is working by typing:
cd example
bob build --insecure --push
You should see that bob successfully pushed some artifacts to bobc.
We have to use the --insecure
flag since bobc is running over HTTP by default locally. We also pass the --push
flag to instruct bob to attempt to push artifacts to bobc, as bob does not push artifacts upstream by default.
Now, if we try to clean the local artifact cache and then try to re-build, the artifacts should be pulled from bobc, leading to a much faster build time.
bob clean system
bob build --insecure
You should see in the output that all build targets were cached
.