I'm in no way trying to discourage you guys from evaluating Travis CI. However...
There are currently 4 builds that are in a failed state on the history of that job: - https://builds.apache.org/view/A/view/ActiveMQ/job/ActiveMQ-Artemis-PR-Build/5111/consoleFull - Failed due to "Could not transfer artifact com.google.code.maven-replacer-plugin:replacer:pom:1.5.3 from/to central ( https://repo.maven.apache.org/maven2): /home/jenkins/.m2/repository/com/google/code/maven-replacer-plugin/replacer/1.5.3/replacer-1.5.3.pom.part.lock (No such file or directory)" - This might in fact be environmental, it's hard to tell. - https://builds.apache.org/view/A/view/ActiveMQ/job/ActiveMQ-Artemis-PR-Build/5103/console - Failed due to "failed to write new configuration file /home/jenkins/jenkins-slave/workspace/ActiveMQ-Artemis-PR-Build/.git/config.lock" - It looks like you've got your builds configured to use the same directory for all builds of the Jenkins job, rather than using a different directory for each build (5103, 5104, etc.), and if that's true, it seems very expected that concurrent builds would fail with errors like this one. Is there a reason you're not checking out the code into a directory that's specific to the individual build being done, to allow them to operate in parallel without interfering with one another? Or am I misreading something about the log output? - https://builds.apache.org/view/A/view/ActiveMQ/job/ActiveMQ-Artemis-PR-Build/5104/consoleFull - Failed due to checkstyle violations. Seems bona fide, and would not be fixed by a move to Travis CI. - https://builds.apache.org/view/A/view/ActiveMQ/job/ActiveMQ-Artemis-PR-Build/5105/console - Failed due to checkstyle violations. Seems bona fide, and would not be fixed by a move to Travis CI. This is obviously a very small sample size, and you guys have been watching these builds for far longer than the 10 minutes I've put into it just now, so there's definitely a chance that today's builds aren't representative. But do consider whether the "environmental" problems you're running into with Jenkins are in fact Jenkins's doing, or whether maybe they're the result of a misconfiguration that you'd have the power to fix yourselves. Again, I'm not lobbying against considering Travis CI (I've got no experience with it), just suggesting based on a very small sampling that maybe some of the problems being laid at Jenkins' feet might not actually be Jenkins's fault and might be solvable within Jenkins, so factor that into any discussion of the pros and cons of moving vs. staying. Tim On Tue, Feb 13, 2018 at 3:56 PM, Michael André Pearce < michael.andre.pea...@me.com> wrote: > This is great idea! I get so frustrated with these environment issues. +100 > > Some other advantages I could see we could implement if successful. > > run a Linux build and a macOS build eg to check bits like kqueue and or > other os specific behaviours (aio fallback to nio) > > look to use appveyor for a windows build validation. (I’m thinking this > validates bat files etc and ensures not Linux specific paths being used in > code by mistake) > > Sent from my iPhone > > > On 14 Feb 2018, at 03:17, Justin Bertram <jbert...@apache.org> wrote: > > > > Over the last several months I've noticed that the Jenkins-based builds > > used to validate GitHub pull-requests for Artemis are failing at a > > significant rate for illegitimate reasons (e.g. environmental issues, > > timing out because they're too slow, etc.) or not being run at all. Even > > as I type this there are 4 PR builds listed on > https://builds.apache.org/ > > which have been waiting for hours. > > > > I'd like to solve this problem so we have relatively quick & reliable PR > > builds. I'm vaguely familiar with Travis CI, and I know other Apache > > projects use it for PR builds. I think it would be worth investigating > > whether or not it would solve our problem. What do you guys think? Does > > anybody in the community have experience with Travis CI? > > > > > > Justin >
