Enhancements to abra recipe lint #685

New Issue

iexos · 2025-10-01T10:56:20Z

iexos commented

2025-10-01 10:56:20 +00:00

This is a proposal to help recipe maintainers with building and maintaining working recipes by performing a couple of checks. Once stable, it should be run at the beginning of abra recipe release to mitigate faulty releases and improve recipe quality.

The following checks I can think of that would not duplicate checks done during deployment:

assert secret names follow the convention of ${STACK_NAME}_name_${SECRET_NAME_VERSION}
assert all SECRET_NAME_VERSION=v1 are present in .env.sample (even if commented out)
assert config names follow the convention of ${STACK_NAME}_name_${NAME_CONFIG_VERSION}
assert all NAME_CONFIG_VERSION= are present in abra.sh
assert README.md contains metadata
- assert image linked metadata matches on of the images in compose.yml (mitigate documentation drift)
other checks already done could be integrated, like testing for a label like "coop-cloud.${STACK_NAME}.version=XXX"

Of course, just add anything that makes sense to you to check :)

From a technical point I am not sure if there would be a big overlap with using recipe release --dry-run and if refactoring those checks so they can be performed independently makes sense. I would be also fine with just adding as many checks as possible to the release command.

This is a proposal to help recipe maintainers with building and maintaining working recipes by performing a couple of checks. Once stable, it should be run at the beginning of `abra recipe release` to mitigate faulty releases and improve recipe quality. The following checks I can think of that would not duplicate checks done during deployment: * assert secret names follow the convention of `${STACK_NAME}_name_${SECRET_NAME_VERSION}` * assert all `SECRET_NAME_VERSION=v1` are present in `.env.sample` (even if commented out) * assert config names follow the convention of `${STACK_NAME}_name_${NAME_CONFIG_VERSION}` * assert all `NAME_CONFIG_VERSION=` are present in `abra.sh` * assert `README.md` contains metadata * assert image linked metadata matches on of the images in `compose.yml` (mitigate documentation drift) * other checks already done could be integrated, like testing for a label like `"coop-cloud.${STACK_NAME}.version=XXX"` Of course, just add anything that makes sense to you to check :) From a technical point I am not sure if there would be a big overlap with using `recipe release --dry-run` and if refactoring those checks so they can be performed independently makes sense. I would be also fine with just adding as many checks as possible to the release command.

👍 3

iexos referenced this issue from toolshed/organising

2025-10-01 11:02:13 +00:00

Improving the recipe release process #663

decentral1se added this to the Abra v0.12 project 2025-10-01 13:21:21 +00:00

decentral1se commented

2025-10-02 06:17:09 +00:00

@iexos we have abra recipe lint <recipe>, should we just extend this? It seems to have a different purpose to suggest / highlight other optional things that you might want to do as a maintainer. However, having check and lint might be confusing. And what do you think about that output format with the table? Is that necessary?

@iexos we have `abra recipe lint <recipe>`, should we just extend this? It seems to have a different purpose to suggest / highlight other optional things that you might want to do as a maintainer. However, having `check` and `lint` might be confusing. And what do you think about that output format with the table? Is that necessary?

decentral1se added the

enhancement

label 2025-10-02 09:11:15 +00:00

iexos commented

2025-10-06 10:15:37 +00:00

Ah, I didn't know about recipe lint. Thats cool! Then we could simply add the suggestions above to that one :) I don't see a benefit in splitting checks/lints.

I added an issue for the docs: toolshed/docs.coopcloud.tech#288

I think the default output format of recipe lint should only show unresolved issues (even though its nice to have a lot of green check marks 😄) especially if more rules are to be added. Having an option to show all rules is nice, but not sure if really needed.

Leaves me with the question if and how this should become better integrated into the release process. Documentation changes are a start, for a future CI integration and catalogue enhancements it could become an indicator for recipe stability. But maybe this is out of scope for this issue? (I still have to learn smth about scope discipline 😅)

Ah, I didn't know about `recipe lint`. Thats cool! Then we could simply add the suggestions above to that one :) I don't see a benefit in splitting checks/lints. I added an issue for the docs: https://git.coopcloud.tech/toolshed/docs.coopcloud.tech/issues/288 I think the default output format of `recipe lint` should only show unresolved issues (even though its nice to have a lot of green check marks 😄) especially if more rules are to be added. Having an option to show all rules is nice, but not sure if really needed. Leaves me with the question if and how this should become better integrated into the release process. Documentation changes are a start, for a future CI integration and catalogue enhancements it could become an indicator for recipe stability. But maybe this is out of scope for this issue? (I still have to learn smth about scope discipline 😅)

👍 1

iexos changed title from ~~Add `abra recipe check`~~ to Enhancements to `abra recipe lint`

2025-10-06 10:15:59 +00:00

decentral1se modified the project from Abra v0.12 to Abra "next"

2025-10-26 09:50:18 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toolshed/abra#685

Enhancements to abra recipe lint #685

Enhancements to `abra recipe lint` #685