 |
History
| Log In
|
|
|
|
Daniel,
I understand easily that full-blown automatic cvs module handling is far from being a quick patch. My suggestion to solve our very immediate need is to have a new pulse property variable called say cvs.prefix or somesuch. Everything stays exactly the same except that on the server side cvs.prefix is used to prefix all patched filenames. What do you think? Christian Hi Christian,
This is certainly something that is possible. I will schedule this for the next release, due out early next week. Regards, -Daniel The properties available are as follows:
1) personal.patch.prefix.default : a default prefix to be applied to all personal builds when they are applied to the source checkout during bootstrapping 2) personal.patch.prefix.<projectName> : a project specific prefix that can be specified on a per project level. If 2 is available, it is used. If not, 1 is used if available. If neither are specified, then the existing behaviour will apply Daniel,
Maybe there is something I quite doesn't catch but I can't activate the patch prefix with 1.2.27. Here is the content of .pulse.properties in directory DFFileDelivery: [camlf@bigboy DFFileDelivery]$ cat .pulse.properties project=File Delivery specification=FDFT Build+Tests cvs.password=fountain personal.patch.prefix.default=FDFT personal.patch.prefix.File Delivery=FDFT (I tried with only personal.patch.prefix.default first without success). Starting the personal build produces: [camlf@bigboy DFFileDelivery]$ pulse personal Pulse password: Updating working copy... ? .pulse.properties M Makefile Update complete. Getting working copy status... MODIFIED Makefile Status retrieved. Creating patch archive... meta.xml files/DFFileDelivery/Makefile Patch created. Sending patch to pulse server... Patch accepted: personal build 94. which is OK since Makefile was the only modified file. Here is the result on the agent: [christian@dfeng4-mdk base]$ ls DFFileDelivery/ FDFT/ [christian@dfeng4-mdk base]$ ls DFFileDelivery/ Makefile [christian@dfeng4-mdk base]$ ls FDFT/ CVS/ DFFileDelivery/ DFTools/ [christian@dfeng4-mdk base]$ ls FDFT/DFFileDelivery/Makefile FDFT/DFFileDelivery/Makefile [christian@dfeng4-mdk base]$ diff DFFileDelivery/Makefile FDFT/DFFileDelivery/Makefile 344c344 < ppulseTest: --- > pulseTest: This shows that the FDFT prefix wasn't used to patch FDFT/DFFileDelivery/Makefile. Any fix suggestion? Hi Christian,
Ahh, I see. The properties that you need to apply are actually system properties on the server side, not properties in the configuration on the client side, although that is a much better place for them. I should have thought of that... See http://confluence.zutubi.com/display/pulse0102/System+Properties for details on how to set these up as system properties. How many projects do you have that need this patch? If it is going to be a hassle for you to maintain, i will fix it so that it becomes a client side property (as you expected). Cheers, -Daniel Daniel,
In fact it is better that they are system properties (I didn't know about them) since I don't have to tell developers how to customize their client property. This being said I set the system properties as per your provided link but it still doesn't work. Just to be sure I tried also with pulse.personal.patch.prefix.default since this seems to be the standard naming scheme, again without success. I also made sure to restart the server after each change. [christian@pit config]$ pwd /home/christian/.pulse/data/config [christian@pit config]$ ls -alt total 56 drwxrwxr-x 3 christian christian 4096 May 22 10:20 . -rw-rw-r-- 1 christian christian 76 May 22 10:01 system.properties -rw-rw-r-- 1 christian christian 569 May 17 14:27 pulse.properties drwxrwxr-x 9 christian christian 4096 Feb 13 18:21 .. -rw-rw-r-- 1 christian christian 64 Feb 6 17:22 service.token -rw-rw-r-- 1 christian christian 1736 Feb 6 17:20 database.properties drwxr-xr-x 3 christian christian 4096 Feb 4 20:22 templates [christian@pit config]$ cat system.properties personal.patch.prefix.default=FDFT pulse.personal.patch.prefix.default=FDFT [christian@pit config]$ How exactly should the property setup be? Moreover is project names have spaces in them what is the correct syntax for the property file? Hi Christian,
A white space character can be represented by escaping it with a '\'. So, the project File Delivery can be represented by personal.patch.prefix.File\ Delivery=FDFT Regarding the pulse.per...., that is probably what I should have named it. However, rest assured that the properties are: personal.patch.prefix.default personal.patch.prefix.<projectName> After updating the system.properties file, did you restart pulse? This file is only read on startup, so modifications will require a restart. Cheers, -Daniel Hey Daniel,
Still no luck, either with default or with the project name and making sure the server was restarted. Is there a way to verify that the server effectively read those new properties? I suspect that either the new properties are not effective for some reason, otherwise your test config is different enough from ours and it doesn't kick in on our side. Hi Christian,
I can think of one possible reason why this is not working. Is your build buy any chance running on a remote agent? If so, can you please try updating the config/system.properties file for that agent? This is not a case that I had considered previously, but would be a reason why you are seeing the behaviour that you are seeing. The system properties need to be available to the process running the bootstrap, which is the agent. It just happens that with all my testing I was using the agent built into the master. Please let me know how you go, and my apologies for not considering this option earlier. Cheers, -Daniel Daniel,
Yes that was it. I was dead sure that the server was "calling the shots" in terms of what happens on the agent. This is a workable solution (we don't have that many projects requiring this trick) but I like very much the fact that all agents are centrally managed through the server. This fix goes a bit against this but I prefer this over having no personal build for those projects :-) Thanks again for the quick turnaround, always appreciated. Christian Hi Christian,
Good to hear. We agree that the agents should be centrally managed by pulse, and to a large extent this is the case. Since the patch is just that, a patch, I took the quickest route possible to implement this, hence using the system.properties. Future functionality will not be so sly :) Cheers, -Daniel |
||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
Patch for personal builds not applied correctly in presence of cvs modules
I see. Unfortunately, at the moment, pulse attempts to simply handle the common case and deal with this problem via some careful user defined working directories. It appears that this is not enough, that pulse is going to need to detect the module type and behave accordingly. There is already some work planned to handle this since Pulses' handling of cvs modules needs to be smarter - in particular, it needs to read and understand the cvs modules file - so that it can correctly handle these situations and remove the need for users playing around with the working directory property for there builds.
Unfortunately, this is more than a quick patch, and so will need to be scheduled in 2.0.x / 2.x sometime, sooner rather than later I expect. We are entering the final stretch for 2.0.0 so are devoting as much effort to that as practical.
Cheers,
-Daniel