2026-09-13: New Crow CI workflow examples & Container Package Cleanup tutorial

We have added a variety of new workflow examples for Crow CI. These originated out of our own daily use and aim to inspire you to potentially enhance your CI/CD game.

The new ones are:

Name What it does Runs on
[Docker] buildx publish via QEMU and caching Multi-platform publishing with a registry layer cache Default-branch push, v* tag
[Docker] Multiple registries Publish one build to two registries with separate credentials Default-branch push, manual
[Docker] Native multi-platform builds Separate AMD64 and ARM64 agents followed by a manifest merge Default-branch push, v* tag
PR changelog Generate notes for commits introduced by a PR PR
Repository release Create a Forgejo release with notes, a source archive, and checksums Default-branch push, manual
S3 assets Upload an archive and checksums under a repository/version prefix Default-branch push, manual
Rust with sccache Cache compiler output in S3 and run Cargo builds and tests PR, default-branch push
prek Run repository hooks and show formatter diffs PR, default-branch push, manual
golangci-lint Lint all Go packages PR, default-branch push, manual

If you have a cool workflow that is somewhat generic and could be useful for others - PRs welcome!

(Container) package cleanup

Did you know that you can save a lot of space by creating a cleanup rule for you (container) packages?

Cleanup rules can be added for all package types offered by the internal Forgejo registry. We’ve added a docs page to the “Usage” section to showcase their use, including a practical complex regex that allows you to cleanup all “non-important” tags when you’re using a semver-based publishing scheme.

While the tutorial tackles container packages specifically as these are the most used ones and take the most space, the general approach applies to any other package type.

Check out the tutorial here: Container Package Cleanup | CodeFloe

4 Likes

If you’re open to requests, one I’d love to see documented or supported better is Nix builds. I’m waiting for NixCI to add native support for arbitrary Forgejo instances, but in the meantime, I’m using CrowCI as kind of an orchestrator for nix builds and using either NixCI or nixbuild.net for the actual build jobs.

One thing that would make this flow smoother is the ability to persist the Nix store locally in the cache so it doesn’t have unconditionally build or pull from the external builders.

Please open a thread for this in the CICD category so it can be discussed as a standalone feature request.