New answers tagged

2

Let's ask an equivalent question: Why would you build the code on a CI server? Surely, by the time something gets committed to master, a developer has already built the code before and fixed any errors that might've occurred with their new code. Isn't that the point of building code? Otherwise they've just committed broken code. The are ...


1

You need a reproducible build - this means you do not want your CI server downloading things from the internet on demand. You need to download them and otherwise collect everything needed for the build and store it somewhere accessible to the CI server. Now the easiest and most future-proof way of doing that is to store these things in their own ...


2

For point 1. and 3. You could create private Ivy repository and fetch DB Drivers and Modules from it via your Build tool ( Mvn, Ant, Gradle support getting dependencies from Ivy repos ) when building your app. And for .xml files - you can have git repository for your Test Environment config files. Or have them encrypted in your app repository, and configure ...


3

It is possible to imagine cases when the change A does not break the test, and change B does not break the test, but A and B together do. If A and B are made by different developers, only CI server will detect the new bug. A and B may even be two parts of the same longer sentence. Imagine a train driven by the two locomotives A and B. Maybe one is more than ...


22

Apart from the excellent Oded answer: You test the code from the repository. It may work on your machine with your files... that you forgot to commit. It may depend on a new table that does not have the creation script (In liquibase for example), some configuration data or properties files. You avoid code integration problems. One developer downloads the ...


68

As a developer who doesn't run all the integration and unit tests before making a commit to source control, I'll offer up my defense here. I would have to build, test and verify that an application runs correctly on: Microsoft Windows XP and Vista with Visual Studio 2008 compiler. Microsoft Windows 7 with Visual Studio 2010 compiler. Oh, and the MSI ...


3

Assuming (contrary to other answers) that developers are quite disciplined and do run unit tests before committing, there can be several reasons : running unit tests can take long for some special set up. For example, running unit tests with memory checker (like valgrind) can take much longer. Although all unit tests are passing, memory check can fail. the ...


14

by the time something gets committed to master I usually set up my CI to run on every single commit. Branches don't get merged into master until the branch has been tested. If you're relying on running tests on master, then that opens a window for the build to be broken. Running the tests on a CI machine is about reproducible results. Because the CI ...


4

By the time something gets committed to master, a developer should have already run all the unit tests ... but what if they haven't? If you don't run the unit tests on the CI server, you'll not know until someone else pulls the changes to their machine and discovers the tests just broke on them. In addition, the developer may have made a mistake and ...


190

Surely, by the time something gets committed to master, a developer has already run all the unit tests before and fixed any errors that might've occurred with their new code. Or not. There can be many reasons why this can happen: The developer doesn't have the discipline to do that They have forgotten They didn't commit everything and pushed an ...


22

You'd think so wouldn't you - but developers are human and they sometimes forget. Also, developers often fail to pull the latest code. Their latest tests might run fine then at the point of check-in, someone else commits a breaking change. Your tests may also rely on a local (unchecked-in) resource. Something that your local unit tests wouldn't pick up. ...



Top 50 recent answers are included