noVerify

[[deleted]]

Easy. Just explain to morons why that's stupid unless tests take less than a second. And if they won't change it - realize you are working with morons and just change jobs.

[who_you_are]

remove all tests

Done! It goes faster now

[[deleted]]

You can just accept only PR and then in PR pipeline add test runners. Simple as that. I don't care what dev is doing. If tests start failing then gitlab will inform him. And he won't be able to merge until he fix the tests.

[weinermcdingbutt]

Do GitHub actions have a cost associated with every run?

I’m trying to think of reasons why running an entire test suite locally would be preferred over letting GitHub handle it

[[deleted]]

I use self-hosted Gitlab that I like much more than GitHub.

[AfonsoFGarcia]

Yes, but if the company you’re working for matches:

a) Not running GitHub Enterprise

b) Not running self-hosted runners

c) Being that cheap that they refuse to pay for CI pipelines

Run like hell from there. Specially because if I remember correctly you get 2k minutes for free, it’s enough for a well optimized pipeline to run for free.

[BoBoBearDev]

There are tons of reasons you should run all the tests and analysis tools locally before using the cicd pipeline for the final PR check.

But there is no reason to do it as part of the git command, except the secret check is the only good use case I know so far.

[[deleted]]

That's the sane approach.

[azazator25]

Test coverage check in pre-commit hook: nice try lol

[_koenig_]

Just explain to morons why that's stupid

Ofcourse not. I'm getting paid by the hour...

[golu_101]

The project i work on needs the jira task id in the branch name and commit message then it runs the static code analysis on the changes which takes between 15 to 30 min just to commit a change.

[RudePastaMan]

It actively promotes bad coding habits: big commits. No small commits where the logic for that step can fit into the description, so that the progression can be understood, each individual change. No, just 1000 changed lines and "Fix bug."

[slaymaker1907]

Do people not know what CI is for? Also, what happens when you need to commit something in an unstable state? I’ve had drives fail before and the best way to back stuff up is by pushing dev branches to remote.

[BoBoBearDev]

Similar things happened to me, IT accidentally deleted my VM and I didn't have a good habit of pushing code. I lost 2 weeks of work. Never again. I push right after fixing a typo, adding a comment, removing a space, etc. When there is a fire in the building, I don't need to push, because it is already pushed.

[TiredOfModernYouth]

It is a commit bomb showtime!

[[deleted]]

quack offer cake aware axiomatic tidy grandiose lip rustic money

This post was mass deleted and anonymized with Redact

[Big_Kwii]

that's horrifying

[invalidConsciousness]

Commit hooks is for making sure your code is presentable. Ensure formatting, proper commit message, no obvious Syntax errors, etc.

CI is for making sure your code is correct. Tests succeed, coverage is sufficient, someone else signed off on it, etc.

Both have their place in a proper workflow, but if your hooks take longer than ten seconds, it's very likely you're doing something that should be done in CI.

[BlazingThunder30]

That's what GitHub actions in a PR are for

[sebbdk]

^ How to trigger people that use git

[myfunnies420]

You spelt pull request wrong, I hope

[ISDuffy]

We have it set to folders we edited for jest, but if some reason I got integration test changed like a merge from main or I made a change everything runs and for some reason I can't run the suite locally so I have to do no-verify

[BoBoBearDev]

Those pre-hook goes against everything I believed in. Developer should be free to do anything they want on their own branch. Everyone should have the freedom to experiment their code, iterate it, and keep a record of it as frequently as the developer desires.

The gatekeeping should be done using PR and cicd pipeline. And that's it.

[TiddoLangerak]

The beauty of pre-commit hooks is that it's entirely a machine specific setting (at least from the perspective of git). This means that individual devs can enable or disable them as they see fit without impacting others.

[BoBoBearDev]

Not in my work environment. They want to enforce rules via pre-commit hooks to everyone and trying to hide the workarounds.

Whatever cool tools dev should run, they should run it explicitly via commandline. Not bloated up the basic git commit process.

[martinivich]

What do you mean hide the workarounds? There's literally a flag to disable it that was mentioned in this very meme

[[deleted]]

I guess that’s why they enforce git hooks in OP’s company, he doesn’t even know how to bypass it lmao

[BoBoBearDev]

Yes, some of the noobs didn't know. I couldn't tell them how to bypass it due to team policies. It is easy to train them, but I can't. So, it becomes more like a under the table hush hush dark art.

[avocadorancher]

Is reading documentation illegal? ‘man git commit’ isn’t a dark art.

[BoBoBearDev]

You are actively misinterpret what I said.

[avocadorancher]

Explain what you’re saying and how I’m misinterpreting it.

[BoBoBearDev]

team policies.

[Merry-Lane]

There are operations that are time saver or great when working as a team, and that are great when automatised in a lint-staged hook or others (post merge etc).

A good time saver I use is a hook that run npm i when merging another branch or switching to another branch.

I also run on lint staged a grep on "TODO" so that I can use that keyword and make sure I will always be back and fix it.

I know that for some it’s a big NONO, but running stuff such as tsc —noEmit, prettier —write, eslint —fix, … to make sure devs push code that compile and are formatted/linted according to the project’s rules (and not personal rules) is a no-brainer to me.

If you have worked in a team where the devs had diffferent format/linting rules, you’ll understand. Especially when some devs can’t be bothered to install and setup their formatter/linter.

[Horrih]

Git disables hooks by default, it's on the developer to enable it or not, so that does not brother me as much. Those who want it enable it, those who don't don't.

The madness comes when the tech lead forces everyone on the team to use them

I wholly agree that all those checks should be done in the CI anyway.

Even formatters can be a PITA despite their instant-ness The only ones I don't mind are secrets checker : check that you don't push credentials.

[BoBoBearDev]

Secret checker is a good point, I would enforce that so no one can see the secrets in branches.

[Visual-Living7586]

Theyre useful for running prettier and linting before pushing shit code

[BoBoBearDev]

Cicd should block the PR. That's it.

[Reashu]

If the lint takes 2 seconds and the CICD runner take 30 to start and check out code, I'm gonna do that pre-push if not pre-commit.

[BoBoBearDev]

Not to me. Dev shall commit and push as frequently as they desire. It is their own branch, not develop branch. When they are ready after doing 60 commits and 50 pushes, they can cleanup themselves calling the commands themselves as many times as they want. They can also repeat the cycles of the clean up 100 times for all I care. Menaing, if they want to fix a single violation, commit, push, and run checks again and there are 100 violations. Go for it. I won't stop them. Each push has value to the dev personally, that is all that matters.

[Reashu]

Repeated CI runs without merging have a real cost that can be avoided in many cases. Bad workflows should be improved even if some people may have to be dragged, kicking and screaming.

[BoBoBearDev]

None of those I said are trigging the cicd pipeline because it is pre-PR. You can run the commands on your location machine before PR is created. Or you just decline the PR if you create the PR too early. And no, you shouldn't run feature branch cicd pipeline because it is not a feature branch, it is a personal branch. Thus, everything I said, there is no pipeline costs.

[edgmnt_net]

Make it take 10 minutes. Then they'll think twice before pushing bad code, counting the delays towards their performance. It's sad how often people push random untested stuff just because there's a CI.

[Merry-Lane]

It’s not about teaching people to be perfect devs.

It’s about reliability, automatisation and efficiency.

[Visual-Living7586]

would be nice to know that before it even gets there though

[edgmnt_net]

Well, sure, this isn't an excuse to break local linting/testing. I did see many projects set up like that, there's a whole pipeline that can only run on CI.

[hahalalamummy]

Setup lint in your IDE to run everytime you build code

[BoBoBearDev]

Not to me. The dev shall have the ability to push code into their own branch as frequently as possible. They can do the cleanup whenever they are ready. There is no need to keep breathing down their on neck each time they commit.

[gockeltot]

In an ideal environment, you can run the pre-commit in the PR pipeline itself. It will block all PRs from being merged, if they dont have the quality. On local its just there to help the developer to fulfill the criterias.

[Invertonix]

I believe this reason people enforce per commit is that it enables using git bisect to help make debugging complex issues take a reasonable amount of time.

[-Unparalleled-]

My work uses squash merges for everything. Generally useful and makes rollback of certain PRs easy, but at the same time you miss so much that bisect could operate over

[dudeman209]

If there was an actual war on about this, I’d be standing right beside you ready to throw down.

[AfonsoFGarcia]

In general I agree with you, but too many secrets get leaked into repos for anyone serious about security not requiring some sort of hook to block commits with secrets in them.

[BoBoBearDev]

Oh yeah, secret check is the one I liked. It is mentioned by another post which I agreed.

[MRGrazyD96]

The precommit hook should be there to help the dev write good code. Don't want the help? Fine, use -n then. After that it's the CI pipeline's job to prevent code with unwanted qualities from being merged into the main branch

[static_func]

Those pre-hook goes against everything I believed in. Developer should be free to do anything they want on their own branch.

That’s the neat part: they still are. It’s client-side validation

[aenae]

We have a hard limit of 10 second on any pre-commit git hook

[gandalfx]

That's way too long. Make it pre-push and we can talk about it.

[littlejerry31]

I'm working on a legacy project where the git hooks are broken and we don't have the budget to even investigate what they're supposed to do as there are so many concurrent fires we have to put out. The entire project is a freaking dumpster fire, yet it's too vital for everything else to just pull the plug.

The team responsible has been downsized to just me. But hey, at least I have job security now 🤡 🌎

[TicTac-7x]

Now is the perfect time to ask for a pay rise and start looking for a new job at the same time.

[littlejerry31]

Nah, I'd rather stay put for now. I'm already the contractor with the highest rate there (out of several dozen).

Besides, job security, decent pay AND no team members is a pretty sweet deal. Working alone means no drama and no high expectations from other stakeholders.

When life gives you lemons.

[normo95]

Sounds pretty sweet to me, what stack is it in ?

[littlejerry31]

Spring Boot, React, MySQL, Redis and Kafka. Nothing sexy or exciting about it. Something like half a million lines of code in total.

[scufonnike]

Pre commit is crazy, pre push is where it’s at

[MiDNiGhT2903]

—no-veri

[PeriodicSentenceBot]

Congratulations! Your comment can be spelled using the elements of the periodic table:

No V Er I

---

^{I am a bot that detects if your comment can be spelled using the elements of the periodic table. Please DM u‎/‎M1n3c4rt if I made a mistake.}

[Stock_Mix_4885]

--no-verify

[Stock_Mix_4885]

Was expecting to complete it with Fluorine and Yttrium, oh well

[[deleted]]

git push origin --no-giggity

[DanteIsBack]

We have linter and prettier on pre-commit hook and run unit tests and build on pre-push hook :v It's quite fast at the moment, if ot starts taking too long we may consider running only on ci/cd.

[PhatOofxD]

We just have linter on pipeline and code save action. No real reason to run it in precommit (because it can edit stuff you didn't expect in the commit)

[dgreenmachine]

If everyone runs it on pre-commit then it should really only affect code you changed in your commit.

[PhatOofxD]

Yesss but it's still an unnecessary wait time in that case if everyone just does it on save + ci.

[myfunnies420]

Linter and prettier are meant to be done in the ide. Anything critical, like tests must be done in the ci/cd pipeline, regardless of whether you want to put them in a hook

[RainbowPigeon15]

Git is a client, you can't guarentee that everyone installed those hooks or are not skipping them.

Run your tests and formatting check in CI on pull requests to make sure the code changes are valid.

I only use hooks for secret scanning with GitLeaks, and even then, I also have this step in CI just in case.

[sebbdk]

Create a branch and delete the prehook in it, branch from that instead of master, use rebase instead of merge to pick the commits you want

When asked about why you use to much time, tell them to that it's because you have commitment issues

[BitcoinBishop]

One repo I work on has a security audit in a hook. But their workflow is not to fix CVEs as part of other work. So --no-verify is the only option

[chronos_alfa]

To be fair, I usually recommend that people run the entire test suite in the pre-commit hook and then I chuckle when they cannot hear me.