GitHub Actions radicalized me
-
Devs make mistakes. We want to put up guardrails so mistakes don’t hurt us so much.
Please don’t deliberately line the guardrails with barbed wire.
-
You work somewhere where the tests don't always fail???
-
You work somewhere where the tests don't always fail???
wrote on last edited by [email protected]You just guessed my job lol
-
Imagine having unit tests, my company could never
-
You work somewhere where the tests don't always fail???
Have you tried rerunning them all day until they pass?
-
How is this meme related to the context?
-
You work somewhere where the tests don't always fail???
Ha, losers - tests can't fail if you don't have any tests.
-
…it’s okay on rare and understood cases. (Why else would you be able to merge if it’s failing.)
-
Sure, but do you want to risk catastrophy as a way to filter out bad developers?
-
You work somewhere where the tests don't always fail???
wrote on last edited by [email protected]I mean what's the point of your test if they fail. It's already bad enough that one of our test is flacky. To be fair I am working in a company that does a lot of system safety and a lot of our stuff isn't just tested, it's mathematicaly proven.
-
I mean what's the point of your test if they fail. It's already bad enough that one of our test is flacky. To be fair I am working in a company that does a lot of system safety and a lot of our stuff isn't just tested, it's mathematicaly proven.
Shit! You got deadlines, and managers or customers piling in? Yeah, they don’t pass, but who cares! The code works….probably! Ship it!
-
This is dumb as fuck.
-
wrote on last edited by [email protected]
We have a few non-required checks here and there - mostly as you need an admin to list a check as required and that can be annoying to do. And we still get code merged in occasionally that fails those checks. Hell, I have merged in code that fails the checks. Sometimes checks take a while to run, and there is this nice merge when ready button in GH. But it will gladly merge your code in once all the required checks have passed ignoring any non-required checks.
And it is such a useful button to have, especially in a large codebase with lots of developers - just merge in the code when it is ready and avoid forgetting about things for a few hours and possibly having to rebase and run all the checks again because of some minor merge conflict...
But GH required checks are just broken for large code bases as well. We don't always want to run every check on every code change. We don't need to run all unit tests when only a documentation has changed. But required checks are all or nothing. They need to return something or else you cannot merge at all (though this might apply to external checks more then gh actions maybe). I really wish there was a require all checks to pass and a at least one check must run. Or if external checks could tell GH when they are required or not. Either way there is a lot of room for improvement on the GH PR checks.
-
Have you tried rerunning them all day until they pass?
Would you look at that - the pipeline is green now! Quick everybody, merge your stuff while it's stable (/s) (sadly a true story tho)
-
Ha, losers - tests can't fail if you don't have any tests.
wrote on last edited by [email protected]Why write tests when you should be writing more features the business needs now but will never use?
-
We have a few non-required checks here and there - mostly as you need an admin to list a check as required and that can be annoying to do. And we still get code merged in occasionally that fails those checks. Hell, I have merged in code that fails the checks. Sometimes checks take a while to run, and there is this nice merge when ready button in GH. But it will gladly merge your code in once all the required checks have passed ignoring any non-required checks.
And it is such a useful button to have, especially in a large codebase with lots of developers - just merge in the code when it is ready and avoid forgetting about things for a few hours and possibly having to rebase and run all the checks again because of some minor merge conflict...
But GH required checks are just broken for large code bases as well. We don't always want to run every check on every code change. We don't need to run all unit tests when only a documentation has changed. But required checks are all or nothing. They need to return something or else you cannot merge at all (though this might apply to external checks more then gh actions maybe). I really wish there was a require all checks to pass and a at least one check must run. Or if external checks could tell GH when they are required or not. Either way there is a lot of room for improvement on the GH PR checks.
wrote on last edited by [email protected]There are definitely ways to run partial testing suites on modified code only. I feel like much of what you're complaining about is an already solved problem.
-
If you only write tests for things that won't fail, you're doing it wrong. Are you anticipating some other feature coming soon? Write a failing test for it. Did you find untested code that might run soon with a little work? Write a test for it. Did a nonessential feature break while adding an essential feature, let the test fail and fix it later.
-
Why write tests when you should be writing more features the business needs now but will never use?
a bug? No problem we will just fix it in the next release. loop for eternity.
-
This just sounds like "my frontend only changes shouldn't be impacted by some dumbass breaking backend two commits ago", which seems reasonable.