undefined | Better HN

0 pointsXorNot6y ago0 comments

Higher level tooling doesn't prioritize this. AFAIK neither Gitlab nor Github have an actual option in their CI implementations for "test every commit before allowing merge". And both of those are everywhere.

There's also nothing out there which enforces practice - i.e. new code must be covered by some amount of test case (I'll settle for "it is executed in some way as part of build").

These are all things that could be done, but they're not priorities to the big players evidently, and good luck to me trying to get any organization to commit to putting that tooling in or running something custom that does it.

0 comments

10 comments · 4 top-level

davidjnelson6y ago· 2 in thread

"test every commit before allowing merge"

I just set this up yesterday for a new codebase with GitHub actions. Very straightforward, took an hour or two. Only odd part was that the GitHub actions wizard saves the yaml in the root instead of .github/workflows where it needs to be.

Liskni_si6y ago

Would you mind sharing how to do this, please?

davidjnelson6y ago

Sure np.

Directions vary depending on what you’re doing, but for a React app this will work.

So click on the actions tab in the repo, and click the nodejs template.

Change the run command to the npm script you want to run like npm run ci-check. It will do something along the lines of npm ci && npm run lint-check && npm run format-check && npm run test && npm run build.

Save that. Then move it from the repo root into a new subdirectory you’ll need to create called .github/workflows.

If you are an admin, click the settings tab and protect your merge branch so you can only merge if this succeeds.

That’s it!

1 more reply

Aeolun6y ago· 2 in thread

Why do we want to test every commit? Does it matter if you broke something if you end up fixing it later?

XorNotOP6y ago

In the context of git bisect, it's vital. You can't go looking for bugs commit by commit with no requirement that any individual commit is actually buildable or functional.

In my own projects I'm as guilty of this as anyone, because it's nigh impossible to get the tools to actually do this (which has a massive effect on the culture which builds up around them).

ajuc6y ago

If you know which commit introduced a bug you know which exact lines to look at - it makes understanding the reason for a bug much easier.

If you're good about small commits it reduces the lines you need to look at to less than 100 usually.

bJGVygG7MQVF8c6y ago· 1 in thread

Higher level tooling doesn't prioritize this.

That's an excellent point.

It's deep in the DNA of GitHub, unfortunately. I'm always reminded of this contrast:

> Look, I don’t give two shits about my Git commits. [...]

> From GitHub’s perspective, individual commits become less valuable because the atomic unit is the pull request.

Utter Disregard for Git Commit History https://zachholman.com/posts/git-commit-history/

(The problem with this "unit of change" theorizing is obvious, especially considering GH only recently added a squash-merge feature.)

vs. Torvalds on GitHub PRs:

> Git comes with a nice pull-request generation module, but github instead decided to replace it with their own totally inferior version. As a result, I consider github useless for these kinds of things. It's fine for hosting, but the pull requests and the online commit editing, are just pure garbage.

https://github.com/torvalds/linux/pull/17#issuecomment-56546...

hinkley6y ago

Commit squashing is a scourge. I sometimes go the other way; rewrite my history as a set of independent refactors.

ninkendo6y ago· 1 in thread

> Higher level tooling doesn't prioritize this. AFAIK neither Gitlab nor Github have an actual option in their CI implementations for "test every commit before allowing merge". And both of those are everywhere.

Of course not, because that would be silly.

Nobody cares when code was committed, because that’s not when bugs are introduced into working software.

Bugs are introduced when a branch full of commits is merged into working software. How could it be any other way? Your CI should be testing “what would happen if I merged this”, not “did every commit in `dest...source` pass checks too”.

If you want your history to consist only of working commits that are green, then squash when merging. GitHub and GitLab (and bitbucket) all support the ability to enforce this as a policy on a repo.

bJGVygG7MQVF8c6y ago

> GitHub and GitLab (and bitbucket) all support the ability to enforce this as a policy on a repo.

Relatively recent feature additions, it should be noted

> Of course not, because that would be silly.

No, actually — see the preceding.

j / k navigate · click thread line to collapse