Add a 'test recipe' or 'local-only recipe' mode to recipes #700

New Issue

2025-10-18T18:39:49Z

cas commented

2025-10-18 18:39:49 +00:00

To support development of new recipes, a way to mark recipes as local-only or test, so they won't ever be considered for git things at all (or maybe, considered for git things but only ever local git things).

This status would have to be changeable (e.g. at the end of development to release the new recipe) and also heavily indicated in listings, and such so that there'd be no confusion on the operator's part that it's not been released.

In addition to supporting development of recipes pre-release, I believe that properly implemented this might lead the way toward multiple recipe repositories, rather than the centralized, single source we have now.

To support development of new recipes, a way to mark recipes as `local-only` or `test`, so they won't ever be considered for git things at all (or maybe, considered for git things but only ever local git things). This status would have to be changeable (e.g. at the end of development to release the new recipe) and also heavily indicated in listings, and such so that there'd be no confusion on the operator's part that it's not been released. In addition to supporting development of recipes pre-release, I believe that properly implemented this might lead the way toward multiple recipe repositories, rather than the centralized, single source we have now.

cas added the enhancement label 2025-10-18 18:53:41 +00:00

decentral1se commented

2025-10-19 10:07:43 +00:00

@cas a lot of this is already possible, I believe, but it's not well documented.

You can manually create releases (git tags) for recipes, or just abra without the --publish flag to do it. And abra will understand those local tags and show them as release targets. I am not sure this is tested and I've just set up a new laptop so cannot re-confirm right now myself.

It's already possible to completely divest from the centralised catalogue by using remote recipes in combination with abra.yml (for convenience).

For moving away from the central catalogue in a more structural way, I think we need to move towards a web API approach. The single JSON blob for the catalogue is really starting to slow abra down. Also, doing comparison operations (is this local? is this remote?) is getting more costly as the catalogue grows.

Concretely, for the ignore logic, I think you could add a ignoreRecipes: [myRecipe, myOtherRecipe] to the abra.yml which could somehow be loaded and then added at runtime into the usual Recipe struct? This would require adapting git-ops related code to check this flag then and ignore if necessary. I am not sure if this would be a big change or not.

		abra/pkg/recipe/recipe.go
		Lines 181 to 195 in 0dc5c307af
	
				type Recipe struct {

					Name          string

					EnvVersion    string

					EnvVersionRaw string

					Dirty         bool // NOTE(d1): git terminology for unstaged changes

					Dir           string

					GitURL        string

					SSHURL        string

					ComposePath   string

					ReadmePath    string

					SampleEnvPath string

					AbraShPath    string

				}

Hope this helps.

@cas a lot of this is already possible, I believe, but it's not well documented. You can manually create releases (git tags) for recipes, or just `abra` without the `--publish` flag to do it. And `abra` will understand those local tags and show them as release targets. I am not sure this is tested and I've just set up a new laptop so cannot re-confirm right now myself. It's already possible to completely divest from the centralised catalogue by using [remote recipes](https://docs.coopcloud.tech/operators/handbook/#remote-recipes) in combination with [`abra.yml`](https://docs.coopcloud.tech/operators/handbook/#configure-abra-with-abrayml) (for convenience). For moving away from the central catalogue in a more structural way, I think we need to move towards a [web API approach](https://git.coopcloud.tech/toolshed/almanac). The single JSON blob for the catalogue is really starting to slow `abra` down. Also, doing comparison operations (is this local? is this remote?) is getting more costly as the catalogue grows. Concretely, for the ignore logic, I think you could add a `ignoreRecipes: [myRecipe, myOtherRecipe]` to the `abra.yml` which could somehow be loaded and then added at runtime into the usual `Recipe` struct? This would require adapting git-ops related code to check this flag then and ignore if necessary. I am not sure if this would be a big change or not. https://git.coopcloud.tech/toolshed/abra/src/commit/0dc5c307af6783ef3220a5006f98972011dd4ca8/pkg/recipe/recipe.go#L181-L195 Hope this helps.

decentral1se added question design and removed enhancement labels 2025-10-19 10:08:50 +00:00

cas commented

2025-10-20 21:04:09 +00:00

Thank you for this information!

The ignoreReucipes idea is a good one, if I get some abra hacking time I'll try to look at it.

Thank you for this information! The ignoreReucipes idea is a good one, if I get some abra hacking time I'll try to look at it.

👍 1

p4u1 commented

2025-10-24 07:08:23 +00:00

I actually explored local recipes a while back and have a prototype laying around somewhere!
It works by setting

RECIPE=./my-local-recipe

It then ignores every got operation and just treats it like a nor all folder. This allows you to track the files in the same git repo as your app configs. If you are interested I can push my code and you can have a look at it

I actually explored local recipes a while back and have a prototype laying around somewhere! It works by setting `RECIPE=./my-local-recipe` It then ignores every got operation and just treats it like a nor all folder. This allows you to track the files in the same git repo as your app configs. If you are interested I can push my code and you can have a look at it

👀 1

decentral1se commented

2025-10-26 10:54:24 +00:00

Hell yes @p4u1, please do push that code up somewhere!