Thank you very much for the explanation. This makes more sense now for me. - Ingo
On Sunday, October 27, 2013 4:52:27 PM UTC-7, Owen B. Mehegan wrote: > > Matrix builds are special. I use them heavily so I'll try to explain - > someone else may be able to do a better job. > > Matrix builds perform a small set of actions on the master (or in the > master workspace), and this is called the flyweight build. I'm always a > little bit vague on where the line is for these, because it's not simply > "things that are not build steps." It can depend on the plugin, and > some/many plugins do not handle the matrix build case well or at all. This > is always a frustration for me. > > Once the flyweight build tasks are done, the main build fans out and runs > on all axes of the matrix. In my case these are always jobs running on > different slaves for different platforms, but I guess some people do things > like matrix builds where the matrix is JVM versions or something, and this > all happens on the master. The point is that here the builds are happening > in a separate workspace for each axis of the matrix. > > Once you get to the post-build steps, I think most of them happen only on > the master, though again depending on the plugin I think this isn't always > the case. But when you specifically mentioned confusion with what happens > when you copy a file back to the master, I thought I would comment because > we do that, and there is a trick to it. Because you're only giving a > filename to copy, the presumption is that the same filename could exist on > all the slaves. If you just copy it back to the master workspace, you'll > overwrite the file a bunch of times and only end up with one copy, when the > contents could be different. So Jenkins, or the plugin, puts the files in > named directories, so you have all the copies. > > The weird thing is that it also copies the file from the master TO the > master, but into a different path for some reason. For example, in my case > files that get copied from slaves end up in > '../configurations/axis-label/precise_64bit/workspace' whereas files that > get copied from the master end up in 'label/lenny_32bit.' Both those paths > are relative to the main workspace on the master. > > Hope this helps, if not perhaps I can explain further. > > -- > IRC: autojack > Twitter: literatesavant > http://holisticqa.com <-- my dev productivity blog > > > On Friday, October 25, 2013 6:05:02 PM UTC-7, Ingo Richter wrote: >> >> Hi, >> >> I've spent a couple of days to reinstall our teams build system. Along >> the way I made a couple of improvements to simplify the job configurations >> by switching to a matrix build for all the supported platforms. >> This work pretty good most of the time. >> >> There is at least one issue that I don't have a solution right now: >> Using the build-name-setter plugin >> https://wiki.jenkins-ci.org/display/JENKINS/Build+Name+Setter+Plugindoesn't >> work for the "master" job if the value should be read from a file. >> This file is created on each slave, but not on the master (obviously). >> Trying to copy the file back to the master with the copy-artifact-plugin >> https://wiki.jenkins-ci.org/display/JENKINS/Copy+Artifact+Plugin didn't >> work either. I don't get an error message, but the file doesn't appear in >> the master workspace. >> >> Is there anything that I miss with matrix job. Why does this type of job >> behave so differently? The copy from slave works just fine in other jobs. >> >> Does anybody have any thoughts that might be helpful to resolve this >> issue? >> >> Thanks, >> Ingo >> >> -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
