Our CI is too slow to really consider this but I w...
# announceh
hundreds-father-404
10/06/2018, 1:46 AMOur CI is too slow to really consider this but I wish we could require always being up-to-date against master
a
aloof-angle-91616
10/06/2018, 1:47 AMup-to-date in what sense?
h
hundreds-father-404
10/06/2018, 1:48 AMMeaning you have to be rebased against master. If someone merged a change into master since you opened the PR, you have to integrate those changes in
We should not actually do this because we’ll never get anything done. But in an ideal world where CI only took 10 minutes it would be great
hundreds-father-404
10/06/2018, 1:49 AMIt’s designed to catch issues like what Stu is encountering, where your code works against the old version of master but doesn’t work when combined with another PR that gets merged before yours does
a
aloof-angle-91616
10/06/2018, 1:49 AMthat’s what i was thinking. what if we required that on push? or is the idea that it would be useful to have that before doing some work on the PR
aloof-angle-91616
10/06/2018, 1:49 AMah sorry will read up
h
hundreds-father-404
10/06/2018, 1:51 AMSo the idea is it blocks merging. You can only merge if you’re 100% up to date and that also passes CI
a
aloof-angle-91616
10/06/2018, 1:53 AMright i guess i’m thinking we already have a pre commit hook and if a pre push hook exists we could like do a fetch and rebase there
aloof-angle-91616
10/06/2018, 1:53 AMit’s not ideal because it doesn’t ensure it
aloof-angle-91616
10/06/2018, 1:53 AMbut like i think i might use that
aloof-angle-91616
10/06/2018, 1:53 AMunclear
h
hundreds-father-404
10/06/2018, 1:56 AMThat would be interesting. It would at least make sure they’re up to date when they first open the PR.
It wouldn’t help if code gets merged to master when the PR is already open though
hundreds-father-404
10/06/2018, 1:57 AMI’m using the check on my startup and really like it. But I’m the only developer and CI only takes 2 minutes 😂 definitely different circumstances than Pants
a
aloof-angle-91616
10/06/2018, 1:57 AMi’m confused as to the second sentence ?
aloof-angle-91616
10/06/2018, 1:58 AMpants pre commit hook can take ages
aloof-angle-91616
10/06/2018, 1:58 AMwhen we like make rust happen it will go away
aloof-angle-91616
10/06/2018, 1:58 AMlike whenever you push a new commit to your PR it would require you to rebase is the idea
aloof-angle-91616
10/06/2018, 1:59 AMso yeah other code can get into master but you won’t have any race conditions with your code except from the last push to the merge
h
hundreds-father-404
10/06/2018, 1:59 AMAh I meant your idea of a pre-commit hook can make sure that they’re up to date when they first open the PR. But until they run that pre-commit hook again, ie to make a new commit, it won’t help with the problem of new code being merged after the PR is already open
Still much better than nothing tho!
a
aloof-angle-91616
10/06/2018, 1:59 AMi guess that’s what you’re talking about huh
aloof-angle-91616
10/06/2018, 1:59 AMi’m thinking of a pre push hook
aloof-angle-91616
10/06/2018, 1:59 AMif such a thing exists
aloof-angle-91616
10/06/2018, 1:59 AMlooking up
h
hundreds-father-404
10/06/2018, 2:03 AMI really like that idea as something that will barely add required time to developer, while still helping to solve this problem. It doesn’t solve the issue 100%, but if it can solve it 65% at very little cost I’ll gladly take that
a
aloof-angle-91616
10/06/2018, 2:09 AMto me personally i would opt in — if we could in any way address the time from last push -> merge that would be nice, but just remembering to rebase at that one point is probably fine