Skip to content
Ronja Docs

Managed in git

Some teams keep the definitions of their tables, metrics, workflows, Apps, modules and automations in a git repository, and deploy them to Ronja from there with the Ronja CLI. When a folder in a repository deploys a resource and keeps its records in Ronja, Ronja remembers which folder that is, and says so wherever someone can change the resource.

The marker

Section titled “The marker”

The page of a managed resource shows Managed in git beside its title. Hover over it to see where the resource is declared:

  • Repository: the address of the repository the folder lives in. A repository deployed from a computer with no git remote is named by its directory, marked “(local, no git remote)”.
  • Folder: the folder’s path inside that repository.
  • File: for a table, a metric or an automation, the file in that folder that declares it. A workflow, an App or a module is a whole folder, so it shows no file.
  • Stack: the name of the deploy target that deploys it.

Under them the popover reads: “A repository deploys this workflow. You can still edit it here, but the repository’s next deploy may refuse or overwrite your change unless its owner adds it to the repository.” It names the kind of resource you are looking at.

A resource that no repository manages shows no marker.

You can still change it

Section titled “You can still change it”

The marker is information, never a lock. You, a colleague or Ronja can still change a managed resource: edit a workflow’s code, rename a table, change an automation’s schedule. You publish the change the same way as anywhere else.

What changes is what happens next in the repository. Its next deploy finds that the resource no longer matches what the repository last deployed, stops, and reports the difference as drift, rather than writing over your change without a word. Whoever looks after the repository then does one of two things:

  • Adds your change to the repository. One command, ronja <kind> pull (for example ronja wf pull for a workflow), writes what is live into the repository’s folder and shows the difference. Once they commit it, the repository and Ronja agree again, and the next deploy changes nothing. If the repository has a change of its own to that resource that it hasn’t deployed yet, the pull stops rather than replace it, and the owner combines the two.
  • Deploys over it on purpose. Your change is then overwritten by what the repository holds.

So before you change a managed resource, consider asking the repository’s owner to make the change there instead. If the fix can’t wait, make it here and tell them, so they can pull it.

When Ronja changes one

Section titled “When Ronja changes one”

When Ronja changes a managed resource in a chat, the result of that change tells her that the resource is managed in git and by which repository. That way she can point you to the repository, but she is never stopped from making the change you asked for. Reading a managed resource, without changing it, tells her nothing extra.

From the CLI

Section titled “From the CLI”

When you clone, push or publish a managed resource from a folder of your own with the Ronja CLI, the command still does what you asked, and prints one line naming the repository, folder and stack that deploy it, and the ronja <kind> pull that takes your change in there. With --json, the same is in a managedInGit list. The folder that manages the resource prints nothing.

From the API

Section titled “From the API”

Reading one table, metric, workflow, App, module or automation by its ID over the API returns a managedBy object when a repository manages it. The object names the repository and folder (sourceLabel and folderID), the file (address), the stack (stackLabel) and the feature the stack deploys to (featureID). A resource no repository manages has no managedBy object.

Section titled “Related”