Discussion
@hipsterelectron @lina about cloud service and continuous integration, writingna simple self-hosted runner gave me some insight. Forgejo (software behind codeberg) is a single go binary.It's super easy to run locally. I mostly did dev my runner against my local instance. I had both the forge and the CI running locally.
That also means I can iterate in CI actions workflows locally on throwaway branches. Or run CI locally.
Sinple tools are fun :)
@hipsterelectron @gkrnours @lina I have come to boring conclusion that CI scripts should just call scripts or build system targets and do whatever little plumbing is required to surface results to the CI/metrics that you want. If this means having a top-level Makefile in a project that wouldn’t normally have a Makefile and that Makefile just has the different stages of the format-lint-build-analyze-test chain, that’s fine.
@c0dec0dec0de @gkrnours @lina i hate the make invalidation model so much lmao but i suppose that only really matters for builds of larger projects
@hipsterelectron @lina while I agree, I don't think that's the main benefit of a CI. I want a CI to package my python toy so there is clarity on how packaging is done. For other if they are curious as a bonus but mostly to me if I come back to the project in 6 or 18 months.
A CI is a proof it worked once. It's not like a readme that could have typo or worse with less scrupulous code bro.
@hipsterelectron @lina I do basic python so I don't have a build step. I have a "turn source into an installable blob" step and a "upload blob to somewhere easily discoverable" step.
I guess splitting making a runnable blob from source and making an instalable blob from runnable make sense when you target many packaging format (like deb/rpm/flatpack/...) and less when not
Install bonfire.cafe
Get the full app experience
