- Nix 100%
| .gitignore | ||
| container.nix | ||
| flake.lock | ||
| flake.nix | ||
| README.md | ||
Goal
Have reusable Forgejo actions that can:
- Eval and build Nix some attributes of Nix flakes
- Push NixOS configuration to target machines
- Have some MRs tagged that regularly upgrade flake.lock (say, keep a MR open to upgrade to the next NixOS release)
- Re-create a MR for just updating flake.lock and nothing else (using above mechanism)
Considerations
Interacting with the Forgejo API
-
https://codeberg.org/forgejo-contrib/forgejo-cli: is definitely made for humans so nope.
-
https://codeberg.org/harabat/pyforgejo: Up to date, but not in nixpkgs
-
Whatever GitHub action uses: Would allow reusing a few things, but also it's NodeJS, mostly made for GitHub, and probably overkill
Docker or host runner
-
Host runner doesn't have the all the depedencies that might be needed for actions, they would need to be added to the runner environment.
-
Could make a Docker image with everything (and can be generated from itself too), but it needs a system/credentials to use morton as a remote builder/substituter.
Reusable actions / generate them
-
We can make use of Forgejo reusable actions. If we change something in there it would also be updated in user repos (I think).
-
Could also use https://github.com/synapdeck/github-actions-nix/ so we would import this repo as a flake and use it to generate Forgejo actions.
Pros:
- Don't need to use Forgejo Action matrices/reusability system
- Could also use the same system to run custom actions from a host builder.
- Better versionability/reusability
Cons:
- Require using flake.parts for each repo
- Puts build artifacts in the repo