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

@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

@vaporeon_ tests are great, automated testing is really nice to have; i just think “actual CI” purr se is often overdoing it