> 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.)...
I've looked through the build configuration and couldn't find anything specifically related to this. How would I know if the build is configured to use the same directory or not? Justin On Wed, Feb 14, 2018 at 11:08 PM, Tim Bain <tb...@alumni.duke.edu> wrote: > 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 > > >
