I’d like to be able to have both “no commit ever breaks the build/tests” and also non-squashed merges. This means much use of revisions/rebase/fixup in git. I’d like drone to ensure that each and every commit build/passes tests before allowing merge to master. Is this possible now? Will there be a way to do so in immediate future?
I’d like to be able to have both “no commit ever breaks the build/tests” and also non-squashed merges. This means much use of revisions/rebase/fixup in git.
Not sure I completely follow, but Drone delegates the git clone to a plugin which means you can provide your own custom plugin if you need something more specialized. More details here http://docs.drone.io/cloning/
Also note that this post might be relevant: Planned change to git clone logic
I don’t think clone needs any change, consider the following PR:
master c1 c2 # some bug c3 # bug is fixed c4 PR-HEAD
When drone clones the PR we get a build/test of c4 which passes. But if I ever need to bisect and land on c2 the build will break and it may not be due to the bug I’m bisecting for, so this failure is just noise.
I’d like for drone to build/test c1, then c2, c3, c4 so that c2 is marked as a fail and blocks the PR.
I do this for my own PRs before submission using
git rebase -x master $build-test-command.
I don’t want to have to squash when merging because then I lose history of development.
Thanks for the clarification.
I think this could be achieved today with a shell script. You would need to perform a diff of commits between the pull request ref and the target branch, and then loop through each commit and run your build and test commands. You would invoke this script from your pipeline step.
pipeline: build: image: golang commands: ./build_diff.sh
Right but the problem then is that I have multiple stages that build different things with different images. And I’d lose on the small niche images that is great about drone, and would need a travis-like all the things image.
I’d be great if drone would not re-build/test commits that haven’t changed (though I don’t think would be possible nor a requirement I’d say)