OAK4 `oakapp.toml` format and syntax definition

JeremyA

Is there a guide describing fields of the oakapp.toml fields?

For example, I want to know how to convert the [base_image] for other docker image registries. For example, gitlab container registries, Azure registries, or AWS registries.

This is a good example but I'm not sure how to expand this to my use cases without a guide for the meaning of each element and relate that to my situation.
luxonis/oak-examplesblob/main/apps/default-app/oakapp.toml

Ales

Try following links:

You've found a good example, it contains all [base_image] fields we support. You just need to tweak the values to fit your needs.

JeremyA

I've seen that link but it only describes that there is a [baseimage] but doesn't describe the items within it such as service, oauth_url, auth_name, etc. Additionally, I'm not using dockerhub I need the explanation of these fields so that I can find the equivalent values for these fields for other container registries.

Ales

[base_image] items are:

api_url - Service HTTPS address (example: https://registry-1.docker.io)
service - Name of a Image Registry Service (example: registry.docker.io)
oauth_url - Address to get a OAuth 2.0 token for this service (example: https://auth.docker.io/token)
auth_type - Scope type (example: “repository”).
auth_name - Name of resource (example: “library/ubuntu”)
image_name - Image name (example: “library/ubuntu”)
image_tag - Image tag (example: "latest")

Under the hood, we use the OCI registry client library. You may find a clearer explanation of what those fields mean in its documentation.

JeremyA

Does this work with only anonymous pulls like docker? Our gitlab uses authenticated access with basic credentials - a username and deploy tokens to manage access. We have to use docker login … for our pulls.

Ales

JeremyA Does this work with only anonymous pulls like docker?

yes

JeremyA

Is there any plan to allow it to work with authenticated access?

Ales

JeremyA It's on the roadmap, but we have no ETA yet for this one.

However, it's often not necessary to have a full base image; the preferred way is to use recommended base images (either luxonis/oakapp-base or debian:bookworm-slim), which should cover most use cases. Then you can build layers on top of these using prepare_container, prepare_build_container and build_steps in oakapp.toml. This way you can utilize caching effectively (e.g., by excluding build-time dependencies from the final image).