You can’t really bork your system, since you can’t always roll back and since the entire system is declared in one file (tree) that should work flawlessly.

In case of servers: the entire config is in one place. That can make maintenance much easier. At least for Homeservers. If you’re deploying a fleet, puppet or ansible might be the better tools.

Epochs aren’t that simple either.

First of all, local time can be relevant, so you have to store timezone information somewhere anyway.

Epochs are also somewhat iffy in regards to leap years or seconds.

And finally: write me an SQL to retrieve all entries submitted in 2022 using just epochs.

Timezones are annoying as fuck, don’t get me wrong, but simply ignoring them isn’t a solution either.

I had a client whose clock was just a few milliseconds behind the server’s, but due to timezone crap one hour in the past. And the signature was valid for one hour.

If the network just happened to be too congested, the validation failed. The next request went through just fine. Took us forever to find out.

Wait, you push to main directly? That’s not exactly what “trunk based” means.

If cloning a repo is an issue, you’re using CI wrong. --shallow has it’s purpose.

Anyway, in my project a complete CI run including local integration tests takes about an hour. We could cut that down by running things in parallel, but we never bothered to add more runners.

I would say, if your tests hold you back, you might want to reconsider testing. Staged testing is an option, or just reevaluate whether you really need all those test cases. Many integration tests are not really testing that much, because 95% of them overlap.

What really baffles me is how bad we (as an industry) are at actually using engineering to leverage these frameworks.

It seems to me, like 90% of the regular, boring business software falls into a handful of categories, where in each category the same problems get solved again and again and again. Frameworks do help, but by far not as much as I’d expect.

Just think about how much software is essentially form>validation>transformation>persistence>messaging. It’s always the same, yet if you’d want to write one of these apps, you’d start with a rather bare bones Spring Boot/Quarkus app and maybe a React frontend, that doesn’t have any connection to the backend, so you have to manually plug them into each other.

As the other comment already stated: it’s extremely complicated and, in my experience, causes weird splits between client and server logic. Maybe I completely misunderstood the idea, but it seems like every use case requires some code in the server to do all the traversing, which also means, that every use case needs to have logic added at both ends of the conversation, which kind of defeats the purpose of loose coupling.

All that may dissolve itself if you’re having hundreds or thousands of different clients and use cases, that all boil down to a relatively small set of traversing methods in the server, but who actually has that many clients/use cases?

It all seems like it’s again one of those “but Google does!!!” technologies that simply don’t make sense for 99% of projects.

That actually looks quite promising. You don’t happen to know of a similar project for Gitlab runners?

It can’t be that hard to create a test harness, so I can plug my own variables into the runner context.

Even just an 80% solution would speed up development tremendously.

I have to say, pretty much every CI/CD tool, build automation or whatever you want to call it, sucks.

Somehow they all manage not to offer boilerplate actions since that would be too restrictive, yet they also stand in your way if you want to have advanced features.

I often end up writing pipeline steps/jobs thinking “how is that not already built-in?”.

And my absolutely biggest pain point: why the fuck is there not a single tool that lets me execute pipelines locally? Why do I have to have 200 commits all saying a variation of “pipeline test”?

I solved it using nix-tree, see the other comment.

Well, that was easy.

I had networkmanager enabled and apparently, that also pulls in a bunch of gnome packages. Why nix thought that suddenly FF needs to be built from source, is beyond me.

The “Win” in Winforms stands for Windows, capital W. It’s simply not available for Linux.

That mug has to be among the worst ever produced.

So, once again we are at a point in subs like this were the question is: Oblivious autist or arrogance bordering on being an asshole?

Pointing out someone’s claim that they don’t care about processes when it’s the critical aspect of any professional work is hardly what I’d call an insult.

See, you’re not claiming that processes are important, you’re claiming that your process is important and your interpretation of Git is the only one allowed, and that everyone who disagress with your opinion is an idiot.

That is factually wrong, extremely close-minded, unproductive, and really really arrogant

And those who don’t immediately insult everyone at the slightest opposition are the ones who get things done.

Seriously, your line of thinking is exactly the one of those weird colleagues nobody wants to work with, because they insist on their idiosyncratic bullshit.

The “problem” you described above is - if it exists at all - extremely niche, and hardly anything anyone should solve with git, but with processes.

Maybe you have a use for it in your workflow - but that might also mean your workflow might not be the best.

That sounds like a solution in desperate need for a problem.

All the “problems” you described boil down to “switching branches is evil”.

If you need anything more complex than cherrypick, you already screwed up big time.

No, it’s definitely user error. Apple clearly states in the manual, that you’re not supposed to use the goggles like goggles!

Also: Let’s be honest, 99.9999% of our work is not that special. It’s cookie cutter business software. There are only of handful of problems I encountered where you could argue, it would have actually required an “awesome” developer. All the others were business problems, lack of knowledge or too ambitious deadlines (thanks, sales!).

Nowadays, I’m lucky if I get more than 2h in code per day. Even if I were the best dev in the world, my company wouldn’t benefit that much.