WIP: Better support for remote recipes #870

2026-06-16T19:46:46Z

ineiti commented

2026-06-16 19:46:46 +00:00

This PR allows to directly add remote recipes with abra:

abra app new <git-url>

The following syntaxes are supported:

git@domain/path
https://domain/path
domain/path

It adds a line

RECIPE=<git-url>

to the .env file of the app, and also uses that line to fetch the remote repo, so you can use the same configuration on multiple computers. Our use-case is to have a configuration for our servers, put that configuration in git, and use it on several developers machines.

This is a first draft PR - "it works on my machine". But if somebody else can test it and tell me if it's useful to them, and it works, I would be very happy!

This PR allows to directly add remote recipes with abra: ``` abra app new <git-url> ``` The following syntaxes are supported: - `git@domain/path` - `https://domain/path` - `domain/path` It adds a line ``` RECIPE=<git-url> ``` to the `.env` file of the app, and also uses that line to fetch the remote repo, so you can use the same configuration on multiple computers. Our use-case is to have a configuration for our servers, put that configuration in git, and use it on several developers machines. This is a first draft PR - "it works on my machine". But if somebody else can test it and tell me if it's useful to them, and it works, I would be very happy!

decentral1se commented

2026-06-16 22:21:53 +00:00

Ah, given toolshed/organising#678 (comment) @ineiti, can you confirm if the changes you're submitting are llm generated? Was that also the case for #855 and #869?

Ah, given https://git.coopcloud.tech/toolshed/organising/issues/678#issuecomment-35636 @ineiti, can you confirm if the changes you're submitting are llm generated? Was that also the case for https://git.coopcloud.tech/toolshed/abra/pulls/855 and https://git.coopcloud.tech/toolshed/abra/pulls/869?

ineiti commented

2026-06-17 20:24:03 +00:00

Yes, with the following caveats:

I did review all the changes manually and made sure I understand what's happening
I am happy with the PRs #855 and #869 and tested them on my deployment, too
for this PR I'm not sure it's the best approach, this is why I added DRAFT to the title, and am asking other people to chime in

Yes, with the following caveats: - I did review all the changes manually and made sure I understand what's happening - I am happy with the PRs #855 and #869 and tested them on my deployment, too - for this PR I'm not sure it's the best approach, this is why I added DRAFT to the title, and am asking other people to chime in

decentral1se commented

2026-06-19 12:56:12 +00:00

OK, thanks for letting me know. I will wait to see what becomes of toolshed/organising#678 before taking an action here.

OK, thanks for letting me know. I will wait to see what becomes of https://git.coopcloud.tech/toolshed/organising/issues/678 before taking an action here.

ineiti force-pushed type_remote from 4578169f0a to 64da46f211

2026-07-17 13:24:54 +00:00

Compare

ineiti force-pushed type_remote from 64da46f211 to 0397443de3

2026-07-21 06:14:04 +00:00

Compare

ineiti commented

2026-07-21 06:14:27 +00:00

Just a heads-up that I'm using this on at least two installations to keep my own version of nextcloud up-to-date, and it works nice so far.

~~ineiti referenced this pull request from coop-cloud/nextcloud 2026-07-21 11:40:34 +00:00~~

Proposing a MAINTENANCE file #81

ineiti referenced this pull request from coop-cloud/nextcloud

2026-07-21 11:41:23 +00:00

Proposing a MAINTENANCE file #81

decentral1se changed title from ~~Better support for remote recipes - DRAFT PR~~ to WIP: Better support for remote recipes

2026-07-25 11:45:26 +00:00

ineiti added 7 commits 2026-08-09 16:34:39 +00:00

fix(formatter): guard ShortenID/SmallSHA against short input 72ea3e9b2b

ShortenID and SmallSHA sliced their input to a fixed length without
checking it was long enough, panicking on shorter strings. Return the
input unchanged when it is already shorter than the cut. Also replace the
blank Commit placeholder with an explicit "unknown-commit" sentinel.

fix(recipe): reject branch names as :version with a clear error 25081d086f

Passing a branch as the ":version" suffix previously failed with an
opaque "unable to resolve" error from go-git. Detect when the requested
revision matches a branch on a configured remote and fail with a message
explaining that ":<version>" only supports tags or commit hashes.

feat(recipe): normalize git URLs to canonical host/path names e095866062

Add NormalizeRecipeName to unify the various ways a recipe can be
referenced - https/http/ssh URLs, SCP-style git@host:path, already-
canonical host/path, and short catalogue names - to a single stable
"host/path" form, preserving any ":version" suffix. Wire it into
recipe.Get and ValidateRecipe so every entry point accepts git URLs, and
add Recipe.ShortName to recover the bare recipe name from a prefixed one.

feat(app): support git-URL recipes in 'abra app new' 66253c7969

Allow `abra app new <git-url>` to use a recipe from outside the
catalogue. On clone, a `.abra-source` sidecar records the canonical
host/path name (the on-disk directory escapes "/" and "." lossily), and
IsClean ignores it. When templating the app's .env, a `RECIPE=<canonical
name>` line is injected so a later `abra app deploy`, possibly on another
machine, re-fetches the recipe from the same git source. `recipe ls` now
shows a source column listing these external recipes alongside catalogue
ones.

fix(app): keep recipe version on a single env field and label b21cf8e67f

Store the deployed version on TYPE (or the legacy RECIPE key when TYPE is
absent) instead of duplicating it across both. For git-URL recipes RECIPE
now stays a bare source pointer, so the two can never drift apart. Drops
the dead dirtyVersion branch and the fragile substring skip in
WriteRecipeVersion.

Also stamp the coop-cloud.<stack>.version label ourselves on upgrade and
rollback rather than trusting the value baked into the recipe's
compose.yml: git-URL/WIP recipes carry a stale or missing label, which
otherwise left the live deployment reporting the wrong version. Stop
getReleaseNotes and the [version] arg validation from fataling when the
deployed version is "unknown".

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Ignore .devbox 6a3c88ef8b

feat(recipe): allow branch names in RECIPE=<name>:<version> de9a683aca

Fetch and resolve a branch name on demand (into refs/remotes/origin/*,
never refs/heads/*, to avoid corrupting default-branch detection),
checking it out detached at its tip as a chaos commit. Resolution order
stays tag -> hash -> branch so existing pins are unaffected. Adds
EnsureVersionCtx so offline mode fails clearly instead of hanging or
erroring opaquely when a branch hasn't been fetched yet.

This supersedes the previous behavior of rejecting branch names with a
clear error.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y6PrSttbx61PCQTie7HzLg

ineiti force-pushed type_remote from 17c608e0ca to de9a683aca

2026-08-09 16:34:39 +00:00

Compare

Checking for merge conflicts…

This pull request is marked as a work in progress.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u https://git.coopcloud.tech/ineiti/abra type_remote:ineiti-type_remote

git checkout ineiti-type_remote

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toolshed/abra#870

Allow edits from maintainers