Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.airelabs.com/llms.txt

Use this file to discover all available pages before exploring further.

The Container Functions guide ends at docker build on your laptop. This page picks up there. The goal: pushing a git tag is the only thing you do. CI builds the image, pushes it to the Aire registry, and tags it with the git tag. No manual builds, no shared credentials, no laptop in the loop. Wire this up once per project. The pattern works for any language — R, Python, Go, Node, Julia, anything you can put in a Dockerfile. You will need two things from your Aire organization: an API key and your registry hostname. Both live in Aire Studio. Open it in another tab and follow along.

​
What You Get

Once this is wired up, releasing a new version of your function looks like this:
  1. Push a git tag like v1.2.0.
  2. GitHub Actions builds the image.
  3. CI pushes it to your Aire registry under that tag.
  4. The new tag is available in any container function block in any Aire model.
No step requires you. The git tag is the version. CI is the only thing that publishes.

​
1. Create an API Key with Registry Push

Open the API Keys page under Settings. The page lists every key in the organization, with name, last-used timestamp, and creation date. Click Create API key. Give it a name that names the project — GitHub Actions — lcoe-r is a good shape. Check the Registry Push permission. That is the only permission the key needs. Copy the key when it is shown. You will not see it again. Treat it like a production credential.
Give each project its own key. Rotating or revoking one should not touch the others.

​
2. Find Your Registry Hostname

Open the Container Registry page under Settings. Your hostname is shown at the top, in the form org-<your-org-id>.airelabs.run. The page also shows the exact docker login, docker tag, and docker push commands for your organization. The workflow you are about to add runs those same commands on a CI runner. If anything ever looks wrong in CI, this page is the ground truth. Under the hostname, the page lists every repository you have pushed so far, with tag counts and last-push timestamps. After your first CI run, your new image will show up here.

​
3. Store the Key as a GitHub Actions Secret

In your GitHub repository, go to Settings → Secrets and variables → Actions. Add a new repository secret named AIRE_API_KEY, with the value you copied in step 1. See the GitHub docs on creating repository secrets for the exact UI walkthrough. That is all the workflow needs to authenticate. The secret never appears in logs and is only available to workflows in this repository.

​
4. Drop in the Workflow

The workflow file lives at .github/workflows/publish.yml in your repository. It runs every time you push a git tag. See the GitHub Actions workflow syntax reference for the full schema, and events that trigger workflows for how the tag-push trigger is filtered. On each tag push, the workflow does five things:
  1. Check out the code.
  2. Set up Docker Buildx and install regctl, a small registry client.
  3. Log in to your Aire registry with AIRE_API_KEY.
  4. Build the image to an OCI layout, pinned to linux/amd64 and tagged with the git tag.
  5. Push the image to your registry under that tag.
The full file is in the public R example: airelabsresearch/integration-language-r/.github/workflows/publish.yml. Copy it into your own repository. Change two lines: REGISTRY to your org’s hostname, IMAGE_NAME to whatever you want this image to be called.
Why regctl instead of docker push? For larger images, regctl’s chunked upload is more reliable than docker push. The example uses it for that reason. If your image is small, docker push works fine.
Apple Silicon and the --platform linux/amd64 flagAire’s runtime is amd64. An arm64 image built on Apple Silicon will fail at runtime. The workflow handles this — that is what the --platform linux/amd64 line is doing.

​
5. Cut a Release

Releasing a new version is two steps:
  1. Merge your change to the default branch.
  2. Tag the commit and push the tag:
git tag v1.2.0
git push origin v1.2.0
GitHub Actions picks up the tag and runs the workflow. The new tag appears under your repository on the Container Registry page within a minute or two. In any Aire model, switch the container function block to the new tag and you are running on the new version.
After the workflow completes, refresh the Container Registry page and confirm your new tag is listed under the repository.
Tags in the Aire registry are immutable. Once v1.2.0 is pushed, it points to that exact image forever. To publish an update, push v1.2.1 — do not re-tag v1.2.0. Models pinned to a tag keep running on exactly the image they were pinned to.

​
Any Language, Same Workflow

Everything above is about the outside of the container: the registry, the API key, the workflow. The inside — the language, the libraries, the model itself — is yours. A Python function with NumPy and SciPy publishes the same way. So does a Go binary, a Julia model, a C++ simulator. Anything that builds a working image with a Dockerfile. The Hook input/output protocol makes the inside language-agnostic. This workflow makes the outside language-agnostic.

​
Further Reading