Nests
Self Hosted Mini Repositories for Soar
Developers
Workflow
This will publish (mirror) your release on ghcr & add a new release tag
soar-nest
to your repositoryThe
soar-nest
release tag contains JSON metadata which soar uses to start ingesting your repository as a Nest.
Add something like this to your release pipeline or as another workflow
Check for the
soar-nest
release tag (It is marked as a Pre-Release)Update your README to include a one-liner
Branding
There's hardcoded stuff related to pkgforge, like filepath & some links.
The filename/paths should be harmless and are present only in CI, not the final artifact
However the api-urls, can't be removed as it is needed & used by soar-core. Fallbacks are automatically used in case our api-urls ever die, so this is also harmless.
Finally, there's some branding in the logfile, To disable banners in logfiles, set
banner:
false
Security
By default, if you use our official workflows, you are pulling in code from our repos & then executing them on your repo with some over privileged perms. This is fine if you trust us not to do anything bad.
However, if you want to be extra careful, these mitagtions will help reduce any potential impact in case of incidents:
Always use the workflow on github actions with github''s own JIT, so they would be generated & expired automatically.
Additionally, rather than using pkgforge/soarpkgs/.github/workflows/matrix_builds.yaml@main , audit our code, and then hardcode it to a particular commit hash pkgforge/soarpkgs/.github/workflows/matrix_builds.yaml@${SHA}
Additionally, separate your project's official project repo and soar's nest repo into two different repositories, so the token would have access to only soar's nest repo, not to your whole project
Additionally, read our code, and then rewrite it by yourself, on your own repo & run it on your own infra
Quirks
Nests won't work on forked repos because github needs it to be a real (detached) repository in order to push packages associated with that repo to ghcr.
Setup time for a build job can be as high as 10 minutes, this is because the runner needs to be able to handle any & all scenarios. This is intentional, as developers can use any build tool or even docker/podman without having to specify install deps in the SBUILD itself. However, if the sbuild only needs curl/wget, the runner will still go through the whole setup phase. Currently there's no solution for this problem, we thank you for your understanding & welcome any ideas over at: soarpkgs/discussions
Users
Last updated
Was this helpful?