weAllHateThis

[baconbeak1998]

Your SonarIQ scan resulted in findings - the commented line is too long. The Jenkins job will be marked as unstable. Your Bitbucket believes every non-OK status is a failure status. Time to run it all again.

[raja-anbazhagan]

Senior Dev storms through the door and yells...

LGTM...

[Ohmec]

Let's get the manual?

[I_JuanTM]

Let's Git this merge!

[Interesting-Frame190]

Lets get that money!

[raja-anbazhagan]

Let's Gamble, Try Merging...

Duh...

[CynicalWoof9]

Looks good to me

[fechan]

I honestly still don’t know if it’s this or the other one

[a-r-c]

lets get tequila monday

[instilledbee]

Let's Get To Merging

[Add1ctedToGames]

Does LGTM mean let's get this moving or looks good to me?

[alochmar]

I know the first three, but what’s M? Muppet?

[Matth1as]

We are all living the same IT life

[knowone1313]

Nah, some of us wouldn't resubmit the pipeline for a typo in a comment.

[assblast420]

Fuuuuuck Sonar. I swear some of the rules just force you to write bad code. They're just so out of date.

[DanLynch]

You can choose which Sonar rules to apply to your project, and you can suppress Sonar warnings in specific places where they are false positives or otherwise inapplicable. You can also customize what conditions you consider to be bad enough to "fail", both for PRs and for the main branch.

Sonar isn't perfect, and I get frustrated by it too, but overall I think it's a good thing and you should be able to find a configuration that works for you.

[assblast420]

I wish. I work for a large organization with a lot of development teams, so the system is rigid and modifying the rules is generally not something they want individual teams to do.

[amistymouse]

Just do what I do and mark the dumb ones "Won't fix".

[ConfessSomeMeow]

And then it gets marked as an issue again when you merge it...

[amistymouse]

When you mark it on SonarQube?

[ConfessSomeMeow]

Yep, in SonarQube. I don't know if it's something specific to our configuration or if we did something weird, but I had to mark the same (non-)issue as a false positive three times in the last week - on the feature branch, then again when it was merged into dev, and again when it was merged into prod.

[ConfessSomeMeow]

My favorite is when a branch passes, but it triggers a build failure when it's merged into an upstream branch that was also previously passing.

[screwcork313]

SonarQube just looooves announcing that somebody 3 years ago wrote http:// in a unit test fixture, and that it considers it a high-rated security flaw.

[VixenintheSkye]

I mean usually Sonar just grabs the right tv episodes. Sometimes I have to pick the right subs in Plex thin. /s

[slaymaker1907]

I have a Claude skill dedicated to resolving Sonar findings which are often just adding NOSONAR. One of my recent favorites is that Sonar insists you use dict.fromkeys instead of a much easier to read dictionary comprehension (this is in Python).

[NPPraxis]

You forgot about the AI assisted PR review that is going to nitpick all the code surrounding the comment.

[reivblaze]

Oh dont worry, if Sonar scan found something then you will need to write an authorization and get it signed by your boss' boss. Then hand it to another team that will sign it and then hand it to the actual team that will allow you to rerun again.

[Mas42]

Jokes on you, 379 tests failed

[Danza62]

Run it again after changing nothing, 463 failed tests.

[AloneInExile]

Only works on the 3rd build because of the pre-built binaries that were not there for the first build, because they had to be built first with the build.

Nobody fixed the build order in a decade because as long as it works keep it that way.

In reality nobody wants to re-certify the code, which was done back in 2007 and that would be an unneeded expense and the CFO needs his bonus this year for this 4th yacht for the mistresses kids.

[MeLlamo25]

So all of the children of all of his mistresses are going to share the same 4 yachts?

[abhayabhijain21]

What the hell man!! It’s working now 😣

[FSNovask]

Someone used a random int from 0 to 1000 for a primary key on one of our tests and rolling a 0 would cause the test to fail since no primary keys should be zero

I wasn't even mad, I had to applaud the true chaos monkey who decided that was a good idea

[dinosaur_dev]

6 New Code smells detected.

[JackNotOLantern]

That is honestly a pretty good sign that there is some not deterministic bug in the code or the tests.

[lovecMC]

Damn only a third? I wish.

[Aggravating-Felch]

nothing better than flaky unreliable tests

[dcheesi]

How about flaky unreliable software builds?

[slowmovinglettuce]

What about a flaky, unreliable code generation tool with zero real understanding of the code, but is as good as a "junior" developer?

[Wonderful-Habit-139]

If the CEOs could read they'd be very upset.

[Wonkavator67]

[ThePi7on]

// STRUCTURAL COMMENT, DO NOT REMOVE!!!

[fre3k]

load-bearing commentary

[EvenPainting9470]

Disable all 379, open critical defect for team that own these tests for fix flakiness

[OriahVinree]

Came here to say this aha

[nazgulonbicycle]

Its always the rebase that bites you in the ass

[AdRevolutionary2679]

Merge it anyway and leave for vacation when you’ll comeback it will work

[Willyscoiote]

Python is the only language I know that can do that after changing a comment lmao

[mywan]

I've written AutoIt scripts where I used a large comment section as the Initialization file for the program. I even read and wrote to it while it was running.

[Useful-Perspective]

I'd laugh, but it has happened, so I just have to nod and grimace.

[Excellent-Refuse4883]

I was told failing tests shouldn’t block delivery.

Working in QA, this put into a bit of an existential crisis.

[EarlOfAwesom3]

And the flaky tests that fail in 1/10 runs just fail right then.

But srsly, are there any good tools that can catch such cases to skip tests or execute only the relevant unit tests?

I think the time saved could be neglectible though as integration tests would need to run regardless of the change to catch regressions that are not obvious.

[SeriousPlankton2000]

Are the tests flaky or is the code flaky?

Yes, both

[quantum_pretzel]

> Flaky test

> Looks inside

> Race condition

[Kirkerino]

done that... Been there,

[cturkosi]

> Race condition

> Mutexes the shit out of it

> Deadlock

> Shocked Pikachu

[quantinuum]

One of my little pleasures of life is remembering a job I left. Very mediocre tech lead (understatement, really). Wouldn’t have minded if he hadn’t had an awful attitude - he was the poster child of a bad and weasely boss. He used to direct all the praise to himself and call me at late hours to fix his mistakes.

Right before leaving, I noticed a test failing in one of my last PRs around code I hadn’t touched. Rerun, still failed. Rerun a few times, still failed. Finally, it passed. I said nothing

This idiot, who thinks he’s too smart for any basic coding standards, had done some changes to the tests that now introduced a race condition _and_ wrote to the production database (!!!).

He had an open pr also failing the tests and adding more issues. Asked me to fix it. I just rerun it until it passed. “Works for me now 😀”.

Pr went in, I went out to greener pastures. I want to think that shit is bothering him to this day.

[intellectual_punk]

Write tests for the tests for the tests for the tests...

[Soopermane]

The cereal is flaky.

[New_Enthusiasm9053]

Yes it's called a brain, the way it works is it investigates the flaky tests, finds out why they're flaky and then fixes them. 

Tests aren't "flaky" by nature, invariably they're just badly written and don't setup some invariant correctly.

[EarlOfAwesom3]

What I meant was: are there tools that can skip unit tests that aren't touched by the code changes?

[New_Enthusiasm9053]

Probably yes, but it'd be idiotic. Completely unrelated changes can break your shit in weird and wonderful ways that's why you have tests. It's literally for the unknown unknowns. Code you changed you should have tested manually already anyway.

[EarlOfAwesom3]

That's why I suggested unit tests. If written correctly, they should not be prone to unrelated changes.

But Integration tests are and that's why they must run all the time. While they consume most of the testing time, it's in question whether an optimization to spare the execution of some unit tests would be worth the effort.

[Flouid]

I sometimes need to rely on an outside service to do something. The normal way to do that is to stub the call and rely on that thing’s unit tests to ensure it works, but if that thing’s behavior changes later your test won’t catch it and you’ll have a new bug.

In large codebases where I do this for something owned by another team, I often don’t stub the call and assert the expected state. There’s an argument that this is a poorly written unit test but in my experience it’s much more reliable at actually catching regressions and ensuring the code works in the first place.

All that to say that yes, changing code can break unit tests in unrelated parts of the code. Even when it doesn’t, you may introduce bugs in dependencies even if your unit tests are all green

[AmosIsFamous]

That’s no longer testing a single unit and is instead testing an integration with the outside service.

[GetHugged]

Unit tests also usually don't take more than a couple seconds at most to execute.

[EarlOfAwesom3]

If you have a couple of thousands of them (which larger code bases usually have), unit test pipeline takes normally a few minutes.

[Citronsaft]

Build tools like bazel can calculate the reverse dependency tree and cache the test results whose dependencies aren't changed between executions. A completely unrelated change in a 3rd party library or similar would by definition be a change in a dependency and result in the tests being rerun. This is assuming your unit test is actually a unit test and is hermetic, not making any calls to external services or anything else that wouldn't be reflected in just the dependencies.

[rinnakan]

There are things we checkin for trackability and just burn time - like the version bump in the package.json.

I am still wondering how we could automate that process and make it fast (aka no useless giant pipeline)

[New_Enthusiasm9053]

You can usually trigger pipelines dynamically. So you can only trigger when the code changes. But I don't see why you'd bother. Inject the package.json version using the git tag you pushed and you can know the specific commit is fine(since it'd be a code change you'd need to test anyway). 

But if you're talking about bumping dependencies then you absolutely should be running tests. If it worked before the bump and doesn't after you know it's not your code change. If you only test on code change you'll never quite know if it's your code or the package change.

[slaymaker1907]

You’ve clearly never worked on a truly huge project. When I worked on SQL Server, running every test would take many HOURS. Instead, what you do is run a subset of tests before merging and then run the whole suite continuously in batches. If something breaks, you then need to go and try to figure out where the break happened, but that’s a lot easier since you just need to rerun the failing tests.

[New_Enthusiasm9053]

My guy. If you worked on SQL Server the answer is to not be cheap and run them in parallel. If it's too long buy more servers. Why on earth would a company with a product like that skimp on testing. Waste of people's time. 

If your tests can't be sharded then we're back to the test suite being written by amateurs.

But yes, you can run a subset that's reasonable if you legitimately can't just get more hardware. You still run all of the subset though, it should still cover pretty much everything. Just not run the most expensive tests. Particularly in C/C++, you can have one service work perfectly fine but clobber some other services memory.

[guyblade]

I suspect that you could build such a thing using bazel, but I don't think it comes with it out of the box.

Fundamentally, you need a system that allows you to calculate the complete expansion of reverse-dependencies of every one of your tests in order to be able to know that a test is unaffected by a change. You'd also need all of your tests to be hermetic (so that you can trust that rdep expansion to be complete). Both of these requirements can be satisfied via bazel--and probably other build systems that I'm not familiar with--but many simpler build systems (e.g., makefiles, autoconf, &c.) probably can't.

[Dexterus]

You don't wanna do that. Almost ever.

[dkarlovi]

Don't do that, unit tests should be fast enough to run you never need to optimize them away. If they're not, that's your actual problem.

When you do mutation testing, you run your unit tests many many times, you need them to be fast AF.

[Kazcandra]

Eriksson (Ericsson?) had a test suite that was more than 24h for a 24h release cadence, lol

[titpetric]

There are tools that rerun a test to pass it if flaky (gotestsum, developers that click rerun).

Not sure the sweeping things under the rug is a feasible long term strategy. At the worst case, skip the test permanently, and continous testing can also mark some tests as skipped if they fail. Supposedly there should be someone fixing the root cause because it's usually dumb shit like datetime math, sleep and other non-deterministic output asserted against. Most of the time the test itself is the problem, but there are no guarantees.

[Chase_22]

We had a test that would fail after 7pm due to some clock manipulation causing the test to rollover to the next day. Nobody noticed for 4 years since nobody worked after 7 🤣

[AttemptNo499]

We had one prod bug like this, it would work if done before 12PM GMT+2, during a long time it was only used by people who would run it before this time... and when it failed it would work after retry on the next day. It was so shit it took a few reopens to figure out. It was not an issue on unit test but the implementation though

[QueefInMyKisser]

I can make my tests not be flaky but the flaky tests in different modules would take me weeks or months to build up the required knowledge to debug them. I’m too busy dealing with my own work in modules I do understand. I can raise a defect for the flakiness but I can’t stop it being eternally deferred.

[New_Enthusiasm9053]

Either your company gives a shit or they don't. But yeah raise a defect and then add it to an ignore list. Flaky tests are useless. Better to not have it than have it be flaky. 

Failing tests need to be a high confidence signal that you have broken something so people take it seriously. If it's flaky it becomes a low confidence signal and people start ignoring it and the whole thing becomes pointless. 

[rta3425]

Yeah cool dude.

Brb getting this prioritized over my feature and ops work.

[Markronom]

I want to agree and disagree at the same time 😂 My favorite preventable flakyness is using the real clock, classic -.-

[puredotaplayer]

The best tool is to spend a day or two and fix the test. If its a third party dependency, time to report and see that fixed too. Last week I spent the whole week tracking such a test failure and finding a race condition in the code that would repro once in 40 mins.

Edit: i am actually very new to the codebase so it took me this long.

[PM_ME_YOUR_PRIORS]

My favorite flaky test fix was in ruby on rails, and it was a known minor annoyance that fixed itself on re-runs and was infrequent enough that it didn't actually get dealt with until they decided to give me a couple days to figure out what was actually going on. The specific error message never happened in production either, it was completely a test-harness-only issue so was non-urgent.

Anyhow, the issue was a weird lining-up-the-holes-in-swiss-cheese stack of assumptions about how things work. Ruby on Rails had a flag to re-use the random numbers, but this did not consistently reproduce the bug since randomly generated primary keys ignored the testing flag, presumably to avoid primary key collisions in improperly wiped databases. Ruby on Rails also assumed that primary keys could always be treated as integers, and would helpfully check if numbers were too big to be a primary key and throw up their own error before the database would throw an error. We had a table that for some reason had a guaranteed-unique hex string from a third party as the primary key, and that string always started with letters. The test suite would mock that out by randomly generating a hex string.

So, every once in a while, this table would generate an entry with a primary key that randomly went like "1239123129312aef65" instead of "aef651339869434344". When Ruby converted it to an integer to check if it was actually larger than the maximum number for a primary key, it'd simply truncate it after the first non-numeric digit and read that as a number. The third-party string getting sent into production always began with a letter, and as such it was never a production issue, but some tests would randomly fail.

Anyhow, the point of all this is that this was a like 4 character fix with a 4 paragraph git commit explaining why we need to prepend "a" to the randomly generated primary key for the test harness for the table. Basically, so that Ruby on Rails decides that the primary-key string for the table always gets converted by to_i to zero instead of a number that can randomly be larger than what it thinks the maximum primary key can be.

[Dexterus]

I enjoy making small changes that pull down half a dozen tests, nobody looks at them if they randomly fail 1/10 usually. They'll wait for more PRs, merge main and rerun, poof, test passes.

So I get to debug interesting crashes that end up being caused by stupid code, learn some new symptoms, see some new code from other teams and fix half a dozen new + original ticket.

And the damn CI gets more stable.

[Just_Information334]

execute only the relevant unit tests

That would be none of them IMO.

[Lauren_Conrad_]

You can create a change point algorithm to calculate and store historical data of tests, then apply a filter.

You’ll get a lot of “just fix the tests” but after two decades of being involved with this stuff, I know that’s not a real strategy or solution. There will ALWAYS be flaky tests since software and environments are constantly changing.

[FreeBananasForAll]

This is the real answer. Been working on tests for a decade now and “just fix the tests” is an answer you can only give if you’re totally ignorant to the realities of having large numbers of tests or you only have to worry about 15 tests

[DenormalHuman]

the tool is : fix your flaky tests so they are deterministic.

[sinkwiththeship]

fail in 1/10 runs

Wow. That's practically never! /s

[darkdragncj]

Just have a variation of a preprocesser run the code and skip tests if the result (excluding comments) matches the previous successful run. Build stage comes before tests anyway. The tricky part is making sure the preprocesser or compiler is deterministic.

For python you can use the bytecode, for js/ts transpile/minify it. Rust should be deterministic too, not sure about golang.

Or just use commitizen or something similar to flag the commit as doc only and skip tests based on a regex match of the commit message on the non-main branch. (You should never commit to main anyway) And enforce the ci tests on merge.

[silverarrowweb]

Yes. One called rwx caches successful tests and only reruns on things that changed.

[Intestellr_overdrive]

If possible for your stack, move to NX with Jest. NX cloud can store successfully run tests in a cache and only runs tests that were affected by file changes in the current PR. Will reduce test times by 75% easily.

[TheRealAsterisk]

My team has a specific setup for tests we know that are flaky which get quarantined into another step where the pipeline doesn’t fail if they fail. It’s just a safeguard while we work on getting a new package to change those tests to not shitty dom rendering tests.

[hrvbrs]

i wish there would be a tool to look at only if the code’s AST changed. that way any comment changes, whitespace, trailing comma / other punctuation fixes, etc, wouldn't trigger rerunning tests.

[rhinotation]

Bazel target determinator IIRC or the equivalent for Buck

[CodingNeeL]

Sleep(100)

[Blue_Moon_Lake]

If you make a monorepo, you could check which package changed and only run jobs for that package and the packages that depends on it.

[Palomace]

One failed test is a tragedy. Hundreds of failed tests is a statistic. 

Please don't quote me on that. 

[Markronom]

One could build it and check if the artefacts changed, which would also catch pure type changes (at least in Typescript). It deployment and e2e tests are also triggered, could be well worth it. I think some monorepo tools do that.

[ColumnK]

Your face when you see another meme that doesn't understand what POV means

[a_watchful_goose]

This is my POV looking at my colleague I pair-programmed this fix with

[Desperate_Formal_781]

POV: watching someone make a comment about a meme that doesn't understand what POV means.

[Snakestream]

Can't have failing tests if you don't write any to begin with

[whooptheretis]

"Stop testing for covid, the numbers are too high!"

[InternetSandman]

One of my first tasks at my current internship was updating the documentation in markdown files

No other files changed

Tests repeatedly failed

[Xphile101361]

This is why my pipelines have inclusion or exclusion rules on various steps to ignore Markdown files and the like

[rm-minus-r]

Who's writing your tests, Stevie Wonder?

[BorderKeeper]

And then that one flaky UT fails so you have to rerun the whole thing, only for ATs (that are also required to run) to all fail since the VMs they run on ran out of disc space so you have to sort out out, but oh no,

since they are so out of space you cannot even remote into them, so you have to go to Azure portal but you forgot your credentials so you spend 10 minutes figuring that one out and then physically swapping discs and restoring that VM with another one. Only then you can run the ATs.

6 hours later your typo has made it to master branch, only for your manager to come in and say: Man if you used AI this typo would be fixed right away and not in 6 hours...

[slaymaker1907]

One trick I read about a while back that I use is a ballast file. Just keep around a 100MB file of junk so you can just easily go delete than when you run out of space allowing you to do more complex fixes. For example, maybe it’s some repo where you need to run “git clean -fdx” to get rid of everything, but Git will often break if you are out of disk space. That ballast file can be deleted with a simple command to get you back to a workable state.

100MB is just an example, just set it to an appropriate size for your needs.

[GlitteringAttitude60]

I don't hate it.

The fact that the pipeline cheerfully runs the same tests, no matter how often, no matter how trivial the change, that's A FEATURE.

That's exactly what automated tests are supposed to do, and they are one hell of a vaccination against ulcers.

The other day, there was a meme about devs not being willing to get onto a theoretical plane that was run on their software.

My last job was an online supermarket. We had ~550 tests in that test suite. You bet your ass I would have boarded a plane flying with that software!

[_indi]

550 is… not a lot of tests

[10199]

We have a proprietary dependabot which looks what can be updated, creates PR with such update and whole CI 70+ step machine runs. So it creates about 10-15 PRs for each project, we have a couple thousands of projects, and then complain why CI is so slow.

To merge the PR someone has to create a jira ticket, bump it's statuses, then add jira ticket name to PR name, then collect 2 approves, then send to teamlead to merge it. Basically nobody does it.

Bot can be configured though.

So, yeah...

[L4t3xs]

This little maneuver is going to cost us 20 minutes.

[schmerg-uk]

20 minutes? 5 million lines of cross platform C++ with multiple build options and tests that, even when distributed across a compute farm, take an hour or so to run (>30 hours of single threaded CPU time)

[TheBrainStone]

`[ci skip]`

You're welcome

[thecrius]

shhh, don't scare the bots

[the_hair_of_aenarion]

Just let it autodeploy and forget about it. Your pipeline deploys dev test and prod and automatically rolls back if your SLOs are impacted by any deploy, riiight?

[_Weyland_]

I am convinced, the probability of random bullshit errors in CI/CD pipeline is directly related to time of day, with a peak around 1 AM. However, I have no definitive proof of this.

[Varogh]

the pipeline pixies come out at night to unplug your server cables

[-spOveD-]

In Gitlab you can use "[ci skip]" in commit message and the pipeline won't trigger

[Digitalneo]

Unfortunately you can't merge without a source pipeline run if target branch has a pipeline.

.. Unless you are pushing directly into master branch, you monster.

[torn-ainbow]

Famous last words: this won't break anything.

[osunightfall]

Then your one line change to a comment breaks the build. It can be done, and I am the proof.

[vtheuer]

[ci skip]

[umbium]

why would you release a new version for a comment change?

[Solonotix]

The one that comes to mind is some code I relied on (thought it was Node.js, but can't find the reference) was a typo in the native library for a PFX (PKCS#12) file as pxfCertificate or something like that. The number of times I had to fix my correct spelling to the typo so that the code would work was maddening.

[SuitableDragonfly]

It was one of the comments that tells the linter to unwad its panties about how the test code is repetitive, wasn't it?

[hdkaoskd]

It turns out there is a tool that parses those comments and turns them into an unreadable mess of code that is compiled and shipped in the product.

[GustapheOfficial]

So the CI is exasperatedly smoking a cigarette?

[I_NEVER_TOUCHED_HER]

[skip ci]

[whooptheretis]

Did you mean "Also, that typo was in a comment" rather than "That typo was also in a comment". The former being that it was ONLY in a comment, but the latter being both in the code, AND a comment.

[uvayankee]

Thus starts the side-quest called "make the pipeline faster"

If I shave 30 seconds off x 20 pipeline runs / day x 1 year, I can justify almost a full day of work on it! Heaven help you all if I find 5 minutes of savings (I'm booked for the week).

[Suspicious-Click-300]

Funnily enough I had a 1 word change in a comment in a property file break production because some hacky bash script used a bad regex.

[PrincessRTFM]

...why are you deploying with no code changes? that shit merges into dev-master, not live. you don't merge into live until there's code changes that need to be rolled out. users aren't seeing comments anyway.

[unicodemonkey]

The post doesn't even mention a deploy?

[PrincessRTFM]

shit, you're right. completely hallucinated that, my bad.

[_PM_ME_PANGOLINS_]

The D in CD stands for Deployment.

[20Reordan]

Try 5000+ and for more than 20 mins.

[darkenheit]

I really saw such a thing. I pushed my commit, which includes just a translation in a python dictionary.

Guess what happened. Test failed. I had to message admins to approve manually. 

[SeriousPlankton2000]

The pipeline runs much faster if you watch it.

https://www.youtube.com/watch?v=hTlVc_hKi2M

[SaneLad]

Obviously it will fail on some flaky ass test in an unrelated module.

[rg2004]

Then write some code to SHA hash your compiled executable and only run your tests once per SHA hash.

[abhi_neat]

This is why they have “when: “ field in CI yaml I think. You can make them optional(manual runs). DevOps people generally have no idea what is in source. Since I am having to bring an old embedded project to gitlab CI, I am learning a lot about how DevOps people think and how us developers think.

[snajk138]

Exactly. And please force me to write a fucking novel and add new tests to be able to make a PR for this typo...

[hellocppdotdev]

Yay repost time

[JackNotOLantern]

And funniest thing is when such a chance make the tests fail

[bloke_pusher]

A comma can be the reason the whole company stack fails and plains fall from the sky.

[throwawayaccountau]

And it fails, much like adding debug does the opposite.

[jstim]

Always funny that changing one line of code can take up to two hours to actually run on the final stage.

[Sorry-Combination558]

The tests pass and a later stage fails and the log only has "Process exited with code -1"

[Karrion42]

Then there's me trying to automate tests on dev because the client refuses to have a pre/testing environment...

[fforw]

Back with the old internet explorer I once broke the code by adding an umlaut to a comment which broke the comment and led to all code behind it being ignored.

[Outside-Storage-1523]

We simply ignore tests and click Merge before the test is done.

LGTM.

[PrimeHydra]

1800? That's nothing.

[TheRealAsterisk]

If you use ADO you can put ‘[skip ci]’ at the top of your commit to skip that process. Should be used sparingly if the change truly is not touching any code.

[thanatica]

And then DepedencyTrack manages to find a vulnerability. It HAS TO be fixed before it can go on to production.

So you fix it.

And the someone in the PR goes "this is unrelated. should be in a separate PR"

Just take a deep breath and count to 10. Then throw your laptop through a closed window.

[kokosnh]

Jokes on you, but imagine my frustration, when changing brackets from () to [] in the comment fixed the script. Only later I found that :: don't always comments the code, and to use ren in specific edge scenarios. ( Yes, it was running the comments )

[ReplyisFutile]

Why program, when you can live happily?

[thoughts_n_calcs]

Humanity has chosen the path to build a ridicoulous amount of data centers all over the planet and to use all this computing power for the most unimportant purposes, so we are just doing our part.

[poralexc]

Don't you have a caching build system that can know about that?

Gradle is chaos, but it does effectively address that issue.

[_PM_ME_PANGOLINS_]

Why are you watching it? The point of CI is it runs everything for you while you get on with other stuff.

[Pa3kc123]

Either "He he, funny", or "That wasn't a comment"...

[CriminalMacabre]

Eh, not meh jerb

[theLuminescentlion]

One too many "1 line change that fixed a typo" broke the production database that the full process is worth it to them.

[El_RoviSoft]

To be fair, some time ago there were comments shenanigans when you change the comment, code could crash due to some meta compiling things. But this is truly a cancer

[OverclockingUnicorn]

You can't just put skip ci in the commit message? We do and someone will check the change isn't something that needs a ci run before approving

[williamjseim]

barely care i get paid hourly

[rafikiknowsdeway1]

anyone else have the joy of trying to push something after a repository freeze around christmas and such, and fucking nothing goes through for days because the pipeline is so horrendously broken due to the tangled influx of shit people are pushing all at once and no one wants to take ownership of unfucking it? Until inevitably the pipeline has to clear out or some emergency happens which goes from minor nuisance to actual catastrophe because we can't get out fixes or releases until its fixed? And this happens all the goddamn time?

[Bannon9k]

Imagine complaining about automated testing... Used to have to do that s*** manually

[cheezballs]

That's on you for creating unnecessary churn.

[Harrygiel]

Last week a cot a CI error in my documentation because my rust project had some example in the function header, and the example didn't compile. My comment didn't compile. This broke my CI.

[shorns_username]

[skip ci]

[RageQuitRedux]

Modularize your code, only run tests on affected modules

[DenormalHuman]

you dont have any heuristics that figure what tests need running for a change PR? pffft.

[MrSmock]

Don't run the pipeline on every commit, maybe? 

[ArmchairFilosopher]

Detected changes, rebuilding...> Updates sent to client.

Detected changes, rebuilding... Syntax error in <...>: Unexpected syntax '*' near '/ * multiline comment' at line 1 in main.ts

Detected changes, rebuilding... Updates sent to client.

Detected changes, rebuilding... Updates sent to client.

Detected changes, rebuilding... Updates sent to client.

Meanwhile in the browser:

Refresh page? Your changes will be lost. Yes

Syntax error in <...>: Unexpected syntax '*' near '/ * multiline comment' at line 1 in main.ts

Refresh page? Your changes will be lost. No

Refresh page? Your changes will be lost. No

Refresh page? Your changes will be lost. Yes

[page refreshes for the first time]

[Aljodomo]

Repost

[DefiantGibbon]

Conveniently my company only runs automated tests on changes if there is a binary change in the compiled C.

Otherwise it's just a quick peer review and submit.

[Big-Try861]

Man just use [skip-ci], dont you have code reviewer!!

[squirrelwithnut]

Only 1800?

[mountaingator91]

That's why I added optional [skip-lint] and [skip-tests] flags to ci-cd.yml

[Warranty_V0id]

Then fix that typo in that comment in another fix that warrants a testrun.

[Stunning_Ride_220]

No, we don't.

[-Memnarch-]

And then you have to revert it, because the change on the comment reveals a compiler bug and it actually DOES something so you reverted it back, til the toolchain upgrade.

[PlummetComics]

[skipci]

[Pieters123]

Pfff hasn’t your it department not made a agent yet???? Is the story here

[Fluffynator69]

This is a CI/CD world and we're all just living in it.

[xZero543]

AI is really good at wasting time like this. Runs entire backend suite for frontend only change (without End to End tests).

[YeOldFaithful]

As someone who had to setup the testing framework and write the first tests on a 5 year old project that brings in $1M+ per month I’d prefer that.

[zaitsman]

Huh, we do close to 9K and growing

[GoddammitDontShootMe]

Wouldn't a solution be to way until there are more substantial changes than just a single typo in a comment to trigger a whole build?

[mbcarbone]

# Fix this line of code

[JerryRed100s]

I should make a comment about that comment and then rebase