undefined | Better HN

0 pointsmojuba9y ago0 comments

Hmm. I usually do merges locally as serious stuff should be built and tested before pushing anyway, so probably why never used GitHub's hosted functions.

0 comments

bjacobel9y ago

> serious stuff should be built and tested before pushing anyway

Yes and no. Build in your CI server that's set up to mirror your prod environment after pushing, but before merging. That's what the whole industry of CI providers and integrations built into and around GitHub and GitLab is for.

stormbrew9y ago

To be fair, one of the annoying things about how PRs work is that they don't test the merge, they test the commit relative to its original base. Your tests may pass in the PR, but fail once applied to later changes in the main line.

pavel_lishin9y ago

Most CI solutions will take care of that; they'll pull in the PR, merge it locally with master, and run tests on that.

1 more reply

Zarel9y ago

In my experience, Travis CI tests the merge at the time the pullreq is created. It also has a "re-run" button that lets you merge the latest master and run the tests on top of that.

steveklabnik9y ago

And depending on setups, testing locally is testing far fewer environments than CI. I only have one laptop, but many of my projects need at least OS X, Linux, and Windows, and often multiple versions of those.

aargh_aargh9y ago

If you write tests diligently, you can integrate CI with GitHub. Travis CI might be the most popular option.

j / k navigate · click thread line to collapse