[dumb] Re: [dumb] [p4] RE: Automated build trigger

jab jab at pobox.com
Fri Jun 25 02:59:04 PDT 2004

[A careful reading of the example template, below, will tell you that 
the command inside the loop would be "p4 counter" with appropriate 
args. not "p4 review" inside the loop itself. You get the idea.  -jab]

On Jun 24, 2004, at 10:52 PM, jab wrote:
> On Jun 24, 2004, at 5:45 PM, Fawad Khan wrote:
>> Currently, I use the "p4 changes" command on the set of directories 
>> listed in the build script to figure out what changes have taken 
>> place since the last build and if there are change I trigger a build. 
>> For example the following would be used to determine changes to the 
>> l3mob branch since the last build assuming the last build labeled the 
>> files within the l3mob branch with label AP_1.2.0.17-l3mob:
>> p4 changes 
>> //depot/foo/bar/feature_branches/l3mob/... at AP_1.2.0.17-l3mob, at now
>> The problem with triggering the automated build using the above 
>> command is that the presence of the filespec using the label limits 
>> Perforce to look for change lists which affect only the files which 
>> have been labeled with the given label. But, if a new file was 
>> introduced into the feature branch after the last build, then the new 
>> file will not be considered when the above p4 changes command is 
>> subsequently issued. Because of this problem, we were trying to come 
>> up with an alternate mechanism to trigger the automated build. But, 
>> so far, I have not come up with a viable solution.
>> Any ideas on how to solve this problem?
> The first thing to say is "look at 'p4 review' because it's the real 
> tool for post-submit anything."
> I gave a talk at the 2000 Perforce User's Conference on the topic of 
> post-submit scripts,
> mainly to emphasize that all post-submit scripts are really the same 
> form:
> 	Put something like this in a script, then run every N minutes from 
> 'at' or 'cron':
> 		NewChangelists=`p4 review  -t  checkcompile_cntr | cut -d' ' -c2`
> 		for n in $NewChangelists
> 		do
> 			echo Processing changelist $n
> 			# put in code to actually *do* something, here*
> 			p4 review -t checkcompile_cntr   $n
> 		done
> (Now, that's written in Bourne shell from memory, but you get the 
> idea.)
> The second thing to say is, "you will probably want to run a 'p4 files 
> //depot/pathname/you/like/...@$n,@$n`
> as the first line of your code to *do* something, because if there's 
> files in intersection of
> //depot/pathname/you/like/... and the set of files modified in the 
> changelist it's examining, you
> have no work to do (for that changelist.)
> Note that the above is pretty close to the answer to your question: 
> how to figure out
> if things have been updated in tree by a specific changelist or set of 
> changelists.
> (Summarized answer: use 'p4 files, but give it real changelist numbers 
> and not just labels'
> and also '... but use p4 review as the framework, because the 
> structure will deal with
> post-submit needs - which is really the thing you're aiming for, 
> anyhow.')
> The third thing to say is that my model, above, is OVERLY simplistic 
> for the test-compile
> case. (You'd really want to have two counters: 
> last-attempted-changelist-counter and
> last-succeeded-changelist-counter.)
> 	-Jeff Bowles
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user

More information about the perforce-user mailing list