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.
this post was submitted on 20 Jul 2025
374 points (94.5% liked)
Programmer Humor
25425 readers
973 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
You work somewhere where the tests don't always fail???
Ha, losers - tests can't fail if you don't have any tests.
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.
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)
You just guessed my job lol
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!
LG2M ✅
The real problem is merging before waiting for that one slow CI pipeline to complete
gitlab has a feature where you can set it to auto-merge when and if the CI completes successfully
One problem is GHs auto-merge when ready button. It will merge when there are still tests running unless they are required. It would be much better if the auto merges took into account all checks and not just required ones.
It tests passing is a requirement of merging, then you should set the tests as required.
If you have folderA and folderB each with their own set of tests. You don't need folderAs tests to run with a change to folderB. Most CI/CD systems can do this easily enough with two different reports. But you cannot mark them both as required as they both wont always run. Instead you need a complicated fan out pipelines in your CICD system so you can only have one report back to GH or you need to always spawn a job for both folders and have the ones that dont need to run return successful. Neither of these is very good and becomes very complex when you are working with large monorepos.
It would be much better if the CICD system that knows which pipelines it needs to run for a given PR could tell GH about which tests are required for a particular PR and if you could configure GH to wait for that report from the CICD system. Or at the very least if the auto-merge was blocked for any failed checks and the manual merge button was only blocked on required checks.
You can have certain jobs run based on what directories or files were modified. If projectA was the only one modified, it can run just projectA's tests.
Yes. They can. But they do not mix well with required checks. From githubs own documentation:
If a workflow is skipped due to path filtering, branch filtering or a commit message, then checks associated with that workflow will remain in a "Pending" state. A pull request that requires those checks to be successful will be blocked from merging.
If, however, a job within a workflow is skipped due to a conditional, it will report its status as "Success". For more information, see Using conditions to control job execution.
So even with github actions you cannot mix a required check and path/branch or any filtering on a workflow as the jobs will hang forever and you will never be able to merge the branch in. You can do either or, but not both at once and for larger complex projects you tend to want to do both. But instead you need complex complex workflows or workflows that always start and instead do internal checks to detect if they need to actually run or not. And this is with github actions - it is worst for external CICD tooling.
Both GitHub Actions and GitLab CI let you specify filepath rules for triggering jobs.
Exactly; the OP image is saying that there's no point to doing that.
Imagine having unit tests, my company could never
Sure, but do you want to risk catastrophy as a way to filter out bad developers?
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.
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.
Yeah there are ways to run partial tests on modified code only. But they interact poorly with GH required checks. https://github.com/orgs/community/discussions/44490 goes into a lot more detail on similar problems people are having with GH actions - though our problem is with external CICD tools that report back to GH. Though it does look like they have updated the docs that are linked to in that discussion so maybe something has recently changed with GH actions - but I bet it still exists for external tooling.
Bro just crash the CI because the linter found an extra space bro trust me bro this is important. Also Unit tests are optional.
…it’s okay on rare and understood cases. (Why else would you be able to merge if it’s failing.)
"You don't have the hiring and firing power."
-- Kitty, Arrested Development
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.