4 ms·

>We run a public buildbot that constantly runs new changes to our code against our test suite on every configuration... In perforce terminology how is this don

>We run a public buildbot that constantly runs new changes to our code against our test suite on every configuration... In perforce terminology how is this done? You could use branches, but you could also shelve the change and have the build-bot unshelve it and test. >We also have a commit queue, which is a way to try a change and have it landed automatically if the try succeeds What happens if the change becomes incompatible due to other changes over the course of running the test? I assume the commit just fails in this case..

phasmantistes 11y ago
Well, we don't use perforce (we use Git), so I assume you're asking for your own benefit. The buildbot masters watch the source repository for new commits. When they see a new commit appear, they tell all of their builders (each one representing a different build configuration) to do a build+test sync'ed to the new commit hash. The builders check out the repository at that revision, compile, and upload the binaries for the testers. The testers then download those binaries, test, and report results. Then we have a display (build.chromium.org) which shows the results of the compiles and tests on each configuration for all of the recent commits. It's actually pretty rare for a patch to become unlandable while the tests are running. But if it does, it just sends a message to the owner of the change that says "Hey, your patch failed to land due to merge conflicts. Please rebase and fix them, then try again."