@adamhsparks Parts of the same audience which read the initial post also read its replies. The reach of such a reply is likely X times higher than opening an issue in the repo in question telling the author to avoid creating an island solutions which already exists (on top I was on the phone while reading your initial post).

(And before somebody points out the obvious: Yes, I know that codeberg-cli allows setting a custom base url. But that isn't a feature but makes the case even worse imo).

"Coming at you" feels like a strong wording here. I didn't want to offend you in any way. There must be a way to express such opinions and have a SM reality that isn't only composed out of likes and agreement in 99% of all posts and replies.

I am aware that I have a more "direct" wording than others but that's just how I am.

@adamhsparks this is an island solution that isn't needed and shouldn't be promoted imo. There is https://codeberg.org/forgejo-contrib/forgejo-cli which is instance agnostic.

Codeberg is only one instance of Forgejo and unless there is something super special that only applies to Codeberg, it shouldn't be used as as synynom.

Phrasing Codeberg as if it would be Forgejo is the same issue as people saying "I did in RStudio" when they actually meant "R".

@TheTomas Ah, cool! Sicher eine gute Sache!

Du kennst es vermutlich schon aber im Sinne der Vollständigkeit: hier der Link zur offiziellen Collection: https://codeberg.org/forgejo-contrib/ansible

#ansible #forgejo

@TheTomas
Ja, aber genau das ist ja das Problem: Ansible und andere Tools sind nicht "Enterprise". Sie funktionieren lokal/im homelab genau gleich wie im Unternehmen. Und genau da von Anfang an mit den "richtigen" Dingen anzufangen ist der Schlüssel. Dann fühlen sie sich auch eher wie der "Standard" an und eben nicht wie das Tool, was nur im "Expertenunternehmen" genutzt wird.

Ich stimme dir zu, dass man in das "Automationsdenken" kommen muss. Aber Leute sind eben so, dass sie gerne mit dem Weitermachen, mit dem sie mal angefangen haben, und nicht gerne wechseln. Und daher ist eines der Hauptprobleme (in Unternehmen), genau dieses Denken zu ändern und zu vermitteln, dass man bash eben idealerweise nicht für solche Dinge nutzt. (Ansible und bash sind hier nur zwei plakative Beispiele jetzt). Und ich glaube eben schon, dass solche Posts, die ja super nett und hilfreich (gemeint) sind, dann als "valide" Referenz gesehen werden und eben (lange) weitergetragen werden.

Ich bin bei solchen Posts immer hin-und-her gerissen zwischen der guten Intention und dem Fakt, dass dabei non-best practice Lösungen gepusht und geteilt werden, die langfristig falsche Ansätze bewerben (und nein ich habe keine spezielle Beziehung zu Ansible, es war nur ein Beispiel hier).

Meine Antwort/Meinung mag sich jetzt sicherlich unangenehm anfühlen und ich nicht gerade sympathisch dabei rüberkommen, aber ich finde, dass es solche Meinungen und Posts braucht um ggf. mal ein Umdenken einzuleiten. Gerade weil mit AI "coding" einfacher wird/geworden ist, werden "best practices" (von Beginn an) wichtiger denn je.

@TheTomas Naja, aber dann sollen sies gleich lassen bzw. man ignoriert es besser direkt.

Ich verstehe schon deinen Gedanken, aber am Ende resultiert dann aus initialer Faulheit/Unvermögen eine "öffentliche", nicht-gute Lösung (sogar mit Blog post), die nur zu mehr Problemen führt und dann als impliziter Standard bzw. Lösung gesehen wird, auf die ggf. sogar noch verwiesen wird.

So kommt man nie auf einen (besseren) Weg mit Qualität.
Es geht da auch nicht drum, ob diese Lösung dann praktisch funktioniert, sondern dass es vom Ansatz her falsch ist und bash (scripting) einfach keine Sprache ist für saubere DevOps Praktiken.

@TheTomas Ansible/Helm und andere ähnliche Automatisierungs Tools existieren, um die Erstellung individueller "reinvent the wheel" Update Skripte zu verhindern.

Das Werben solche Skripte zu nutzen führt langfristig zu mehr Problemen, als es hilft.

Since @WoodpeckerCI decided to delete comments of mine now in their repo issues, I'll share the info here once again:

If you need HashiCorp Vault/Openbao integration, #crowci got you covered in v5.1.0.

#woodpeckerCI #crowci #foss

#crowci 5.1.0 just released.

Highlight: external secret store integration! Every user can create an integration and define which users/repos are allowed to use it.

Starting out with Hashicorp Vault / Openbao. Azure KeyVault is planned.

Let us know which other secret stores are of interest to you!

https://crowci.dev/v5-1/usage/integrations/#hashicorp-vault--openbao-configuration

#crowci #codeberg #codefloe #foss

#forgejo (dev) folks: I'd like to draw your attention to two QOL PRs which are pending since some days and could use feedback/reviews to proceed further:

- "granular repository watch notifications " (https://codeberg.org/forgejo/forgejo/pulls/10598)
- "highlighted word wrapping in editor" (https://codeberg.org/forgejo/forgejo/pulls/10561)

Just released v5 of #crowci - a hard-fork of #woodpeckerci

Many hours of work went into this new release, which looks and (almost) feels like an entirely new application!

Besides a fully refactored UI, docs were migrated to #astro #starlight (https://crowci.dev/).

The new version includes many bugfixes and QOL improvements, which you might have come across in older versions (or in Woodpecker):

- Restarting failed pipelines resources metadata, so you can fix your secret conditions and actually rerun a workflow
- Bulk-delete for cron, secrets, registries
- Global cron/secrets/registry views
- Autoscaler UI integration
- New metrics panel with both table and charts view
- Support for multiple UI themes
- Auto-follow steps within a workflow as they proceed
- Conditions within "Deployment" runs (environment, task) actually take effect now
- Highly improved agent re-connection behaviour when server restarted/was unavailable shortly

If you find some bugs or just wanna say thanks, please do so at https://codeberg.org/crowci/crow.

NB: Crow will soon move to @codefloe

#codeberg #codefloe

@mapache @badgefed

If you need (unlimited) private repos, check out @codefloe

Alpine 3.23 #rstats binaries are now available at https://rpkgs.com.

Subsequently, 3.21 entered EOL. Binaries will continue to be built until 3.24 has been released.

#matrix folks running #dendrite : If you want to enable sliding sync (MSC4186) in your instance (which enables you to use Element X), have a look at this issue and the linked PR:

https://github.com/element-hq/dendrite/issues/3236#issuecomment-3508685172

Feedback and general contributions are welcome/needed to keep Dendrite alive!

@stfn otherwise I likely wouldn't have made that claim 🙂

@stfn If you want a Woodpecker-with-less-bugs developed on a Forgejo instance, have a look at https://codeberg.org/crowci/crow ;)

In case you have been using @OpenCloud on Kubernetes, you might have noticed that they archived the (community) helm chart a few weeks ago due to "low quality contributions (from AI)".

Without any comment about this action: here is a forked version of the chart (with no changes yet) to move forward:

https://codefloe.com/devxy/helm-opencloud

#opencloud #helm #kubernetes

@sheogorath I don't see any reference in the docs that relate to charges for CI. Can you please provide proof for this statement?

@preya @hannsr used that before for some time. I even built arm64 images for some time for it.

pgautoupgrade seems easier to use and closer to common usage patterns. It has seen proper maintenance for a while, so it might hopefully be on a solid path moving forward.

And if not it's not a big issue either. All of primarily does is to get major upgrades right by automating the semi-manual intermediate steps.

@preya @hannsr

https://github.com/pgautoupgrade/docker-pgautoupgrade

Did several major upgrades through that, no issues so far.

Decided to upkeep (Alpine) R images on #dockerhub instead of enforcing to use (self-hosted) #harbor registry.

Main reason: user discovery and convenience, even though I would not recommend using DockerHub to anyone these days anymore after their recent rate-limit and pricing changes in 2025.

FYI: Alpine 3.23 currently building.

https://hub.docker.com/r/devxygmbh/r-alpine

#devops #container #rstats