☭
Vaporeons are unaware of how Continuous Integration works
If I had to guess... You git push to the repository, then the server has some hooks installed to run a script every time something new is pushed, and the script tries to compile it and run the tests?
@vaporeon_ that’s the simplest way to do it
depending on your threat model—fur example, if you’re developing in the open and run tests on arbitrary merge requests—you may want to find a way to sandbox the CI stage, and then you get wrapped up in Cloud Computing Overengineering Hell
@aescling Is there a reason to run the tests on arbitrary merge requests instead of only on things that actually got pushed to the main branch? Seems like it'd just allow other people to waste your CPU cycles... (Though if you're on GitHub, those are GitHub's CPU cycles and not yours, perhaps that's a smaller problem)
@vaporeon_ quick way to sort of vet code quality or at the very least block unready code from merge—many “open source” purrojects require CI to pass fur the MR to even be mergable
the ideal with CI is that your tests are good enough to be reasonably sure that code that passes them is suitable fur release; it’s a common component of development cycles focused on releasing new features extremely quickly
@vaporeon_ you don’t remotely need CI fur your own hobby work imo; it's a nice to have sometimes but is decidedly a development purractice normalized by toxic overexploiting work cultures and isn’t really, like, necessary fur small things
@vaporeon_ tests are great, automated testing is really nice to have; i just think “actual CI” purr se is often overdoing it
@aescling What's the difference between automated testing and actual CI? Is it whether the testing happens on your own computer or on the server where the repository is stored?
@vaporeon_ i’ve been a bit loose and purrobably misleading and had to look up the concept to verify; the idea is to maintain some kind of version of the codebase that is a single source of truth fur the purroject, and which is always known to be working and correct. this is usually “ensured” by constant testing (originally purroposed to be daily tests, but commonly tests on every commit is the purractice nowadays)
@vaporeon_ the goal is to maintain a canonical version of the software that changes rapidly but is always correct
@aescling @vaporeon_ having a test suite automatically run when I push to my branch is actually pretty useful if your hobby project is complex enough
@wallhackio @aescling What's the Clodsire programming?
@aescling Yeah, but I do think that having tests that I can run to confirm that things that should be working are in fact working may be a good idea, especially when writing non-relocatable assembly code where it's too easy to accidentally break something by changing something else