Refactored the recipe in preparation for a v1 release.
Changes:
Added .drone.yml (maybe a little silly at this point since it's a cronjob, so it doesn't actually execute, but I guess at least it'll validate the config)
Added .env.sample and .abra.sh
Removed the config.js file. Since Abra does all config via environment variables and most all Renovate config is controllable by env vars already, I figured this would be simpler.
Expanded secrets to cover a github token and an npm token. These optional secrets are implemented via dedicated compose files, since otherwise abra won't let you deploy without setting all secrets.
Added entrypoint, which is needed to export the the secrets to env vars
Expanded readme
Refactored the recipe in preparation for a v1 release.
**Changes:**
- Added .drone.yml (maybe a little silly at this point since it's a cronjob, so it doesn't actually execute, but I guess at least it'll validate the config)
- Added .env.sample and .abra.sh
- Removed the config.js file. Since Abra does all config via environment variables and most all Renovate config is controllable by env vars already, I figured this would be simpler.
- Expanded secrets to cover a github token and an npm token. These optional secrets are implemented via dedicated compose files, since otherwise abra won't let you deploy without setting all secrets.
- Added entrypoint, which is needed to export the the secrets to env vars
- Expanded readme
Tested this out by deploying it on my own server and pointing it at mealie, which seemed to work: coop-cloud/mealie#2
After merging and running again, it created a dependency dashboard, showing it detected some deps automatically: coop-cloud/mealie#3
Tested this out by deploying it on my own server and pointing it at mealie, which seemed to work: https://git.coopcloud.tech/coop-cloud/mealie/pulls/2
After merging and running again, it created a dependency dashboard, showing it detected some deps automatically: https://git.coopcloud.tech/coop-cloud/mealie/issues/3
I know it's tempting to ditch the secrets but this will force every operator to make their renovate configurations private because they have tokens in their env configuration. i think we should keep them and use an entrypoint to expose the secret, using our usual age-old hack, e.g.
echo >&2 "error: both $var and $fileVar are set (but are exclusive)"
exit 1
fi
local val="$def"
if [ "${!var:-}" ]; then
val="${!var}"
elif [ "${!fileVar:-}" ]; then
val="$(< "${!fileVar}")"
fi
export "$var"="$val"
unset "$fileVar"
}
file_env "PEERTUBE_DB_PASSWORD"
file_env "PEERTUBE_SECRET"
I know it's tempting to ditch the secrets but this will force every operator to make their renovate configurations private because they have tokens in their env configuration. i think we should keep them and use an entrypoint to expose the secret, using our usual age-old hack, e.g.
https://git.coopcloud.tech/coop-cloud/peertube/src/commit/2744684292d66053a9681ac57692b9f026863dde/entrypoint.sh.tmpl#L5-L28
Ah I see now, abra.sh is only for config versions.
The only way I could see to create optional secrets is to have each secret be in its own COMPOSE_FILE, which is what I've now implemented.
Ah I see now, `abra.sh` is only for config versions.
The only way I could see to create optional secrets is to have each secret be in its own COMPOSE_FILE, which is what I've now implemented.
Can we configure also the assignees via env var? I really would like to have that for when we implement maintainers and we can ping specific handles. that would be ideal. otherwise, pretty good with ditching this file if possible!
Can we configure also the `assignees` via env var? I really would like to have that for when we implement maintainers and we can ping specific handles. that would be ideal. otherwise, pretty good with ditching this file if possible!
Pretty sure it's a space-separated list as well. Will add a commented-out field since it's a common need.
Yep! `RENOVATE_ASSIGNEES` : https://docs.renovatebot.com/configuration-options/#assignees
Pretty sure it's a space-separated list as well. Will add a commented-out field since it's a common need.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Refactored the recipe in preparation for a v1 release.
Changes:
Tested this out by deploying it on my own server and pointing it at mealie, which seemed to work: coop-cloud/mealie#2
After merging and running again, it created a dependency dashboard, showing it detected some deps automatically: coop-cloud/mealie#3
c786b29226toe23a715a40e23a715a40todcf08cb12eamazing, tysm!
@@ -0,0 +15,4 @@## If not using autodiscover, you can supply a space-separated list of repos.## Ex: "coop-cloud/renovate coop-cloud/keycloak"RENOVATE_REPOSITORIES=""RENOVATE_TOKEN="token for your git forge"I know it's tempting to ditch the secrets but this will force every operator to make their renovate configurations private because they have tokens in their env configuration. i think we should keep them and use an entrypoint to expose the secret, using our usual age-old hack, e.g.
Hmm I see that
SECRET_SMTP_PASSWORD_VERSIONis not inabra.sh. Is that the solution for having an optional secret?Ah I see now,
abra.shis only for config versions.The only way I could see to create optional secrets is to have each secret be in its own COMPOSE_FILE, which is what I've now implemented.
@@ -5,4 +0,0 @@logLevel: "error",unicodeEmoji: false,onboarding: true,assignees: [],Can we configure also the
assigneesvia env var? I really would like to have that for when we implement maintainers and we can ping specific handles. that would be ideal. otherwise, pretty good with ditching this file if possible!Yep!
RENOVATE_ASSIGNEES: https://docs.renovatebot.com/configuration-options/#assigneesPretty sure it's a space-separated list as well. Will add a commented-out field since it's a common need.
Okay it's fixed now! Secrets implemented and tested 🫡
Incredible, thanks so much @cyrnel 👏 Merge away!